Długowieczna Jawa słaba

Obecnie próbuję zdiagnozować powolny wyciek pamięci w mojej aplikacji. Fakty, które mam do tej pory są następujące.

• mam zrzut sterty z 4-dniowego uruchomienia aplikacji.
• ten zrzut sterty zawiera ~800 obiektów WeakReference, które wskazują na obiekty (wszystkie tego samego typu, które będę nazywał Foo do celów tego pytania), zachowując 40mb pamięci.
• Eclipse Memory Analysis Tool pokazuje, że każdy z obiektów Foo, o których mowa przez te słabe o których nie wspominają żadne inne obiekty. Oczekuję, że dzięki temu Obiekty Foo będą słabo osiągalne i dlatego powinny zostać zebrane w następnym GC.
• każdy z tych obiektów Foo ma znacznik czasu, który pokazuje, że zostały przydzielone w trakcie 4-dniowego biegu. W tym czasie mam również logi, które potwierdzają, że miało miejsce zbieranie śmieci.
• ogromna liczba obiektów Foo jest tworzona przez moją aplikację i tylko bardzo mała ich część kończą w tym stanie na wysypisku śmieci. To sugeruje mi, że główną przyczyną jest jakiś stan rasy.
• Moja aplikacja używa JNI do połączenia z natywną biblioteką. Kod JNI wywołuje NewGlobalRef 4 razy podczas inicjalizacji początku dnia, aby uzyskać odniesienia do klas Java, których używa.

Co może spowodować, że te klasy Foo nie będą zbierane, mimo że będą odwoływane tylko przez słabe (według Eclipse Memory Analyser Narzędzie)?

EDIT1:

public class FooWeakRef extends WeakReference<Foo>
{
  public long longA;
  public long longB;
  public String stringA;

  public FooWeakRef(Foo xiObject, ReferenceQueue<Foo> xiQueue)
  {
    super(xiObject, xiQueue);
  }
}

Foo nie ma finalizera i żaden finalizer nie będzie brany pod uwagę, dopóki nie zostaną wyczyszczone słabe Refy. Obiekt nie jest finalizowalny, gdy jest słabo osiągalny. zobacz tę stronę po szczegóły .

@ kasten słabość jest czyszczona, zanim obiekt jest finalizowalny. Mój zrzut sterty pokazuje, że to nie stało się.

@jarnbjo odnoszę się do słabego Javadoc:

"Załóżmy, że garbage collector określa w pewnym momencie czasowym, że obiekt jest słabo osiągalny. W tym czasie będzie atomicznie wyczyścić wszystkie słabe odniesienia do tego obiektu i wszystkie słabe odniesienia do innych słabiej osiągalnych obiektów, z których ten obiekt jest osiągalny poprzez łańcuch silnych i miękkich odniesień."

Edycja 2

@j - wiem, że 40mb nie brzmi jak dużo, ale obawiam się, że 40mb w 4 dni oznacza 4000mb w 100 dni. Wszystkie dokumenty, które przeczytałem sugerują, że obiekty, które są słabo osiągalne, nie powinny wisieć przez kilka dni. Dlatego jestem zainteresowany wszelkimi innymi wyjaśnieniami na temat tego, w jaki sposób obiekt może być silnie odwołany bez odniesienia pojawiającego się w stercie wysyp.

Spróbuję przydzielić kilka dużych obiektów, gdy niektóre z tych zwisających obiektów Foo są obecne i zobaczę, czy JVM je zbiera. Jednak konfiguracja i ukończenie tego testu zajmie kilka dni.

Edycja 3

@jarnbjo-rozumiem, że nie mam gwarancji, kiedy JDK zauważy, że obiekt jest słabo osiągalny. Jednak spodziewałbym się, że wniosek pod dużym obciążeniem przez 4 dni zapewni wystarczająco dużo możliwości, aby GC zauważył że moje przedmioty są słabo osiągalne. Po 4 dniach jestem mocno podejrzliwy, że pozostałe słabo nawiązujące obiekty zostały jakoś wycieknięte.

Edycja 4

@j flemm-to naprawdę ciekawe! Tak dla jasności, czy mówisz, że GC dzieje się w Twojej aplikacji i nie czyści miękkich / słabych refów? Czy możesz mi podać więcej szczegółów na temat tego, czego używasz konfiguracji JVM + GC? Moja aplikacja używa paska pamięci na 80% sterty, aby uruchomić GC. Zakładałem, że każdy GC starego gen czyści słabe refy. Sugerujesz, że GC zbiera słabe refy tylko wtedy, gdy zużycie pamięci przekroczy wyższy próg? Czy ten wyższy limit można konfigurować?

Edycja 5

@j - twój komentarz o wyczyszczeniu WeakRefs przed SoftRefs jest zgodny z Javadoc który stwierdza: SoftRef: "Załóżmy, że garbage collector określa w pewnym momencie w czasie, że obiekt jest miękko osiągalny. W tym czasie to może wybrać wyczyścić atomicznie wszystkie miękkie odniesienia do tego obiektu i wszystkie miękkie odniesienia do wszelkich innych miękko osiągalnych obiektów, z których ten obiekt jest osiągalny poprzez łańcuch silnych odniesień. W tym samym czasie lub w późniejszym czasie zapyta o nowo wyczyszczone miękkie odniesienia, które są zarejestrowane w kolejkach referencyjnych."

WeakRef: "Załóżmy, że garbage collector określa w pewnym momencie czasowym, że obiekt jest słabo osiągalny. W tym czasie będzie atomicznie wyczyścić wszystkie słabe odniesienia do tego obiektu i wszystkich słabych odniesień do innych słabych obiektów, z których ten obiekt jest osiągalny poprzez łańcuch silnych i miękkich odniesień. Jednocześnie zadeklaruje wszystkie wcześniej słabo dostępne obiekty jako finalizowalne. W tym samym czasie lub w późniejszym czasie zapyta o nowo wyczyszczone słabe referencje, które są zarejestrowane w kolejkach referencyjnych."

Dla jasności, mówisz, że Garbage Collector działa, gdy aplikacja ma więcej niż 50% Darmowa pamięć i w tym przypadku nie usuwa słabych plików? Dlaczego GC w ogóle działa, gdy aplikacja ma >50% wolnej pamięci? Myślę, że Twoja aplikacja jest prawdopodobnie po prostu generowanie bardzo małej ilości śmieci i gdy kolektor działa to wyczyszczenie WeakRefs, ale nie SoftRefs.

EDIT 6

@j flemm-innym możliwym wyjaśnieniem zachowania Twojej aplikacji jest to, że młody gen jest zbierany, ale twoje słabe i miękkie refy są w starym Genie i są usuwane tylko wtedy, gdy stary gen jest zbierane. Dla mojej aplikacji mam statystyki pokazujące, że stary gen jest zbierany, co powinno oznaczać, że WeakRefs się wyczyścić.

Edycja 7