Maciej Sobczak pisze:
> On 27 Lip, 11:30, Jacek Czerwinski <x...@...z.pl> wrote:

>> 2. Inna idea Spring JDBC odnośnie często źle zwalnianych zasobów
>> (bazodanowych), zamyka je w przedział czasu.
>
> Nie różni się to niczym od tego, co mam z wątkiem czyszczącym.
>
W algorytmie czyszczenia to dokladnie to samo, inny sposób sprowokowania
(dziedzina czasu).

>> 3. Trzecia idea, też z baz. Pule.
>
> Tak naprawdę to bazy danych nie są w żaden sposób szczególne. Systemy
> bazodanowe też są systemami rozproszonymi i ostatecznie wszystkie
> problemy z zarządzaniem czegokolwiek są tam do siebie podobne
Dokładnie, pule bazową dałem jako popularny przykład.

do góry

Maciej Sobczak wrote:
>> Ja zaproponuje takie rozwiązanie.
>>
>> 1. Oprócz mapy kluczy, utworzyć kolejkę par [ID, Item].
>> 2. W konstruktorze obiektu Item
>> a) pobrać N > 1 par z kolejki,
>> b) usunąć z mapy wpisy z martwymi referencjami,
>> c) pary z żywymi referencjami dodać na koniec kolejki,
>> d) utworzyć parę [ID, Item] dla bieżącego obiektu i dodać ja do mapy,
>> oraz na koniec kolejki.
>
> Tak naprawdę to całe rozwiązanie jest w 2b (brute-force to po prostu
> pełny skan mapy w każdym konstruktorze Item). Nie potrzeba już żadnych
> kolejek.

Nie myślałem o metodzie brute-force a o N z przedziału co najwyżej [2, 8].
Założyłem, że istnieje ograniczony czas na utworzenie obiektu.

> Nadal jest potencjalny problem z pamięcią, bo całość zależy od tego,
> czy program będzie w przyszłości wołał konstruktory Item - czyli
> zwalnianie pamięci jest stymulowane przez tworzenie obiektów jednego
> tylko typu. Być może program nie stworzy już żadnego takiego obiektu.
>
> Niemniej, to rozwiązanie jest dobre w połączeniu z obecnym cyklicznym
> wątkiem.

Fakt, istniałaby potrzeba sporadycznego skanowania mapy, na wypadek gdyby
obiekty nie były już tworzone.

Pozdrawiam,
- Bastek -

do góry

On 27 Lip, 14:26, A.L. <a...@a...com> wrote:

> WeakHashMap?...

Napisałem, że Item jest wartością a nie kluczem.
Kluczem jest Long - niezbyt dobry kandydat na WeakHashMap.

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

do góry

On Mon, 27 Jul 2009 08:05:54 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:

>On 27 Lip, 14:26, A.L. <a...@a...com> wrote:
>
>> WeakHashMap?...
>
>Napisałem, że Item jest wartością a nie kluczem.
>Kluczem jest Long - niezbyt dobry kandydat na WeakHashMap.

Ja proponuje zeby Pan przeczytal dokladnie opis WeakHashMap.

Zdanie ""Kluczem jest Long - niezbyt dobry kandydat na WeakHashMap"
nie ma sensu jako takie.

Proponuje poczytac tutaj na przyklad

http://onjava.com/pub/a/onjava/2001/07/09/optimizati
on.html?page=1

Specifically, we want to handle the situation where the
deregisterObject() method is not called, but the registered object is
no longer referenced anywhere in the application, except by our
internal Map. This situation is precisely what WeakHashMap was
designed for. The keys entered into a WeakHashMap are held using
WeakReferences. This allows the garbage collector to collect the keys
if there are no other strong references to those keys elsewhere in the
application (for more details about strong and weak references in
Java, see the "Further resources" section at the end of this article).
After the keys have been collected, the values are also dereferenced
from the WeakHashMap, and can also be garbage collected if they are
not referred to elsewhere in the application.


A.L.

do góry

