Ten blog jest częścią 1 z 2-częściowej serii, wyjaśniającej, czym są wirtualne wątki w Javie 19 , w jaki sposób wirtualne wątki mogą poprawić wydajność aplikacji, a na koniec kilka testów porównawczych przy użyciu wirtualnych wątków.

Co to są wątki wirtualne:

Ponieważ ChatGPT jest nowym Google , zapytajmy go o definicję „wirtualnych wątków w Javie19” (za każdym razem podawał inne i sensowne definicje, brawo dla twórców tego cuda!!!)

Wirtualne wątki to rodzaj lekkich wątków w Javie 19. Wirtualne wątki umożliwiają użytkownikom tworzenie dużej liczby wątków, bez narzutu związanego z tradycyjnymi wątkami. Wirtualne wątki są zarządzane przez Wirtualną Maszynę Javy, dzięki czemu mogą być ponownie wykorzystywane w razie potrzeby i umożliwiają znaczną poprawę wydajności w porównaniu z tradycyjnymi wątkami natywnymi.

Dla miłośników GoLanga wirtualne wątki do rutyny to nic innego jak „Brat z innej matki ”

Dlaczego wirtualne wątki są przydatne

Wirtualne wątki Java różnią się od wątków oryginalnej platformy w tym sensie, że są znacznie lżejsze pod względem ilości zasobów (RAM), których wymagają od systemu do działania . Dzięki temu w aplikacjach można uruchomić znacznie więcej wątków wirtualnych niż wątków platformy. Przez cały czas, zapewniając pełne korzyści z normalnego wątku platformy.

Wykorzystanie wirtualnych wątków

Tworzenie wirtualnego wątku w Javie jest podobne do tworzenia konwencjonalnego wątku Runnable. Będziemy jednak używać klasy Executors do tworzenia newVirtualThreadPerTaskExecutor (), który uruchamia nowy wirtualny wątek dla każdego zadania. Liczba wątków tworzonych przez Executora jest nieograniczona.

Test

W tym teście będę dzwonić do usługi zewnętrznej (której odpowiedź zajmuje 1 milisekundę) i wykonywać operację milion razy, używając zarówno konwencjonalnej platformy, jak i wątków wirtualnych.

Cel:
Porównanie czasu potrzebnego wątkom wirtualnym i wątkom konwencjonalnym na wykonanie operacji 1 milion razy.
Specyfikacja maszyny: 10 rdzeni, 16 GB pamięci.

Kod :

Konwencjonalne nici

Mogłem już używać maksymalnie 1000 wątków i otrzymywał błąd OOM.

Wirtualne wątki

Wyniki :

Poniżej przedstawiono użycie procesora + czas potrzebny na wykonanie 10 razy zewnętrznej pętli for w obu podejściach.

Konwencjonalne nici

Wirtualne wątki

Wniosek :

Różnica czasu b/w użycia wątków konwencjonalnych i wirtualnych daje nam wyraźnego zwycięzcę korzystania z wątków wirtualnych w przypadku, gdy czekamy na jakąś usługę zewnętrzną. Jeśli ekstrapolujemy ten przykład na 10 milionów lub 100 milionów wywołań, różnica staje się znacznie większa, a wirtualne wątki okazują się mieć lepszą wydajność, gdy aplikacja jest zaangażowana w oczekiwanie na jakąś zewnętrzną aplikację.

W przykładzie naśladowano wywołanie usługi zewnętrznej za pomocą funkcji Thread.sleep(), którą można zastąpić rzeczywistym wywołaniem usługi zewnętrznej. Pozostawiamy to jako ćwiczenie dla czytelnika. ZRÓB TO!!!

UWAGA: Prawdą jest, że metodą prób i błędów możemy zoptymalizować liczbę tworzonych konwencjonalnych wątków, chociaż nie będzie możliwe przewidzenie idealnej liczby wątków dla każdego przypadku użycia (jeśli losowo zachowasz pulę z większą liczbą wątków , niepotrzebnie marnujesz zasoby aplikacji). Korzystanie z dynamicznej alokacji wątków (wątków wirtualnych) ma znacznie większy sens w rzeczywistej aplikacji.

Problemy z używaniem Wirtualnych Wątków

Powyższy przykład właśnie uświadomił Ci, że wirtualne wątki to gorący interes i aby przyspieszyć działanie aplikacji i optymalnie wykorzystać procesor, zawsze powinniśmy tworzyć wirtualne wątki.

Byle tylko nie wszystko miało swoje „ ALE ”.

Wirtualne wątki w Javie są świetne, ale w przypadku, gdy twoja aplikacja nie jest ograniczona we/wy, tj. Jeśli sam procesor musi wykonać ciężkie przetwarzanie (jak trenowanie modelu lub liczenie do 100 milionów), użycie wirtualnych wątków nie jest idealnym wyborem.

Szczegóły na ten temat zostaną podane w drugiej części tego artykułu. Czekać na dalsze informacje!!!

Końcowe przemyślenia

Wprowadzenie Java 19 do systemów jest wciąż w fazie rozwoju (ponieważ projekt Loom jest na razie tylko w fazie podglądu), chociaż spodziewamy się ogromnej poprawy w zarządzaniu serwerem, krótszych czasów odpowiedzi API i rzadszych problemów z OOM.

O autorze :

Yash Bansal jest zastępcą głównego inżyniera w firmie RedBus. Więcej informacji o nim można znaleźć na jego profilu na LinkedIn .