Tak serio to czy w projekcie korzystaliscie z wielowątkowości?

Tak jak w temacie, oczywiście nie mam tu na myśli intereceptorow, adnotacji, libow zewnętrznych korzystających z magii.

Czy sami mieliście kiedyś faktycznie taka potrzebę?
Ja przez 3 lata - 5 projektów. Jeden raz.
Było to z racji na przetwarzanie bardzo duzych plikow. Ciekawi mnie czy ja jestem jakiś nieczuły i olewam wielowatki, broniąc się przed użyciem rencoma i nogami i czy do innych tez przemawiają wady i korzystają w oststecznej ostateczności.

Patrząc realnie, nie życzeniowe to z wad widzę:
Ciężko testować
Bez testow brak pewności co do działania
Wymagana duża wiedza
Duże ryzyko stosowania
Ciężko utrzymać

Życzeniowo można pragnąc by obiekty były niezmienne. Ułatwiłoby to duzo, ale tak nie jest.

Stad tylko i wyłącznie widzę opłacalność wielowątkowości gdy nie ma innego wyjścia.

Tak naprawdę jeśli nie pracuje się w jakiejś niszy to trudno nie korzystać. Czasami nie używa się tego wprost. Na przykład aplikacje webowe są wielowątkowe, więc trzeba mieć na uwadze wszystkie konsekwencje z tym związane.

Mi może też z raz zdarzyło się w projekcie komercyjnym korzystać z takiej "surowej" wielowątkowości tak bezpośrednio ale pośrednio oczywiście cały czas korzystam tj. korzystam z gotowych rozwiązań np. jakieś pule wątków ExecutorService, TaskExecutor, TaskScheduler, HikariCP, CompletableFuture, RxJava, ConcurrentHashmap, AtomicLong itd. gdyż nie ma sensu wymyślać koła na nowo. Generalnie implementowanie w projekcie wielowątkowości na własną rękę jest trudne i łatwo można sobie strzelić w stopę z drugiej strony warto wiedzieć i rozumieć jak to działa pod spodem.

Ciężko testować
Bez testow brak pewności co do działania

Dlatego najlepiej oddzielić kod domenowy od wielowątkowości wtedy o wiele łatwiej testować.

Dodam jeszcze, że ostatnio w projekcie w testach integracyjnych dodałem taką konfigurację, która
sprawiła, że testy były bardziej deterministyczne i nie wywalały się:

    static class AsyncConfiguration {

        @Bean("taskExecutor")
        public Executor taskExecutor() {
            return Runnable::run;
        }

        @Bean("reportTaskExecutor")
        public Executor reportTaskExecutor() {
            return Runnable::run;
        }
    }

Komercyjnie zdarzyło mi się trzy razy. Były ty bardzo proste rzeczy w stylu "publish- subscribe", żeby oddzielić mielenie danych od IO.

Tak. Np teraz pracuje nad systemem którego część stanowi coś jak workflow engine i że względów wydajnościowych wiele zadań można wykonywać równolegle, ale wymaga to też odpowiedniej komunikacji między tymi zadaniami.

Bardzo często. Najczęściej jak używam IO i chcę robić jak najwięcej równolegle, żeby zmniejszyć latency. Drugi use case to asynchroniczne akcje w stylu fire and forget. Jeśli chodzi o data parallelism to najczęściej używając uproszczonych modeli w stylu zmapuj każdy element używając funkcji f używając tyle wątków ile się da

Korzystałem wielokrotnie, nawet pisałem własne locki i inne bebechy.

Miałem dosłownie kilka komercyjnych projektów gdzie faktycznie zrównoleglenie na wątki dawało sens wydajnościowy. W tym tylko jeden(!!!) większy projekt żyjący kilka lat(przetwarzanie ton PDFów dla drukarni poczty), reszta to to jakieś proste skrypty: zrób przelicz, zapomnij.

Akurat pisanie wielowątkowe jest łatwe, o ile nie bawisz się w mutowanie i robienie efektów ubocznych pod dywanem. (Kotlin, Scala, Haskell).
Chociaż w Scali i Kotlinie można się naciąć na gówniane biblioteki javowe, które udają w API, że sa OK,... ale kłamią. Czyli np mutują coś zupełnie bez potrzeby typu: addChild(c:Child) : Parent - gdzie zamiast zwracania nowego Parent mutowany jest this, a potem zwracany...

Trudna rzecz w wielowątkowości to wydajność - w tym sensie, że dość częśto intuicje co do tego co i jak warto zrównoleglić są zaskakująco zawodne. Najczęściej się mylę mówiąc, że nic nam zrównoleglenie jakichś operacji nie da (np. skanowanie plików na jednym dysku)... a prosty test praktyczyny pokazuje, że jednak istotnie pomaga.

Abstrachuje tu też od problemów takich jak:

• czy kod non-blocking jest wielowątkowy (skoro wygląda dokładnie tak samo odpalony na jednym wątku co na 16),
• klasyczna webówka na javie jest blokująca i wielowątkowa z definicji,
• czy w takim JVM da się w ogóle coś napisać jednowątkowo - skoro zawsze działa Ci kilka wątków technicznych,
• w Haskellu/GHC kod może być odpalany wielowątkowo bez wiedzy programisty

szkoda że pytanie w dziale java a nie ogólne ;)