On 27 Lip, 17:28, A.L. <a...@a...com> wrote:

> >> WeakHashMap?...
>
> >Napisałem, że Item jest wartością a nie kluczem.
> >Kluczem jest Long - niezbyt dobry kandydat na WeakHashMap.
>
> Ja proponuje zeby Pan przeczytal dokladnie opis WeakHashMap.

Tak. Zgadzam się, że problem jest w dokładnym przeczytaniu tego opisu.

> Zdanie ""Kluczem jest Long - niezbyt dobry kandydat na WeakHashMap"
> nie ma sensu jako takie.

Otóż ma sens, bo obiekty typu Long mogą być cache'owane przez
implementację, co sztucznie podtrzymałoby wpis w mapie, jeśli Long
miałby być kluczem. Nie mówiąc o tym, że Longi mogą być użyte również
w innym celu.

> Proponuje poczytac tutaj na przyklad

> The keys entered into a WeakHashMap are held using
> WeakReferences. This allows the garbage collector to collect the keys
> if there are no other strong references to those keys elsewhere in the
> application

No właśnie. Sęk w tym, że interesujące mnie obiekty Item to nie
"keys", tylko "values".

Potrzebna jest taka mapa: Map<Long, Item> (ewentualnie jej
WeakReference warianty). W tej mapie kluczami są Longi a wpisy mają
być usunięte po porzuceniu wartości Item.

Ech - ostatecznie chyba zrobię funkcję close(). Programiści Javy są do
takich funkcji mocno przyzwyczajeni, więc chyba nie będą marudzić przy
jeszcze jednej? :-|

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

do góry

Witam,

A może takie coś pomoże.
Mój pomysł opiera się na własnej podklasie dziedziczącej z WeakReference
(działa też z SoftReference, tylko w innym momencie następuje czyszczenie -
dopiero jak pamięci zabraknie).
Moja klasa IdWeakReference przechowuje dodatkowo klucz do mapy, więc wiadomo
co z mapy usunąć przy przetwarzaniu obiektów pobranych z ReferenceQueue.
Testowałem i wydaje się, że działa:

package referencetest;

import java.lang.ref.ReferenceQueue;
import java.lang.ref.WeakReference;
import java.util.HashMap;
import java.util.Map;

