Maciej Sobczak wrote:

[ciach]
>
> 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.

Moglbys pokazac kod w C++ ktory to robi bez uzycia jakichs smart pointerow
zliczajacych referencje? Bo ja nie bardzo to widze (ale specem nie
jestem) - chyba ze wszystkie obiekty Item o tym samym id sa rownowazne -
tyle ze wtedy nie jest potrzebna zadna mapa.

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

Nie widze w powyzszym przykladzie mapy ani pobierania obiektow Item z tejze.

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

Prawda.

> * Wprowadza dodatkowe wartości konfiguracyjne służące do strojenia
> pracy tego wątku (okres skanowania).
>

Nie trzeba watku skanujacego - wystarczy usuwajacy. Od skanowania jest
java.lang.ref.ReferenceQueue

--
Michal