Mi się nigdy nie zdazylo robić tego jawnie tj poza tym co jest w frameworku. A robiłem dziwne projekty xD. Jeden projekt który tworzyłem(i dalej supportuje) dawno temu ponad 100TB( i dość szybko rośnie) danych binarnych kazda operacja to od 100 do 2000 odczytow małych fragmentow plikow(same pliki tak srednio maja po ~500MB) aktywnych uzytkownikow ze 3k I nie jest to skalowane w zaden sposob ot zwykly monolit na springboocie. Dalej chodzi. Ostatnio drobne zlecenie analiza danych z czujnikow 300M danych rocznie i trzeba robic raporty z "anomaliami" po prostu wszystko wjebałem w postgresa i robie wszystko w bazie. Napisałem pare funkcji agregujących przelicza sie to do postaci posrednich wszystko co noc tak ze 20-30minut(dla danych z 2-3lat) a potem raporty jakie chcą maja od strzała.

Takze dalej czekam na projekt gdzie wreszcie będę musiał się nauczyc wielowatkowsci dobrze xD.

BTW u mnie przy duzym IO zawsze jak próbowałem optymalizować/zrównoleglać to zazwyczaj dostawałem po łbie od sieciowców bo zapychałem infrastrukturę XD.

Ja użyłem ostatnio ale w Scali. I nie były to gołe wątki tylko Future i/lub par dla dużej kolekcji. Przez co zadałem też pytanie o wyższość jednego rozwiązania nad drugim na forum Kolekcje parallel vs Future.traverse

Tylko czy Future liczy się jako wielowątkowośc? Czy intresuje cię tylko ręczne zarządzanie wątkami i pulą wątków?
(Albo czy praca z biblioteką Akka liczy się jako wielowątkowość? Albo czy praca w Erlangu (gdzie sa miliony lekkich procesów liczy się jako wielowątkowośc)?)
No bo żeby napisac kod wielowatkowy w Scali czy Haskellu nie trzeba nawet wiedzieć co to wątek. Wątek to szczegół implementacyjny który jest gdzieś tam sobie w tle

Patrząc realnie, nie życzeniowe to z wad widzę:
Ciężko testować
Bez testow brak pewności co do działania
Wymagana duża wiedza
Duże ryzyko stosowania
Ciężko utrzymać

Jak masz jakieś locki itp to pewnie tak. Dlatego takich rzeczy unikam, ale gdzie jest trudność jak w jednym CompletableFuture idzie request po HTTP a w drugim wczytywanie czegoś z dużego pliku?

W sumie à propos tego tematu to ciekawe co wyjdzie z tego JEPa

Mi się czasem przytrafia, że gubię wątki w projekcie.

Tak czytam wasze posty i się dziwie że jednak mało korzystacie. Takie projekty ze wszystko idzie po sznurku czy jednak niechęc do wielowątkowości? Ja używam, czy często? Raczej tak, jak widzę że moge coś zrównoleglić to to robię.

Przykład z amatorskiego projektu, mając do wysłania kilkaset tysięcy zapytań HTTP i przetworzenia odpowiedzi, wolałem wykonywać równolegle 50-100 tasków, wykorzystując wszystkie wątki i procesor w 100% niż wysyłać jeden za drugim. Na lokalnej maszynie skracało to czas realizacji cyklu 10x-20x. Na współdzielonym serwerze skracało jakieś 3x-5x, ale to z racji jego limitów. Ale to w C# to nie wiem czy się liczy ;p

kzkzg napisał(a):

Tak czytam wasze posty i się dziwie że jednak mało korzystacie. Takie projekty ze wszystko idzie po sznurku czy jednak niechęc do wielowątkowości? Ja używam, czy często? Raczej tak, jak widzę że moge coś zrównoleglić to to robię.

W Javie i podobnych robi sie to po prostu trudno. Ja jak w Scali moge cos zrownoleglic to zazwyczaj to robie bo w przypadku ZIO koszt jest prawie zerowy.

Jeśli chodzi o takie bezpośrednie odwołanie do java.util.concurrent i Thread w Javie to nie było tego zbyt wiele - a raczej nie było to trudne. Ot, standardowy scenariusz w stylu "zapytaj o X serwisów, odpowiedz" lub jakaś bardzo uproszczona implementacja szyny.

Jeśli chodzi o sytuację, w której framework przychodzi z własnym API, które nie ogarnia wielowątkowości za ciebie, ale po prostu opakowuje koncepcje w kontener (np. zamiast tworzyć wątek przez new Thread() musisz wywołać np. MyFrameworkApi.createNewThread()) to przez ostatnie 2 lata było tego sporo - pracowałem przy streamingu danych i np. pilnowanie zsynchronizowanego stanu oraz wydajność była priorytetami.

Jeśli korzystasz z serwera HTTP, to korzystasz z wielowątkowości czy tego chcesz czy nie :)

W mobilkach masz zawsze sporo wątków do obsługi, zdarzało się nawet używać procesów oddzielnych w tej samej apce

Praktycznie w każdej aplikacji mobilnej, których trochę w życiu zrobiłem, kilku aplikacjach narzędziowych. W aplikacjach web, jak wiadomo też są wątki, ale można w miarę bezpiecznie udawać, że ich nie ma.

@Charles_Ray: a możesz rozwinąć myśl że jak używasz serwera HTTP to używasz wielowątkowości? Serio pytam, pytanie początkującego w serwerach.

Jakiś artykuł naprowadzający albo hasło do wyszukania?

Tak:

• testy systemowe/integracyjne
• generatory ruchu w systemie
• pipeline'y
• w amatorskich zabawach w gamedev