public class SelfCleaningCache<ID, ITEM> {

private Map<ID, IdWeakReference<ID, ITEM>> items = new
HashMap<ID, IdWeakReference<ID, ITEM>>();
private ReferenceQueue<ITEM> referenceQueue = new
ReferenceQueue<ITEM>();
private volatile boolean running = true;
private Thread refQueueCleaner;

public SelfCleaningCache() {
System.out.println("creating RefQue cleaner");

refQueueCleaner = new Thread(new Runnable() {

@Override
public void run() {
while (running) {
try {
IdWeakReference<ID, ITEM> reference =
(IdWeakReference<ID, ITEM>) referenceQueue.remove();
System.out.println(reference.getClass());
items.remove(reference.getId());
System.out.println("removing map entry, id from
reference is " + reference.getId());
} catch (InterruptedException e) {
System.err.println("RefQue cleaner interrupted!");
break;
}
}
}
});
refQueueCleaner.start();
}

public void put(ID id, ITEM item) {
items.put(id, new IdWeakReference<ID, ITEM>(id, item,
referenceQueue));
}

public ITEM get(Object key) {
IdWeakReference<ID, ITEM> ref = items.get(key);
if (ref != null) {
return ref.get();
} else {
return null;
}
}

public void close() {
running = false;
refQueueCleaner.interrupt();
}
}

class IdWeakReference<ID, T> extends WeakReference<T> {

private ID id;

public IdWeakReference(ID id, T referent) {
super(referent);
this.id = id;
}

public IdWeakReference(ID id, T referent, ReferenceQueue<? super T> q) {
super(referent, q);
this.id = id;
}

public ID getId() {
return id;
}

}



I program testujący:




package referencetest;

public class RefTest {

public static void main(String[] args) {
SelfCleaningCache<Long, Item> cache = new SelfCleaningCache<Long,
Item>();

System.out.println("Creating objects");
for (long i = 0; i < 1000000; i++) {
cache.put(i, new Item(i));
if (i % 10000 == 0) {
System.out.println("id " + i);
}
}

cache.close();
}

}

class Item {
private Long id;
private Long[] table = new Long[100000];

public Item(Long id) {
this.id = id;
}

public Long getId() {
return id;
}

}

Pozdrawiam
Jarek

do góry

On Jul 27, 10:38 am, Maciej Sobczak <s...@g...com> wrote:

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

Klasycznie to się nazywa WeakValueMap. Wydaje mi się, że w Javie nie
ma tego standardowo, ale można zrobić ze słabych referencji (jakieś
weak reference queue przeglądane przy zmianach mapy) albo pewnie
znaleźć gotowe.

do góry

> Otóż ma sens, bo obiekty typu Long mogą być cache'owane przez
> implementację, co sztucznie podtrzymałoby wpis w mapie, jeśli Long
> miałby być kluczem. Nie mówiąc o tym, że Longi mogą być użyte również
> w innym celu.

Cache'owane są wtedy gdy ich tworzenie następuje przez Long.valueOf
(long l).
new Long() tworzy zawsze nowy obiekt.

>
> > Proponuje poczytac tutaj na przyklad
> > The keys entered into a WeakHashMap are held using
> > WeakReferences. This allows the garbage collector to collect the keys
> > if there are no other strong references to those keys elsewhere in the
> > application
>
> No właśnie. Sęk w tym, że interesujące mnie obiekty Item to nie
> "keys", tylko "values".
>
> Potrzebna jest taka mapa: Map<Long, Item> (ewentualnie jej
> WeakReference warianty). W tej mapie kluczami są Longi a wpisy mają
> być usunięte po porzuceniu wartości Item.

Użyj mapy gdzie klucze też mogą być słabymi referencjami.
Gotowa implementacja:
http://google-collections.googlecode.com/svn/trunk/j
avadoc/index.html?com/google/common/collect/MapMaker
.html

Z jej opisu:
"An entry whose key or value is reclaimed by the garbage collector
immediately disappears from the map"

PL

do góry

On Mon, 27 Jul 2009 23:18:57 -0700 (PDT), "Marcin 'Qrczak' Kowalczyk"
<q...@k...org.pl> wrote:

>On Jul 27, 10:38 am, Maciej Sobczak <s...@g...com> wrote:
>
>> 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.
>
>Klasycznie to się nazywa WeakValueMap. Wydaje mi się, że w Javie nie
>ma tego standardowo, ale można zrobić ze słabych referencji (jakieś
>weak reference queue przeglądane przy zmianach mapy) albo pewnie
>znaleźć gotowe.

Owszem, mozna

http://www.ableverse.org/apidoc/av/util/WeakValueMap
.html

A.L.

do góry

On Mon, 27 Jul 2009 13:36:43 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:

>On 2
>Potrzebna jest taka mapa: Map<Long, Item> (ewentualnie jej
>WeakReference warianty). W tej mapie kluczami są Longi a wpisy mają
>być usunięte po porzuceniu wartości Item.
>

Ja mialem na mysli WeakHashMap w ktorej kluczem jest Item a waroscia
slaba referencja na klucz. Item musi miec "equals" zaomplementowane na
podstawie rownosci ID, a do wyszukiwania tzreba zrobic "dummy" Item z
zainicjowana wartoscia ID taka jakiej poszukujemy

>Ech - ostatecznie chyba zrobię funkcję close(). Programiści Javy są do
>takich funkcji mocno przyzwyczajeni, więc chyba nie będą marudzić przy
>jeszcze jednej? :-|

W jezkach z GC, wbrew powszechnej opinii, tez potzrebne sa
destruktory. Czasami. Wiec nei widz nic zlego w close(), tyle ze ja
taka metode nazywam destroy()

A.L.

do góry