Przed Java 9, uzyskanie programowego dostępu do stosu wykonawczego wymagało albo utworzenia Throwable (co natychmiastowo ładowało cały stos w tablicy), albo użycia metody SecurityManager.getClassContext() (która była ograniczona przez polityki bezpieczeństwa i podobnie kosztowna). Te podejścia zmuszały programistów do ponoszenia pełnego kosztu przechodzenia przez stos, nawet gdy potrzebna była tylko górna ramka lub konkretny wywołujący, co znacząco ograniczało możliwości użycia API wrażliwych na wywołania w krytycznych ścieżkach kodu.
Fundamentalny problem z eager capture to jego O(n) złożoność w stosunku do głębokości stosu oraz obowiązkowa alokacja tablic StackTraceElement, co generuje znaczną presję na GC w ramach frameworków logujących, bibliotek serializacji i narzędzi debugujących, które często introspekcjonują miejsca wywołania. Ponadto, Throwable.fillInStackTrace przechwyca ukryte ramki (metody natywne, infrastruktura refleksji), które kod aplikacji zazwyczaj chce zignorować, co wymaga dodatkowego przetwarzania filtrującego na już zmaterializowanych danych. To natychmiastowe realizowanie uniemożliwia JVM optymalizację ramek, które nigdy nie są inspekcjonowane przez aplikację.
StackWalker (wprowadzony w Java 9) ujawnia abstrakcję Stream<StackFrame>, gdzie JVM leniwie materializuje ramki tylko wtedy, gdy końcowa operacja strumienia ich wymaga, w połączeniu z filtrowaniem oparte na predykacie, które działa na poziomie VM przed alokacją Object. Implementacja wykorzystuje wewnętrzne prymitywy do przechodzenia przez stos rama po ramie, zatrzymując się natychmiast, gdy dostarczony przez użytkownika Predicate<StackFrame> zwraca fałsz, unikając alokacji dla pomijanych ramek i zapewniając złożoność O(k), gdzie k to liczba inspekcjonowanych ramek, a nie całkowita głębokość. W odróżnieniu od Throwable, który tworzy niemutowalny zrzut w momencie utworzenia, StackWalker zapewnia aktywny widok, który odzwierciedla dokładny stan stosu wątku w momencie przechodzenia przez strumień.
Wyobraź sobie rozwijanie frameworka RPC o wysokiej przepustowości, w którym każde przychodzące żądanie musi zweryfikować, że wywołująca klasa pochodzi z zatwierdzonego modułu przed deserializacją argumentów. W pierwszej implementacji używano new Throwable().getStackTrace() do identyfikacji najbliższego wywołującego, ale podczas testów obciążeniowych z 10 000 równoczesnymi żądaniami usługa wykazywała poważne skoki latencji i częste OutOfMemoryError z powodu ogromnej alokacji tablic śladowych. Profiling ujawnił, że niemal 40% alokowanych bajtów pochodziło z tych zabezpieczeń, co sprawiało, że podejście było nieopłacalne do wdrożenia w produkcji.
Zespół najpierw rozważył wykorzystanie SecurityManager.getClassContext(), które zwraca tablicę kontekstu klasy bez kosztów parsowania ciągów. Chociaż unika to kosztów związanych z wypełnianiem ciągów śladowych, nadal wymaga, aby SecurityManager był zainstalowany z podwyższonymi uprawnieniami, co komplikuje wdrożenie w środowiskach o ścisłych politykach bezpieczeństwa, i przechwytuje całą tablicę klas bez względu na potrzebę, nie rozwiązując problemu złożoności O(n). Ponadto, to podejście jest przestarzałe i jest usuwane w nowoczesnych wersjach Javy, co czyni je słabą inwestycją na dłuższą metę w kodzie.
Inną alternatywą było utrzymanie statycznej Map<Class<?>, Boolean> wypełnianej przy starcie poprzez skanowanie ścieżki klas w celu uniknięcia introspekcji w czasie wykonywania. Ta strategia eliminuje alokację per żądanie i zapewnia wydajność wyszukiwania O(1), ale nie uwzględnia dynamicznego generowania kodu za pomocą Proxy lub MethodHandle, które tworzy legalne klasy wywołujące nieznane w czasie startu, prowadząc do fałszywych odrzuceń bezpieczeństwa i wymagając skomplikowanej logiki unieważniania pamięci podręcznej. Ponadto, ślad pamięci wynikający z przechowywania każdej możliwej klasy wywołującej staje się prohibicyjny w dużych aplikacjach z tysiącami załadowanych klas.
Inżynierowie ostatecznie wybrali StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE).walk(stream -> stream.skip(2).findFirst().map(StackFrame::getDeclaringClass).orElse(null)), która leniwie ocenia tylko pierwsze dwie ramki i zwraca odwołanie do klasy bez alokacji pośrednich tablic. To podejście zostało wybrane, ponieważ równoważy optymalną wydajność przy minimalnej złożoności kodu, a także prawidłowo obsługuje dynamicznie generowane klasy bez wcześniejszej rejestracji, a działając w całości w standardowych API bez zależności od menedżera zabezpieczeń, zapewnia kompatybilność z przyszłością w miarę dalszej ewolucji Javy w kierunku modeli bezpieczeństwa minimalnych uprawnień.
Po wdrożeniu, narzut na każde żądanie do weryfikacji wywołującego spadł z około 450 bajtów alokacji i 2 mikrosekund do niemal zerowej alokacji i 20 nanosekund, skutecznie eliminując presję GC z gorącej ścieżki zabezpieczeń. Testy obciążeniowe potwierdziły, że usługa mogła utrzymać pełne obciążenie 10 000 równoczesnych żądań bez skoków latencji, a zrzuty sterty zweryfikowały brak akumulacji tablic StackTraceElement. Rozwiązanie okazało się solidne w różnych stosach wywołań, w tym w wywołaniach refleksyjnych i opartych na MethodHandle, gdy skonfigurowano je z odpowiednimi predykatami filtrującymi.
Dlaczego StackWalker zwraca strumień, który może być przechodzony tylko raz w ramach metody walk, i jakie zagrożenie współbieżności powstaje, jeśli ktoś spróbuje zbuforować i ponownie wykorzystać ten strumień w wielu wywołaniach?
Stream zwrócony przez StackWalker.walk jest oparty na aktywnym, zmiennym widoku aktualnego stosu wątku, który jest ważny tylko przez czas wykonywania wywołania zwrotnego walk. Gdy wywołanie zwrotne się zakończy, JVM zwalnia bufor ramek natywnych, przez co wszelkie zbuforowane odniesienia do strumienia stają się bezużyteczne i powodują rzucenie IllegalStateException przy kolejnych dostępach. Kandydaci często błędnie zakładają, że StackWalker tworzy zrzut jak Throwable, ale w rzeczywistości dostarcza przejrzysty widok stanu wykonania wątku, co oznacza, że jeśli strumień zostanie przekazany do innego wątku lub zapisany w polu, jednoczesne modyfikacje stosu mogą ujawniać niespójne stany ramek lub spowodować awarię VM, gdyby nie rygorystyczne egzekwowanie zakresu.
Jak opcja RETAIN_CLASS_REFERENCE zmienia wewnętrzną reprezentację ramek, i dlaczego jej brak zmusza do używania Class.forName z potencjalnymi błędami powiązania podczas inspekcji ramek?
Bez RETAIN_CLASS_REFERENCE, StackWalker optymalizuje, przechowując tylko nazwę klasy jako ciąg, nazwę metody i numer linii w StackFrame, unikając potrzeby rozwiązywania obiektu Class, co mogłoby wywołać ładowanie lub inicjalizację klasy. Jednak oznacza to, że StackFrame.getDeclaringClass() jest niedostępne, a wywołujący muszą używać Class.forName(frame.getClassName()), co może spowodować ClassNotFoundException lub NoClassDefFoundError, jeśli ładowarka klasy z przechodzonej ramki nie jest ładowarką wywołującego. Gdy RETAIN_CLASS_REFERENCE jest określone, VM przypina obiekty Class podczas przechodzenia, zapewniając, że pozostają one dostępne i eliminując koszt wyszukiwania, ale to uniemożliwia przejście przez ramki refleksyjne, które mogą odnosić się do klas, których sama przechodząca nie może załadować.
Jaka subtelna różnica behawioralna istnieje między StackWalker.walk a Thread.getStackTrace pod względem uwzględnienia metod natywnych i stawów refleksyjnych, i jak opcja SHOW_HIDDEN_FRAMES współdziała z wywołaniami MethodHandle?
Thread.getStackTrace i Throwable.getStackTrace zarówno domyślnie filtrują ukryte ramki implementacji (takie jak adaptery MethodHandle, mosty refleksyjne i stawy natywne), aby zaprezentować czysty widok aplikacji. StackWalker z domyślnymi opcjami również ukrywa te ramki, ale oferuje SHOW_HIDDEN_FRAMES, aby ujawnić pełny fizyczny stos w tym ramach powiązań MethodHandle, co jest kluczowe podczas przechodzenia przez stos w celu weryfikacji uprawnień w łańcuchach wywołań związanych z MethodHandle lub VarHandle. Kandydaci często nie dostrzegają, że pominięcie SHOW_HIDDEN_FRAMES może pominąć rzeczywiste wywołujące, które są wrażliwe na bezpieczeństwo, jeśli łańcuch wywołań związuje się, podczas gdy uwzględnienie go wymaga, aby logika predykatu explicite filtrowała syntetyczne ramki, aby uniknąć błędnej identyfikacji wywołującego.