On Thu, 30 Jul 2009 14:49:00 +0200, Michal Kleczek <k...@g...com>
wrote:

>A.L. wrote:
>
>> On Thu, 30 Jul 2009 13:15:24 +0200, Michal Kleczek <k...@g...com>
>> wrote:
>>
>>>Maciej Sobczak wrote:
>>>
>>>> On 29 Lip, 15:14, A.L. <a...@a...com> wrote:
>>>>
>>>>> Do kreowania "dummy" ja bym bie robil konstruktora ale statyczna
>>>>> metode createKey. Na dodatek, wystarczy jeden egzemplarz "dummy"
>>>>> jeseli zrobimy druga methode umozliwiajaca zmiane ID
>>>>
>>>> A na drugi dzień będziesz rozwiązywał nowy problem o nazwie
>>>> "wielowątkowość".
>>>>
>>>
>>>Wtedy trzymasz oddzielne "dummy" dla kazdego watku w ThreadLocal :)
>>>
>>>A tak powazniej - IMHO w wiekszosci wypadkow w Javie proba "polepszenia"
>>>programu poprzez _unikanie_ GC zle sie konczy.
>>
>> Czy Kolega moglby pokazac gezie w tym watku jest proba "unikania
>> GC"?...
>
>Trzymanie jednego "dummy", ktory jest mutable - rozumiem, ze to
>taka "optymalizacja" po to, zeby nie tworzyc nowego obiektu za kazdym
>razem, gdy chcemy cos w mapie znalezc.

Po pierwsze, nie "optymalizacja" a optymalizacja - kreowanie Item moze
byc kosztowne i nei ma co go tworzyc za kazdym razem gdy potrzebujemy
klucz. Slusznie zauwazyl pan Sobczak ze nalezy unikac raczej
rownoleglego dostepu do "dummy", ale rozniez nalezy unikac
rownoleglego dostepu do WeakHashMap. Z tego powodu dostep do dummy,
ustawienie ID oraz wyszukiwanei nalezy umiescic w jednej metodzie i
zrobic tak zeby byla "atomowa". Obiekt "dummy" w ogole nie musi byc
manipulowany pzrez klienta, ani w ogole klient nie musi wiedziec o
jego istnieniu

Po drugie - co to ma wspolnego z "unikaniem GC"?...

A.L.