> > Jak wół stoi:
>
> > "Like most collection classes, this class is not synchronized.
>
> Zabawa polega na tym, że to nie jest takie proste.
>
> Specyfikacja Javy (JLS) w rozdziale o wątkach a konkretnie o
> współdzieleniu danych (17.4.1) pisze:
>
> "Two accesses to (reads of or writes to) the same variable are said to
> be conflicting if at least one of the accesses is a write."

Z taką właśnie sytuacją mamy tu do czynienia. Szczegóły dalej.

> Czyli wiele wątków *czytających* te same dane nie stanowi problemu.
> Można stworzyć jakąś wartość (ogólnie: *strukturę danych*), zapewnić
> jej widoczność i bez problemu czytać ją z wielu wątków. To jest
> gwarantowane przez specyfikację języka.
> BTW - stąd właśnie bierze się eksponowanie pomysłu na klasy
> "immutable" w książce, którą polecał A.L. - obiekty niezmienne mogą
> być używane przez wiele wątków równocześnie nie dlatego, że jest w
> nich jakaś magia, tylko właśnie dlatego, że wtedy nie ma
> konfliktujących zapisów.

Immutable ma się tu jak pięść do nosa. Sens istnienia WeakHashMap jest
w zmienności -
usuwane są z niej klucze, które GC zbierze.

> Moje pytanie w pełnej wersji: czy get() w WeakHashMap jest operacją
> modyfikującą? Jeżeli nie, to na mocy powyższego paragrafu można wołać
> get() z różnych wątków (i w szczególności ReadWriteLock można użyć do
> synchronizacji, wbrew temu, co twierdził A.L.).
>
> *To* jest właśnie pytanie, któro tutaj zadałem.

To czy get jest operacją modyfikującą jest szczegółem implementacji.

Istotne jest, że w pewnym momencie jakiś obiekt zawarty w WeakHashMap
jest "weakly reachable". Można więc "go" usunąć z mapy.
Skąd wiadomo, że jest "weakly reachable"? - zaglądamy do dokumentacji
WeakReference:

"Suppose that the garbage collector determines at a certain point in
time that an object is weakly reachable. [...] At the same time or at
some later time it will enqueue those newly-cleared weak references
that are registered with reference queues."

Jeśli obiekt jest "weakly reachable" to obiekt weak reference, który
go zawija trafia do kolejki (ReferenceQueue). Sprawdzamy kolejkę -
jeśli zawiera referencję to usuwamy je z mapy. Operacja usuwania może
być przeprowadzona w wątku, który wywołał jakąś operację na mapie (tak
się dzieje w przypadku java.util.WeakHashMap - wiem bo zajrzałem do
źródeł) może też być zrealizowane w sposób, który pokazał Michal
Kleczek - w odzielnym wątku "pollującym" kolejkę referencji.

Zarówno w pierwszej jak i drugiej implementacji mamy modyfikację mapy
w jednym wątku odczyt w drugim.

[...]

> Ale wtedy też będziemy mieli dwie opcje:
> - uznać, że dokumentacja jest do dupy i nie opisuje rzeczywistości
> - uznać, że implementacja jest do dupy i nie działa zgodnie ze
> specyfikacją.
>
> Co byś wybrał?
>

Dokumentacja jest super. Ty jej nie doczytałeś ;-)

PL