pamięć, (procesy w menedżerze zadań Win)

0

Witam, mam problem z tym co w temacie. Każdy obiekt, który nie będzie więcej potrzebny kończę dispose(), mimo to, pamięć tylko rośnie (czasem tylko spada minimalnie).

Zrobiłem testowy prosty program. 2 klasy:
-JFrame z guzikiem
-JFrame z labelem.

po naciśnięciu na guzik pierwszego JFrame'a, przez randoma losuje się liczba, przerabia przez String.valueOf() na Stringa, i podaje go do konstruktora drugiego JFrame'a, a on daje go jako wartość swojego labela. Domyślna akcja na 'krzyżyk' drugiego Frame'a, to dispose(). Teraz po prostu odpaliłem to, sprawdziłem jaką pamięć zużywa program na początku (ok. 17000K - faza początkowa), nacisnąłem na guzik ze 100 razy (w tym momencie ok. 22000K), wyłączyłem wszystkie okna (tak, znowu 100 kliknięć), efekt w menedżerze: ok. 21000K - faza końcowa. (poczekałem jeszcze kilkanaście minut, na przemian minimalnie rósł i malał, ciągle jednak mniej więcej było tyle samo). Teraz tak: to bardzo prosty program, więc nawet po wywołaniu dużej liczby okien, zmiana w pamięci (w menedżerze zadań) będzie niewielka, ale sam fakt jej WZROSTU względem fazy początkowej a fazy końcowej (gdzie jakby liczba istniejących obiektów jest taka sama [jeden JFrame z buttonem], ew. dodatkowe 2 zmienne [losowany int i String przekazywany do konstruktora drugiego JFrame'a]) w większych aplikacjach (np. mojej, o której wspominałem na początku posta) wpływa na dość istotne wartości w nieużywanej pamięci. Jak temu zapobiec? Obiekt, który kończę przez 'dispose()' nie jest potencjalnym celem dla gc? Mogę jakoś zwalniać pamięć?

0

Jesli zapominasz o referencjach do tych framow to po dispose() jest gotowe dla sprzatniecia przez GC.
Przy czym Ty zakladasz, ze jak tylko obiekt bedzie do zwolnienia, to po jakims czasie GC go zwolni, a wcale tak nie jest. GC zacznie dzialac wtedy kiedy zacznie mu brakowac pamieci. Nie wiem jakich ustawien starty uzywasz, pewnie domyslnych 64 mb czy cos podobnego. Sprobuj dac mniejsza pamiec, np 16 mb dla jvm (switche Xmx, Xms i moze jakies inne, nie pamietam) i klikaj ile wlezie i obserwuj.

0

Możesz ręcznie wywołać gc... jak strzelisz jvm hinta o gc gdzieś tak z 20 razy pod rząd, to raczej Cię posłucha ;)
Otóż jvm robi zwykłe gc i full gc, w zwykłym gc usuwa śmieci (i nie wiem czy coś więcej, być może przesuwa niektóre obiekty) a w full gc usuwa śmieci i przesuwa obiekty w pamięci "do tyłu", żeby zapełnić luki...
Nie powinieneś się sugerować tym co pokazuje menadżer zadań - ja całkiem niedawno miałem jakąś swoją aplikację okienkową otwartą w tle przez pół godziny i manadżer twierdził, że zajmuje 1,5 mb w pamięci, nawet gdy okna były na wierzchu.
Z drugiej strony inna mała aplikacja wyświetlająca jedno okienko zajmowała mi ponad 20mb przez długi czas.

0

No bo task manager pokazuje pamiec dla JVM, ktory sobie radosnie moze rosnac az do ustalonych (knfigurowalnych) limitow, i raczej nigdy nie maleje (smiec twierdzic ze te malutkie wahania jakie widziales wynikaja z czegos specyficznego dla OS). Nie pokazuje on natomiast ile z tej pamieci jest aktualnie zajmowane.

0

Keraja rady posłuchałem, 'proszę' ;) gc o odpalenie się po każdym dispose(). Powyższy testowy program zmodyfikowałem, do tego drugiego frame'a dodałem 100000 elementową double tablicę i zapełniałem losowymi wartościami żeby zwiększyć troche rożnice liczbowe w menedżerze, w efekcie po uruchomieniu 50 okien z początkowych 20000K podskoczyło do okolic 70000K, a po wyłączeniu (z System.gc() po każdym dispose()) skończyło na 26000K, dalej gdzieś 6000K niby siedzi, ale bez System.gc() kończy na 75000K <hahaha>;). Wiedziałem o System.gc(), tylko właśnie wszędzie zawsze czytałem, żeby tego nie używać, bo to 'i tak pozostaje losowe', wątpiłem, że to coś da.

Dzięki.

0

Wiesz jednak, że nie musisz tego ciągle wywoływać?
JVM na każdy kolejny obiekt rezerwuje sobie coraz większą stertę, żeby nie bawić się w szukanie wolnego miejsca na obiekt. Zostawia sobie tą zabawę na później, na gc. Menadżer może pisać, że zajmuje dużo pamięci, kiedy tak na prawdę większość z tego może być wolne, ale zarezerwowane...

1 użytkowników online, w tym zalogowanych: 0, gości: 1