Hej,
W przypadku, gdy metoda biznesowa tego wymaga, lepiej jest stosować własnoręcznie oprogramowane wątki (np. fork/joina) czy może lepiej korzystać z adnotacji @Asynchronous ?
0
0
Ej. @niezdecydowany ? :P
Po przeczytaniu mojego pytania czy wtf ten paraliż mózgu? :)
0
Generalnie w 99% przypadków lepiej używać mechanizmów wbudowanych. Własne pisze sie tylko jeśli jest ku temu konkretny powód. Na przykład potrzebujesz jakąś szczególną logikę zastosować, albo robisz cuda na kiju z rozproszeniem i standardowe mechanizmy się nie nadają itd.
0
@Shalom - fork join jest czescia javy, tak samo jak adnotacje :)
0
Jasne i ręczne locki w java.util.concurrent też są, a mimo to lepiej jednak korzystać z synchronizacji ;] I zgodnie z twoją logiką to przecież mógłbym też sam zaimplementować sobie kolekcje, jakąś listę czy mapę, bo wszystkie potrzebne elementy "są częścią javy", czyż nie?
Chodzi o to ze jeśli kontener ma już wbudowane zarządzanie pulą wątków do wykonywania zadań asynchronicznych to nie ma sensu pisać tego samodzielnie. Szczególnie że zwykle koderzy którzy pisali serwer aplikacyjny / framework są znacznie lepsi niż "przeciętny koder" i ich rozwiązania są lepsze.
0
Pomijając kwestie EJB.
Oczywiście, że nie należy korzystać z synchronized tylko java.util.concurrent.
0
Pójdziesz do pierwszej pracy to ci wybiją z głowy takie pomysły. Jasne, jeśli jest taka potrzeba bo coś się nie skaluje to można sie bawić w optymalizacje przez ręcznie stosowanie locków (chociaż po prawdzie to należy stosować obiekty immutable, stateless i podejście funkcyjne i wtedy w ogóle nie trzeba sie bawić w synchronizacje). Ale przedwczesna optymalizacja nigdy nie jest dobra. Poza tym jeśli ktoś stosuje ręcznie locki albo np. wait i notify to w 99% przypadków będzie to źródłem błędów, deadlocków, race conditions i innych trudnych do wyśledzenia problemów.
To że coś jest "szybsze" wcale nie znaczy że jest "lepsze". W rzeczywistości zwykle liczy się:
- szybkość pisania kodu
- łatwość utrzymania kodu
- czytelność kodu
Wprowadzanie do kodu niskopoziomowych mechanizmów, albo ręcznej zabawy wątkami sprawia że kod pisze się dłużej, jest znacznie mniej czytelny i jako że kodu jest więcej i jest bardziej skomplikowany to jest trudniejszy w utrzymaniu. A korzyści zwykle są pomijalne bo zyskujesz milisekundy na lockowaniu podczas gdy logika biznesowa, komunikacja ze zdalną bazą danych, komunikacja z webserwisami i tym podobne mechanizmy kosztują cię tysiące razy więcej i to one są operacjami "wiodącymi".
0
Wyjaśnij różnice w skalowalności synchronized i te z java.util.
Próbujesz znowu mi "pojechać", że jestem noobem z gimnazjum.
0
Absolutnie nie! Po prostu wygłaszasz opinię która wskazuje na to że nie masz jeszcze zbyt dużo komercyjnego doświadczenia, nic więcej. Wcale nie kwestionuje twojej znajomości technologii, a jedynie brak znajomości realiów pracy programisty.
O różnicy w skalowalności przecież już wiesz, bo sam pokazałeś link który o tym traktuje -> pokazuje że ręcznie zarządzanie lockami skaluje się czasem lepiej. Przypadek ekstremalny stanowiłaby sytuacja kiedy masz 2 rodzaje wątków które mogą korzystać z pewnego zasobu wspólnie w ramach typu. W efekcie w sekcji krytycznej możesz mieć wiele wątków X albo wiele wątków Y. Zrobienie tego w naiwny za pomocą synchronized spowoduje wąskie gardło bo w sekcji krytycznej będzie zawsze tylko 1 wątek.