Jak zawsze, długi opis problemu.

Obecnie testujemy nasz produkt pod wpływem stresu - teraz mamy dziwny problem. Po jednej do dwóch godzin przestrzeń sterty zaczyna rosnąć, aplikacja umiera później.

Profilowanie aplikacji pokazuje bardzo dużą liczbę obiektów Finalizer, wypełniając stertę. Pomyśleliśmy, że „może to być dziwny wątek zwalniający finalizator” i przejrzeliśmy, aby zmniejszyć liczbę obiektów, które muszą zostać sfinalizowane (w tym przypadku rodzime uchwyty JNA). Dobry pomysł i zmniejszył tysiące nowych obiektów ...

Kolejne testy pokazały ten sam wzór, tylko godzinę później i nie tak stromo. Tym razem finalizatory pochodzą ze strumieni FileInput- i FileOutput, które są mocno wykorzystywane w testbedu. Wszystkie zasoby są zamknięte, ale finalizery nie są już czyszczone.

Nie mam pojęcia, dlaczego po 1 lub 2 godzinach (bez wyjątków) FinalizerThread nagle przestaje działać. Jeśli zmusimy System.runFinalization () ręcznie do niektórych naszych wątków, profiler pokaże, że finalizatory są czyszczone. Wznowienie testu powoduje natychmiastowe przydzielenie sterty dla finalizatorów.

FinalizerThread nadal tam jest, pytając jConsole, że CZEKA.

EDYTOWAĆ

Po pierwsze, sprawdzenie sterty za pomocą HeapAnalyzer nie ujawniło niczego nowego / dziwnego. HeapAnalyzer ma kilka ciekawych funkcji, ale początkowo miałem trudności. Używam jProfiler, który przychodzi wraz z ładnymi narzędziami do kontroli sterty i pozostanie z nim.

Może brakuje mi zabójczych funkcji w HeapAnalyzer?

Po drugie, dzisiaj przeprowadzamy testy z połączeniem debugującym zamiast z profilerem - system jest stabilny już prawie 5 godzin. Wydaje się, że jest to bardzo dziwna kombinacja zbyt wielu Finalizerów (które zostały zredukowane w pierwszym przeglądzie), profilera i strategii VM GC. Ponieważ w tej chwili wszystko jest w porządku, żadnych prawdziwych spostrzeżeń ...

Dziękuję za dotychczasowy wkład - być może jesteście czujni i zainteresowani (teraz, gdy macie więcej powodów, by sądzić, że nie rozmawiamy przez zwykły błąd programowania).