Historia pytania
Java PhantomReference została wprowadzona, aby rozwiązać fatalne wady Object.finalize(), które powodowały nieprzewidywalne opóźnienia i zagrożenia związane z odrodzeniem podczas zbierania śmieci. Wczesni projektanci JVM dążyli do stworzenia mechanizmu umożliwiającego wykrycie, kiedy obiekt staje się niedostępny, bez przywracania go do życia lub blokowania kolektora. Doprowadziło to do koncepcji odniesienia fantomowego, w którym samo odniesienie pełni rolę tokena powiadomienia, a nie środka dostępu do obiektu.
Problem
W przeciwieństwie do SoftReference lub WeakReference, wywołanie get() na PhantomReference bezwarunkowo zwraca null, nawet przed zebraniem obiektu. Taki projekt celowo odcina dostęp do referenta, aby zapobiec przypadkowemu przywracaniu obiektu przez programistę podczas finalizacji. W konsekwencji nie można bezpośrednio badać stanu obiektu ani wyzwalać logiki czyszczenia za pośrednictwem instancji odniesienia, co tworzy paradoks: wiesz, że obiekt ma zostać zebrany, ale nie możesz na niego działać.
Rozwiązanie
ReferenceQueue działa jako kanał komunikacyjny, w którym JVM dodaje instancję PhantomReference po tym, jak referent został sfinalizowany i jest gotowy do zbierania. Poprzez ciągłe sprawdzanie lub blokowanie na tej kolejce, wątek w tle odbiera obiekt odniesienia i wykonuje logikę czyszczenia związanych zasobów natywnych. To oddziela rekultywację zasobów od krytycznej ścieżki kolektora śmieci, eliminując opóźnienia związane z finalizacją, a jednocześnie zapewniając, że pamięć poza stertą lub uchwyty plików są szybko zwalniane.
Wyobraź sobie aplikację do handlu o wysokiej częstotliwości, która przydziela terabajty pamięci poza stertą za pomocą ByteBuffer.allocateDirect() do operacji sieciowych bez kopiowania. Pamięć natywna związana z tymi buforami nie jest zarządzana przez stertę Javy, jednak standardowe instancje Cleaner mogą być niewystarczające, jeśli aplikacja wymaga niestandardowej ewidencji zasobów lub czyszczenia współdzielonej pamięci między procesami. Zespół deweloperski potrzebował solidnego mechanizmu zapobiegającego wyciekom pamięci natywnej, gdy traderzy zapomnieli jawnie zamknąć bufory w czasie niestabilnych warunków rynkowych.
Rozwiązanie 1: Nadpisanie finalizacji
Jednym podejściem jest rozszerzenie ByteBuffer i nadpisanie finalize() w celu wywołania procedur Unsafe do dealokacji pamięci. Choć wydaje się to proste, wprowadza poważne wzrosty opóźnień podczas zdarzeń Full GC, ponieważ finalizacja wymaga dwóch cykli zbierania i blokuje wątki. Dodatkowo ryzyko odrodzenia stwarza luki w zabezpieczeniach, jeśli zfinalizowany obiekt odnosi się do stanu zewnętrznego.
Rozwiązanie 2: Jawne bloki try-with-resources
Programiści mogą wymusić rygorystyczne bloki try-with-resources dla każdego przydziału buforów, zapewniając natychmiastowe wywołania close(). To całkowicie eliminuje zależność od GC i zapewnia deterministyczne czyszczenie, ale polega na doskonałej dyscyplinie programisty. W dużej bazie kodu z asynchronicznymi wywołaniami zwrotnymi, zapomniane wywołania zamknięcia prowadzą do kumulacyjnych wycieków pamięci natywnej, które mogą zawiesić JVM, gdy system operacyjny odmawia dalszych alokacji.
Rozwiązanie 3: PhantomReference z monitorowaniem ReferenceQueue
Zespół wdrożył dedykowaną ReferenceQueue, którą sprawdza wątek demona, śledzący niestandardowe podklasy PhantomReference przechowujące adresy natywne. Gdy GC ustali, że bufor jest niedostępny, odniesienie trafia do kolejki, co wyzwala natychmiastową dealokację natywną bez blokowania zbierania. To podejście zostało wybrane, ponieważ przetrwa błędy programisty, jednocześnie utrzymując pauzy GC poniżej milisekundy, co jest krytyczne dla algorytmów handlowych.
Rezultat
System przetrwał 50 000 alokacji na sekundę bez OutOfMemoryError w regionach sterty natywnej, redukując czasy pauz GC z 200 ms do jednorodnych 5 ms operacji. Wątek w tle zużywał mniej niż 1% zasobów CPU, udowadniając, że monitorowanie odniesienia fantomowego lepiej skaluje się niż finalizacja dla aplikacji wymagających zasobów. Profilowanie pamięci potwierdziło zerowe wycieki pamięci natywnej podczas 72-godzinnych testów obciążeniowych.
Dlaczego PhantomReference.get() zwraca null z zamiarem, a nie referent?
To zachowanie zapobiega odrodzeniu obiektów dostępnych fantomowo. Gdyby get() zwracało obiekt po oznaczeniu go przez kolektor do finalizacji, programista mógłby przechować silne odniesienie w polu statycznym, przywracając go do aktywnego użycia. Naruszyłoby to invariant kolektora, zgodnie z którym obiekty dostępne fantomowo są już sfinalizowane i gotowe do rekultywacji, co potencjalnie prowadziłoby do błędów użycia po zwolnieniu w kodzie natywnym lub sceneriach podwójnej finalizacji.
Jak API Cleaner różni się od ręcznego zarządzania PhantomReference i ReferenceQueue?
Cleaner to w zasadzie wygodne opakowanie wokół PhantomReference, ReferenceQueue i dedykowanego wątku systemowego wprowadzonego w Javie 9. Chociaż podstawowy mechanizm pozostaje identyczny, Cleaner abstrahuje zarządzanie cyklem życia wątku i obsługę wyjątków, automatycznie usuwając odniesienie po wykonaniu akcji czyszczącej. Ręczne zarządzanie oferuje kontrolę nad priorytetem wątku i strategiami sprawdzania kolejki, ale Cleaner zapobiega typowym błędom, takim jak zapomnienie o usunięciu odniesienia z kolejki, co mogłoby prowadzić do wycieków pamięci w samym zbiorze odniesień.
Co się stanie, jeśli ReferenceQueue nie jest wystarczająco często sprawdzane podczas korzystania z PhantomReference?
Każda instancja PhantomReference konsumuje pamięć (około 32-64 bajty), dopóki nie zostanie jawnie usunięta z kolejki i nie zostanie z niej usunięta. Jeśli wątek konsumencki się zaciął lub zawiódł, kolejka zatyka się w nieskończoność, tworząc wyciek odniesienia, który ostatecznie wyczerpuje stertę Javy, mimo że referenty są zbierane. W przeciwieństwie do referenta, obiekt odniesienia sam w sobie jest silnym obiektem zakotwiczonym w kolejce, wymagającym jawnego czyszczenia, aby uniknąć błędów braku pamięci w długotrwałych usługach.