Maciej Sobczak wrote:
[ciach]
> Piszę *prawie*, bo pomiędzy posprzątaniem obiektów Item (hint: to się
> dzieje dopiero wtedy, gdy GC jest wystarczająco zestresowany, żeby się
> w ogóle ruszyć - co następuje akurat wtedy, gdy *zaczyna brakować
> pamięci*) a skanem mapy jest pewien odstęp czasu, kiedy niepotrzebne
> już wpisy w mapie *nadal* zajmują pamięć, zmniejszając efektywnie pulę
> dostępnej pamięci. To powoduje, że przy dalszej pracy programu GC
> szybciej będzie zestresowany i znowu coś tam posprząta, ale przez nowe
> wiszące wpisy w mapie i tak zostawi jeszcze mniejszą pulę wolnej
> pamięci. Ostatecznie program wylatuje na jej braku, chociaż z
> projektowego punktu widzenia może nigdy nie używać więcej, niż jednego
> obiektu Item.
> Oczywiście zmiany okresu skanowania mapy wpływają jedynie na
> *prawdopodobieństwo* poprawnego działania całego programu i nigdy nie
> można tej poprawności *zagwarantować*.
>

Dlaczego? Watek sprzątający może sam "kopnąć" GC.

> Ot, taka sobie historyjka. Ale może ktoś znudzony upałami i burzami
> wpadnie na jakiś pomysł, jak to poprawić.
>
> Jedną z możliwości jest dodatnie do klasy Item funkcji close() i
> uprzejme poproszenie programisty, żeby jej używał. Jest to
> rozwiązanie, którego poziom abstrakcji i wartość projektowa
> odpowiadają językowi C.

To nie jest złe. Dla bezpieczeństwa w finalizatorze można
dodać asercje o niezwolnionym obiekcie.

> Są inne?
>

Może zobaczyć jak zaimplementowali WeakHashMap ( tam "weak"
jest klucz a nie wartość ).

Pozdrawiam
KK