Wątki wirtualne w Project Loom działają jako kontynuacje umieszczone na wątkach nośnych pochodzących z ForkJoinPool. Gdy wątek wirtualny napotyka blok synchronized lub wykonuje kod natywny, przypina swój podstawowy wątek nośny, uniemożliwiając schedulerowi odmontowanie wątku wirtualnego podczas blokujących operacji I/O. To skutecznie redukuje stopień współbieżności do rozmiaru puli nośnej (zwykle równej liczbie rdzeni CPU), co może prowadzić do załamania przepustowości pod obciążeniem, ponieważ skonfliktowane wątki wirtualne monopolizują stałą pulę nośną.
Firma świadcząca usługi finansowe przeniosła swoją legacy'ową bramę przetwarzania zamówień z tradycyjnego modelu wątków na żądanie Tomcat (ograniczonego do 500 wątków platformy) do Jetty z wątkami wirtualnymi, oczekując obsługi 50 000 jednoczesnych połączeń WebSocket. Natychmiast po wdrożeniu, mimo przyjęcia wątków wirtualnych, opóźnienie wzrosło do sekund, a przepustowość osiągnęła jedynie 800 TPS podczas zmienności otwarcia rynku. Zrzuty wątków ujawniły, że wszystkie 24 wątki nośne utknęły w stanie BLOCKED wewnątrz bloków synchronized, podczas gdy tysiące wątków wirtualnych czekały na I/O, nie mogąc kontynuować.
Pierwszym rozważanym rozwiązaniem było zwiększenie równoległości ForkJoinPool za pomocą -Djdk.virtualThreadScheduler.parallelism do 1000. To zapewniłoby więcej wątków nośnych do obsługi przypiętego obciążenia, skutecznie powracając do zachowania dużej puli wątków platformy. Jednak to podejście jedynie maskuje podstawową wadę architektoniczną, konsumując nadmiar zasobów systemu operacyjnego i niweczy korzyści z efektywności pamięci, które obiecuje wirtualizacja wątków.
Drugie rozwiązanie polegało na refaktoryzacji wszystkich bloków synchronized, które chroniły wspólne cache'e limitujące w użyciu, aby zamiast tego stosować ReentrantLock. W odróżnieniu od wbudowanych monitorów, ReentrantLock integruje się z harmonogramem wątków wirtualnych, umożliwiając odmontowanie podczas kontencji lub blokujących operacji bez przypinania nośnika. To podejście zachowuje lekkość wątków wirtualnych, ale wymaga systematycznego audytu bazy kodu i starannego zarządzania semantyką przerywania blokady.
Trzecie rozwiązanie zaproponowało zastąpienie współbieżnych pamięci podręcznych mapami haszującymi bez blokad, takimi jak metody obliczeniowe ConcurrentHashMap lub StampedLock dla optymistycznych odczytów. Chociaż to eliminuje blokowanie dla wielu ścieżek odczytu, nie rozwiązują one scenariuszy wymagających wyłącznego dostępu do stanowych zasobów zewnętrznych, takich jak sekwencje wypożyczania połączeń z bazą danych, które z natury wymagają wzajemnego wykluczenia.
Zespół wybrał drugie rozwiązanie, priorytetowo traktując celowaną migrację pięćdziesięciu krytycznych sekcji synchronized do ReentrantLock po profilowaniu, które zidentyfikowało je jako punkty przypinania. Ten wybór bezpośrednio rozwiązywał pierwotną przyczynę, pozwalając schedulerowi na odmontowanie wątków wirtualnych podczas kontencji, bez zmiany podstawowej logiki biznesowej aplikacji lub zwiększenia wykorzystania pamięci.
Po refaktoryzacji i ponownym wdrożeniu, system osiągnął docelowe 50 000 jednoczesnych połączeń z stabilnym opóźnieniem p99 poniżej 100 ms. Pula wątków nośnych pozostała na domyślnym rozmiarze 24 (równym rdzeniom CPU), co pokazuje, że wątki wirtualne dostarczają prawdziwej skalowalności tylko wtedy, gdy kod unika przypinania nośników za pomocą synchronizacji wewnętrznej.
// Przed: Przypinanie wątku nośnego synchronized (rateLimiter) { // Wątek wirtualny nie może zostać odmontowany, jeśli jest zablokowany tutaj externalApi.call(); } // Po: Umożliwia odmontowanie rateLimiter.lock(); try { // Wątek wirtualny odmontowuje się, zwalniając nośnik externalApi.call(); } finally { rateLimiter.unlock(); }
Dlaczego przypinanie występuje szczególnie w blokach synchronized i metodach natywnych, podczas gdy ReentrantLock pozwala na odmontowanie?
Przypinanie występuje, ponieważ JVM implementuje wbudowane monitory (synchronized) przy użyciu rekordów monitorów opartych na stosie wątku oraz wewnętrznych struktur VM na poziomie C++, które są z natury związane z kontekstem wykonania fizycznego wątku OS. Gdy wątek wirtualny wchodzi do bloku synchronized, JVM nie może bezpiecznie przenieść kontynuacji do innego nośnika bez uszkodzenia stanu monitora lub naruszenia gwarancji happens-before na poziomie natywnym. W przeciwieństwie do tego, ReentrantLock jest zaimplementowany wyłącznie w Javie na podstawie AbstractQueuedSynchronizer, który używa prymitywów VarHandle i LockSupport.park, na które nakłada się harmonogram wątków wirtualnych, co pozwala na bezpieczne odmontowanie i ponowne zamontowanie przez nośniki bez zależności od stanu wątku natywnego.
Jak przypinanie wątku nośnego współdziała z metodą kradzieży pracy ForkJoinPool, aby stworzyć potencjalne scenariusze głodu?
W normalnym działaniu, ForkJoinPool zakłada, że zadania są związane z CPU lub nieblokujące; gdy wątek roboczy blokuje, kompensuje to, uruchamiając lub aktywując dodatkowych pracowników do limitu równoległości. Jednak przypięty wątek wirtualny blokuje swój nośnik, skutecznie nie sygnalizując mechanizmu rekompensaty puli. W rezultacie, jeśli dwadzieścia wątków wirtualnych jednocześnie przypina dwadzieścia nośników (na przykład, wchodząc do bloków synchronized), nie ma nośników, które mogłyby wykonać tysiące gotowych wątków wirtualnych w kolejce w schedulerze. To tworzy inwersję priorytetów, w której niezablokowana praca nie może postępować, mimo dostępnych zadań, skutecznie zmniejszając rozmiar użytej puli dynamicznie i katastrofalnie.
Czy agresywne wykorzystanie zmiennych ThreadLocal może powodować przypinanie wątku nośnego w środowiskach wątków wirtualnych?
ThreadLocal nie wywołuje przypinania, ponieważ implementacja wątków wirtualnych przenosi mapę lokalnych zmiennych wątkowych między nośnikami podczas operacji montowania i odmontowywania. Jednak kandydaci często przeoczają, że ThreadLocal stwarza odrębny kataklizm zarządzania pamięcią: gdy miliony wątków wirtualnych krótkotrwałych dotykają lokalnych zmiennych wątkowych, każdy wątek nośny gromadzi wpisy w swojej ThreadLocalMap dla każdego wątku wirtualnego, który kiedykolwiek hostował. Ponieważ te mapy są czyszczone tylko po eksplicytnej eliminacji lub zbiorczej kolekcji klucza (wątku wirtualnego), generuje to nieograniczony wzrost pamięci w długo działających wątkach nośnych. To skutecznie stanowi wyciek pamięci niezwiązany z przypinaniem, ale równie katastrofalny dla wdrożeń wątków wirtualnych na dużą skalę, wymagając migracji do ScopedValue (JEP 446) dla odpowiedniego oczyszczenia.