Projekt Loom – głównym celem jest obsługa lekkiego modelu współbieżności w Javie. Nie ma jeszcze tego dostępnego w Javie. Przede wszystkim możemy jednak uzyskać dostęp do prototypów na wiki tego projektu.
Dlatego w Javie obecnie polegamy na klasie Thread, który tak naprawdę jest mapowany na wątek systemu operacyjnego.
Wady takiego rozwiązania:
- droższe tworzenie wątków (czas i pamięć)
- nie tanie przełączanie pomiędzy tymi wątkami
- limit wątków
Problem ten, że wątki java’owe są przywiązane do wątków systemu aktualnie rozwiązywany jest poprzez tworzenie puli wątków. Musimy wkładać możliwe małe zadania, ponieważ musimy później te zadania łączyć i synchronizować, jednak nie jest to łatwe.
Kolejnym problemem są spowalniające operacje blokujące. Są to operacje związane z operacjami wejścia/wyjścia np. czekamy na dostępność bajtów na sockecie albo gdy czekamy na to aż dysk twardy zwróci dane, ponieważ podczas wykonywania ich wątki się marnują.
Ten z kolei problem możemy rozwiązać przy pomocy dwóch puli, ponieważ nie jest to łatwe do implementacji.
Dlatego, aby rozwiązać te problemy możemy użyć CompletableFuture.
Zalety:
- prosty do tworzenia
- łatwy do przełączania
- nielimitowany
Przykład z CompletableFuture:
![]()
![]()
![]()
Natomiast niestety ma też wady:
- tracimy na czytelności jeżeli operacje wykonujemy sekwencyjnie
- gubimy kontekst wyrzucania wyjątków(nie mamy dokładnego stack trace’a)
- musimy konsekwentnie zwracać CompletableFuture przy skomplikowanej logice
Przy wywoływaniu operacji równolegle często lepszym pomysłem będzie wykorzystanie CompletableFuture.
Przykład wywoływania sekwencyjnych operacji. Wygląda źle. Przede wszystkim źle się czyta.
![]()
![]()
![]()
W projekcie Loom możemy wykorzystywać wirtualne wątki. Ponieważ nie są one powiązane z systemem operacyjnym, dlatego nie ma wad z tym związanych.
Dlatego możemy go stworzyć poprzez metodę Thread.startVirtualThread()
Uwaga! Projekt Loom daje nam ważną rzecz. Piszemy kod, który wygląda jak zwykły blokujący się kod, natomiast pod spodem jest nieblokujący. ponieważ operacje wejścia/wyjścia nie są blokujące. Dlatego jest to domyślnie obsługiwane w tle.
Przy wykorzystaniu Projektu Loom otrzymujemy zwykły stack trace, nie jak w przypadku, gdy przede wszystkim korzystamy z CompletableFuture.
Dlatego w zależności od przypadku będziemy wybierać czy korzystamy z CompletableFuture czy Projektu Loom. Jakie rozwiązanie najlepiej pasuje do danej sytuacji.
A Tobie podoba się Projekt Loom?
Źródło:
https://www.youtube.com/watch?v=INr4Q9Rs8RA



