2015-02-11 24 views
6

O ile rozumiem, Executory pomagają w obsłudze wykonywania runnables. Na przykład. Wybrałbym użycie executora, gdy mam kilka wątków roboczych, które wykonują swoją pracę, a następnie kończą. Executor poradziłby sobie z tworzeniem i zakończeniem wątków potrzebnych do uruchomienia run runów pracowniczych.Czy wątek jest faworyzowany w stosunku do Executora?

Jednak teraz mam do czynienia z inną sytuacją. Ustalona liczba klas/obiektów powinna zawierać własny wątek. Tak więc wątek rozpoczyna się przy tworzeniu tych obiektów i wątek będzie działał przez cały czas życia tych obiektów. Kilka obiektów z kolei jest tworzonych na początku programu i istnieje przez cały czas wykonywania. Domyślam się, że wątki są lepsze od Executorów w tej sytuacji, jednak kiedy czytam w Internecie, każdy wydaje się sugerować użycie Executorów zamiast wątków w każdej możliwej sytuacji.

Czy ktoś może mi powiedzieć, czy chcę wybrać Executory lub Nici tutaj i dlaczego?

Dzięki

+0

Co będzie robić te nitki podczas ich życia ? Czy będą w 100% zajęci obliczaniem wartości dziesiętnych pi, czy będą bezczynni, dopóki nie wejdą z nimi w interakcję? – aioobe

+0

to zależy ... niektóre z nich będą miały około 50% czasu bezczynności, inne tylko około 10% – flxh

+0

... jeszcze inni będą w 100% zajęci przetwarzaniem protokołów drzew. – flxh

Odpowiedz

1

Nie wiedząc więcej o kontekście, trudno jest dać dobrą odpowiedź, ale ogólnie rzecz biorąc powiedziałbym, że sytuacje, które wymagają użycia Thread, są bardzo nieliczne. Jeśli zaczniesz próbować zsynchronizować swój program "ręcznie", stosując zakładkę synchronized, założę się, że wszystko szybko wymknie się spod kontroli. (Nie wspominając już o tym, jak trudno będzie debugować kod).

Ostatni raz użyłem wątku, kiedy chciałem nagrać jakiś dźwięk w tle. To było coś typu "start"/"stop", a nie "zorientowane na zadanie". (Próbowałem długo i ciężko, aby znaleźć bibliotekę audio, która mogłaby się dla mnie zamknąć, ale się nie udało.)

Jeśli zdecydujesz się na rozwiązanie wątku, sugeruję, aby spróbować ograniczyć zakres wątku do wykonywać tylko w powiązanym obiekcie. Pozwoli to w możliwie największym stopniu uniknąć zmuszania do myślenia o zdarzeniach - przed relacjami, bezpiecznym publikowaniu wartości itp. W całym kodzie.

+0

"Jeśli zaczniesz próbować zsynchronizować program" ręcznie "przy użyciu synchronizacji, powiedziałbym, że jesteś na naprawdę cienkim lodzie" Dlaczego tak? Wszelkie odniesienia do tego wsparcia? –

+0

Model pamięci Java jest bardzo owłosiony i myśli w kategoriach zdarzających się zanim relacje szybko wymkną się spod kontroli. W niemal każdej sytuacji powinieneś spróbować pracować na wyższym poziomie abstrakcji, używając klas dostarczonych przez java.util.concurrent. – aioobe

+0

aktualnie w tej chwili synchronizuję mój program "ręcznie" niezsynchronizowany. Jaka byłaby alternatywa? – flxh

3

Nieco mieszania rzeczy. Executor to tylko interfejs. Thread to klasa podstawowa. Nie ma niczego, co bezpośrednio sugeruje, że implementacje Executor wykonują zadania w osobnych wątkach.

Przeczytaj kilka pierwszych linii JavaDoc.

Executor

Więc jeśli chcesz pełną kontrolę, wystarczy użyć Thread i robić rzeczy na własną rękę.

+0

Przypuszczalnie myśli o ExecutorServices i Executorach, takich jak ThreadPoolExecutor. – aioobe

+0

@aioobe Tak, wiem. Ale to tylko jeden sposób myślenia o tym. –

+0

Przepraszamy za to zamieszanie. Ale tak, jak twierdzi Aioobe, mówiłem o ExecutorServices. – flxh

1
  • ExecutorService może mieć wątek basen

Optymalizuje wydajność, ponieważ tworząc wątek jest drogie.

  • ExecutorService ma kontrolę cyklu życia

shutdown(), shutdownNow() etc są świadczone.

  • ExecutorService jest elastyczny

Można wywołać szereg zachowań: dostosowanie ThreadFactory, ustaw rozmiar puli wątków, opóźnienie zachowanie ScheduledThreadPoolExecutor etc ...