Posiada ktoś może jakiś tutek do wielowątkowości w springu?
Ktoś mi może wytłumaczyć najogólniej jakie zastosowanie ma @Async a jakie @Scheduled?
Jakieś plusy, minusy? Jak to działa?
0
0
Ogólnie, to @Async mówi Springowi że te metodę, chcesz wywołać w http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ThreadPoolExecutor.html - oczywiście Spring ma swoją abstrakcje nałożoną na te klasy, a dokładnie: http://docs.spring.io/spring/docs/current/spring-framework-reference/html/scheduling.html w dziale TaskExecutor types
@Scheduled(fixedDelay=5000) to nic innego jak np: wykorzystanie http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ScheduledThreadPoolExecutor.html (aczkolwiek implementacja w springu może się różnić).
Wszystkie te ficzery jesteś w stanie stworzyć samodzielnie, używając właśnie tych klas podanych wyżej, ale tracisz np: możliwość korzystania z annotacji (chyba że zrobisz sobie swoje - da się).
Po co ? możesz mieć np: jakiś serwis
RestService service
którego metoda
service.createNewOrder()
może zająć kilka sekund, ale user nie musi czekać aż ta metoda się zakończy, możesz ją wywołać w osobnym wątku(bo na tym to właśnie polega, metoda asynchroniczna wywołuje się gdzieś daleko od nas).
0
Dzięki bardzo.
Takie dodatkowe pytanie. Intuicja mi podpowiada, że jeśli korzystam z serwisów, które będą ze sobą jakoś współpracowały to muszę raczej skorzystać ze @Scheduled bo z @Async może coś nie zadziałać poprawnie, albo nie zawsze? Dobrze myślę?
0
Dlaczego ? to nadal jest TaskExecutor - i co znaczy że serwisy mają ze sobą współpracować ?
0
W sensie to sie moze wszystko nawzajem wywolywac, uzywac itp.?
co masz na mysli mowiac, ze metoda asynchroniczna wywoluje sie gdzies daleko od nas?
0
Bo Twoja metoda jest odpalana w innym wątku, na tym polega @Async ... Możesz zwracać wynik z takiej metody ale w tedy dostajesz Future<TwojTyp> - to wszystko wykonuje się w **WĄTKU ** który jest obsługiwany przez Executor.
Najbardziej trywialnie jak można:
Nie asynchronicznie:
jakasMetoda();
asynchronicznie:
class AsyncCall extends Thread {
public void run() {
jakasMetoda();
}
}
//gdzie dalej
(new AsyncCall()).start(); //zapominasz o tym
Oczywiście pod spotem to nie działa na czystych Thread'ach - bo to by było głupie, znowu po to jest Executor, który możesz nawet podać w atrybutach dla @Async.
P.S widzę że Ty nie specjalnie wiesz po co ten mechanizm który oferuje @Async tak naprawdę istnieje. Radzę albo poczytać trochę o wątkach albo omijać szerokim łukiem.
0
Dzięki. Sorry, nie do końca doczytałem Twojego pierwszego posta i nie zrozumiałem.
Tak, z wątkami jestem dupa i znam tylko jakies podstawy podstaw prostych rzeczy... i jeszcze jestem niedoświadczony i w zasadzie pierwszy raz spotykam się z nimi w web czy springu.
Dzięki za linki, poczytam sobie.
0
Ten koleś jest spoko: http://tutorials.jenkov.com/java-util-concurrent/executorservice.html
I teraz, wystarczy że założysz, że taka metoda, z adnotacją @Async, jest odpalana w takim miejscu.
0
O, śliczne tutoriale, przejrzyste. Bardzo dziękuję.
Ogólnie widzę, że temat wątków muszę mocno nadrobić.
A tak już bardziej z ciekawości zapytam. Jak oceniasz przydatność/popularność wielowątkowości w web? Bo nie raz słyszałem, że jest to rzadko wykorzystywane.
0
Teoretycznie, np: każda transakcja w EJB jest wpinana jako http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html , tak więc te wątki są wszędzie, ale nisko. W Springu np: te podejście że wszystko jest bezstanowym singletonem uprasza sprawę, i normalnie programista nie styka się z problemem wielowątkowości. Ale jak już chcesz stworzyć cache, wykonać coś asynchronicznie, stworzyć jakiegoś Producer-Consumera problem się pojawia. Kiedyś w WTF'akach @Koziołek pokazał kod jakiegoś seniora który zniszczył mi mózg swoim sposobem na synchronizowanie :D
Także warto mieć świadomość, i według mnie to jednak podstawy - nawet jeżeli nie spotykasz się z tym za często - na pewno to jest ważniejszeniż umiejętność całkowania ...
0
To, że wątki sobie latają pod spodem to tyle to wiedziałem, oczywiście chodziło mi o manualne majstrowanie przy tym ;)
Chociaż by coś więcej majstrować to raczej trzeba dobrze wiedzieć co sie robi hehe
Jeszcze raz dzięki i cenną opinię na końcu.
0
Ogolnie to zrobilem co potrzebowalem.
Ale chcialem jeszcze zapytac o samą konstrukcję np.
http://www.mkyong.com/spring/spring-and-java-thread-example/
czy zawsze trzeba tworzyc Beana ze scopem = prototype czy jest sliczniejszy sposob?
0
Nie, nie trzeba(w tym przypadku trzeba, bo inaczej to by było gupie), i nie wiem co to jest "śliczniejszy sposób" w tym wypadku. Tu tak naprawdę nic nie ma... tyle że obiekty są zarządzane przez kontener. I wydaje mi się że nie wiesz też czym różnicą się scopy beanów - zamiast brać się za wątki, zrozum podstawy.
0
Ok. Ktoś mi rzucił tekstem, że można to zrobić bez Beana, stąd pytanie.
ok, poczytam, więcej sięnie pogrążam ;)
2
Ale przecież bean to ...... nic innego jak obiekt, nadszedł ten czas, że ludzie uzależnili się od springa, w ten sposób, że będą myśleć że inaczej się nie da - armagedon nadchodzi
0
a takie pytanko.
W sumie korzystacie z tych springowych adnotacji czy moze bardziej prawilnie ExecutorService, Future i Callable?
0
Zimny Terrorysta napisał(a):
a takie pytanko.
W sumie korzystacie z tych springowych adnotacji czy moze bardziej prawilnie ExecutorService, Future i Callable?
A dlaczego Springowa adnotacja nie jest "prawilna" ? Jeżeli masz naprawdę mało wytężony fragment aplikacji który może zostać wykonany asynchronicznie, np: jakieś żądanie do ERP'a, powiedzmy, synchronizacja, która idzie raz dziennie, trwa 5min, zajmuje jeden wątek, to żaden problem. To w takim przypadku jak wykonasz taką logikę w jakieś metodzie, oznaczysz
@Async
i masz spokój - wiesz że działa, żadnego problemu performancem nie będzie nawet jeżeli SimpleAsyncTaskExecutor
używany jako domyślny egzekutor przez <code class="java">@Async
tworzy nowy per każdą inwokacje.
Możesz mieć jakieś krótko żyjące akcje, wywoływane bardzo często(przychodzący request ? ale to nie jest związane z
@Async
, ale jako przykład dobre) - w takiej sytuacji możesz przecież też skorzystać z @Async
ale podać twój własny executor z jakimś tam thread poll'em (http://docs.spring.io/spring/docs/4.0.2.RELEASE/javadoc-api/org/springframework/scheduling/annotation/EnableAsync.html)
0
Tak tylko napisalem ;)
Ze springiem w sumie powinno byc wygodniej uzywac, wstrzykiwac itp.
Tylko tak jakos mniej jawnie widac co sie dzieje, no i nie mam z tym duzego doswiadczenia ;)
0
hmm, a da sie jakos shutdownowac tego @asynca , w łatwy sposób?
czy trzeba swój configurer zrobić?