Jest taki problem.
Program działający w systemie rozproszonym tworzy lokalnie i
przetwarza obiekty typu Item. Każdy Item ma swój unikalny
identyfikator typu long. Item zna swoje id, któro jest znane również
innym programom działającym w systemie. Te inne programy wpływają na
stan lokalnych obiektów Item na podstawie ich id.

Jeżeli program porzuci swój lokalny obiekt Item, to wszystko co
dotyczy jego id może być później zignorowane. Zwykle porzucanie
obiektów Item następuje wtedy, gdy i tak nie ma szansy na dalsze
interakcje dotyczące tego id, ale nie musi tak być.

Ponieważ przy każdym komunikacie przychodzącym z zewnątrz trzeba jakoś
znaleźć odpowiedni lokalny obiekt Item, w programie istnieje mapa,
której kluczem jest long a wartością jest Item (bądź wskaźnik na
Item), czyli która dla danego id potrafi znaleźć Item.

Z powodów, które nie są ważne w tej dyskusji, ten projekt jest pisany
zarówno w C++ jak i w Javie.

W C++ typ Item ma destruktor, który wyrejestrowuje swoje id z mapy.
Dzięki temu, jeśli program "porzuci" jakiś obiekt Item (przez co nie
może już go obserwować i reagować na zmiany jego stanu), to
odpowiadający mu wpis w mapie jest natychmiast wyrzucany. W
szczególności, jeśli program używa obiektów Item w takiej pętli:

for (...)
{
Item it;
// ...
}

to w efekcie mapa nigdy nie ma więcej, niż 1 wpis. Zużycie pamięci
jest wtedy *stałe* (albo ma znaną górną granicę) - dotyczy to również
bardziej złożonych, ale nadal cyklicznych układów.

W Javie nie ma destruktorów, ale jest GC. Jeśli program "porzuci"
jakiś obiekt Item, to w pamięci wisi zarówno obiekt Item, jak i
odpowiadający jego id wpis w mapie. Wyciek.
Na szczęście są słabe referencje, ale uwaga - Item jest *wartością* a
nie kluczem w mapie. W najlepszym razie GC posprząta obiekty Item, ale
wpisy w mapie pozostaną, przez co mapa i tak puchnie w nieskończoność.
Wyciek.
Można pomyśleć o podpięciu się pod finalizator, ale w opinii
szanowanych obywateli jest to robienie wiochy. Zamiast tego doradzono
mi zrobić *dodatkowy wątek*, który będzie okresowo jeździł po mapie i
wywalał wpisy, których wartości się wyzerowały (czyli te wpisy,
których obiekty Item zostały posprzątane przez GC).
To rozwiązanie *prawie* działa, ale ma takie dwie przykre cechy:
* Komplikuje projekt wymuszając istnienie dodatkowego wątku.
* Wprowadza dodatkowe wartości konfiguracyjne służące do strojenia
pracy tego wątku (okres skanowania).

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ć*.

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.
Są inne?

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com