Historia pytania
Przed Java 5, koordynacja wątków opierała się na prymitywnych metodach jak Thread.suspend (przestarzała z powodu wrodzonych ryzyk martwego bloku) lub Object.wait/notify, które wymagały ścisłego posiadania monitora i cierpiały na utratę obudzeń, gdy powiadomienie wystąpiło przed czekaniem. Wraz z wprowadzeniem java.util.concurrent w Java 5 (JSR 166), LockSupport został zaprojektowany jako niskopoziomowy prymityw blokujący, umożliwiający budowę wysokowydajnych synchronizatorów takich jak AbstractQueuedSynchronizer, bez obciążenia związanym z wbudowanymi blokadami.
Problem
W programowaniu równoległym klasycznym warunkiem wyścigu jest sytuacja, gdy wątek sygnalizujący wywołuje mechanizm unpark przed tym, jak docelowy wątek faktycznie parkuje. W przypadku tradycyjnych zmiennych warunkowych ten sygnał byłby utracony, co powodowałoby, że wątek docelowy zasypiałby na czas nieokreślony. Naiwnym rozwiązaniem mogłoby być wykorzystanie semafora liczącego do akumulacji pozwoleń, jednak wprowadzałoby to niepotrzebną złożoność i potencjalne wycieki zasobów, jeśli producent wyprzedzałby konsumenta.
Rozwiązanie
LockSupport korzysta z nieakumulującego, jednobitowego pozwolenia przypisanego do każdego wątku. To pozwolenie działa jak jednorazowy, lokalny bilet dostępu:
Ponieważ pozwolenie nie jest kumulacyjne (saturuje się na 1), zapobiega to wyciekom pamięci z powodu nadmiernego unparkowania, zapewniając jednocześnie, że jedno unpark wydane przed parkiem zostanie zapamiętane, eliminując w ten sposób problem utraty obudzenia przez relację happens-before.
import java.util.concurrent.locks.LockSupport; public class PermitExample { public static void main(String[] args) throws InterruptedException { Thread worker = new Thread(() -> { System.out.println("Worker: Wstępna praca..."); try { Thread.sleep(100); } catch (InterruptedException e) {} System.out.println("Worker: Próba parkowania..."); LockSupport.park(); System.out.println("Worker: Pomyślnie odparkowany!"); }); worker.start(); // Sygnalizuj przed tym, jak wątek roboczy rzeczywiście parkuje Thread.sleep(50); System.out.println("Main: Wywołanie unpark przed parkowaniem wątku roboczego"); LockSupport.unpark(worker); worker.join(); } }
Opis problemu
Podczas projektowania silnika dopasowywania zleceń w systemie handlu wysokiej częstotliwości potrzebowaliśmy mechanizmu przeciążeniowego, w którym wątki konsumentów mogłyby wstrzymać przetwarzanie, gdy kolejka przychodząca osiągnęła pojemność, bez trzymania blokad, które uniemożliwiałyby producentom sprawdzanie stanu kolejki. Standardowy ReentrantLock z Condition powodował kontencję na blokadzie kolejki podczas sygnalizacji, a Object.wait/notify cierpiało na ryzyko utraty obudzeń podczas wyścigów o dużej rotacji.
Różne rozważane rozwiązania
1. Object.wait/notifyAll
To podejście korzystało z wbudowanej blokady kolejki. Plusy: Proste do zaimplementowania z użyciem standardowych monitorów. Minusy: Wymagało, aby producent zdobył monitor, aby zwołać powiadomienie, co tworzyło wąskie gardło serializacji. Co gorsza, jeśli producent wywołałby powiadomienie w krótkim czasie między sprawdzaniem rozmiaru kolejki przez konsumenta a wywołaniem wait, sygnał byłby utracony, co prowadziłoby do trwałego martwego bloku konsumenta.
2. ReentrantLock z wieloma warunkami
Próbowaliśmy używać oddzielnych warunków dla stanów "pełny" i "pusty". Plusy: Bardziej elastyczne niż wbudowane blokady, co pozwala na selektywne obudzenia. Minusy: Wciąż wymagało zdobycia blokady do sygnalizacji (signalAll), a złożoność poprawnego przenoszenia wątków między kolekturami warunkowymi wprowadzała dodatkowe obciążenia związane z konserwacją bez rozwiązania podstawowego przeciążenia blokadowego.
3. LockSupport z explicite atomowym stanem
Wybrane rozwiązanie korzystało z AtomicBoolean do reprezentowania „pozwolenia na kontynuację” oraz LockSupport do blokowania. Gdy kolejka się zapełniła, konsument atomowo ustawił flagę „needsParking” i następnie parkował. Producenci, po usunięciu elementu, sprawdzali flagę i wywoływali unpark, jeśli była ustawiona. Plusy: Sygnalizacja nie wymagała żadnych blokad, eliminując kontencję podczas obudzeń. Model jednobitowego pozwolenia zapewnił, że nawet jeśli producent wywołałby unpark nanosekundy przed tym, jak konsument wywołałby park (z powodu planowania CPU), obudzenie nie było utracone.
Wybrane rozwiązanie i wynik
Wybraliśmy podejście LockSupport. Oddzielając mechanizm sygnalizacji od strukturalnej blokady kolejki, zredukowaliśmy latencję producenta o 40% pod dużym obciążeniem i wyeliminowaliśmy scenariusze utraty obudzenia obserwowane podczas testów obciążeniowych. Jawne zarządzanie stanem (podwójne sprawdzanie warunku po unpark) zapewniło poprawność pomimo umowy o fałszywych obudzeniach park().
Czy LockSupport.park zwalnia posiadanie monitorów utrzymywanych przez wątek?
Nie. To jest krytyczna różnica w porównaniu do Object.wait(). Kiedy wątek wywołuje LockSupport.park, wchodzi w stan oczekiwania, ale zachowuje posiadanie wszystkich monitorów, które obecnie posiada. Jeśli inny wątek spróbuje wejść do jednego z tych monitorów (np. bloku zsynchronizowanego na tym samym obiekcie), zostanie zablokowany, co potencjalnie może prowadzić do martwego bloku, jeśli zablokowany wątek byłby jedynym, który mógłby to zwolnić. Kandydaci często błędnie zakładają, że park jest jak wait i zwalnia blokady; jest to czysto lokalny prymityw harmonogramu.
Jakie jest zachowanie LockSupport.park po wywołaniu na wątku, którego status przerwania jest ustawiony?
Metoda zwraca natychmiast bez blokowania i nie czyści statusu przerwania. To fundamentalnie różni się od Object.wait(), które czyści status przerwania i zgłasza InterruptedException. Z LockSupport wątek musi jawnie sprawdzić i wyczyścić status przerwania (za pomocą Thread.interrupted()), jeśli chce poszanować konwencje przerywania. Ten projekt pozwala na użycie park w kontekstach nieprzerywalnych lub tam, gdzie przerywanie jest traktowane jako osobna kwestia od pozwolenia na parkowanie.
Jak LockSupport radzi sobie z fałszywymi obudzeniami i jak to wpływa na wzorce kodowania?
LockSupport.park jest udokumentowane jako zwracające „bez powodu” (fałszywe obudzenie), chociaż w praktyce jest to rzadkie w nowoczesnych JVM. W przeciwieństwie do obudzenia opartego na pozwoleniu (unpark), fałszywe obudzenia nie konsumują pozwolenia. W związku z tym, wywołujący musi zawsze ponownie sprawdzić warunek, który spowodował parkowanie w pętli:
while (!canProceed()) { LockSupport.park(); }
Kandydaci często przeoczają, że po prostu sprawdzenie warunku raz po parku jest niewystarczające; wątek mógłby obudzić się fałszywie (lub z powodu przypadkowego przerwania) bez wywołania unpark, co wymaga ponownej oceny stanu. Pozwolenie zapewnia, że ważne unpark nie jest tracone, ale nie zapobiega fałszywym powrotom.