Moduł zbierający elementy bezużyteczne to proces o niskim priorytecie, uruchamiany okresowo i zwalniający pamięć używaną przez obiekty, które nie są już potrzebne. Moduł zbierający śmieci działa w tle, równolegle z programem, w osobnym wątku. Podstawą zbierania śmieci nie jest zliczanie referencji, ale podział obiektów na dwa typy - osiągalne i nieosiągalne. Obiekt uważa się za osiągalny (żywy), jeśli odwołuje się do niego inny osiągalny (żywy) obiekt. Osiągalność jest liczona z wątków. Działające wątki są zawsze uważane za osiągalne (żywe), nawet jeśli nikt się do nich nie odwołuje. Wszystkie obiekty w Javie są przechowywane w specjalnym obszarze pamięci zwanym stertą. Wszystkie obiekty w programach można podzielić na dwa typy - stosunkowo proste i „długowieczne”. Obiekty „długowieczne” to takie, które przetrwały wiele zbiórek śmieci. Najczęściej będą istnieć do końca programu. W rezultacie wspólna sterta, na której przechowywane są wszystkie utworzone obiekty, została podzielona na kilka części. Pierwsza część ma piękną nazwę – Eden (biblijny „Ogród Edenu”), przedmioty trafiają tu po stworzeniu. To w tej części przydzielana jest pamięć dla nowych obiektów, gdy piszemy nowe. Obiektów można utworzyć wiele, a gdy w tym obszarze zabraknie miejsca, rozpoczyna się pierwsze, „szybkie” zbieranie śmieci. Trzeba przyznać, że śmieciarka jest bardzo sprytna i wybiera algorytm pracy w zależności od tego, czego jest więcej na stercie – śmieci czy działających obiektów. Jeśli prawie wszystkie obiekty są śmieciami, moduł zbierający zaznacza „żywe” obiekty i przenosi je do innego obszaru pamięci, po czym bieżący obszar jest całkowicie czyszczony. Jeśli śmieci jest mało i większość zajmują przedmioty żywe, zaznacza śmieci, sprząta je i porządkuje pozostałe przedmioty. Obszar pamięci, do którego przenoszone są wszystkie obiekty, które przetrwały co najmniej jedno wyrzucanie elementów bezużytecznych, nazywany jest Przestrzenią Przetrwania. Przestrzeń Przetrwania z kolei podzielona jest na pokolenia. Każdemu obiektowi przypisana jest generacja na podstawie liczby operacji wyrzucania elementów bezużytecznych, które wystąpiły. Jeśli jest, należy do „Generacji 1”, jeśli 5 – do „Pokolenia 5”. Razem Eden i Survival Space tworzą obszar o nazwie Młode Pokolenie. Oprócz Młodego Pokolenia na stosie znajduje się jeszcze jeden obszar pamięci – Stare Pokolenie („stare pokolenie”). Są to obiekty bardzo długowieczne, które przetrwały wiele zbiórek śmieci. Bardziej opłaca się przechowywać je oddzielnie od wszystkich pozostałych. I tylko wtedy, gdy obszar Starej Generacji będzie zapełniony, czyli tj. Nawet w programie jest tak wiele długowiecznych obiektów, że nie ma wystarczającej ilości pamięci, przeprowadzane jest pełne odśmiecanie. Przetwarza nie tylko jeden obszar pamięci, ale ogólnie wszystkie obiekty utworzone przez maszynę Java. Naturalnie wymaga to znacznie więcej czasu i zasobów. Dlatego zdecydowano się przechowywać przedmioty długowieczne oddzielnie. Gdy w innych obszarach zabraknie miejsca, przeprowadzana jest tzw. „szybka zbiórka śmieci”. Obejmuje tylko jeden obszar, dzięki czemu jest bardziej ekonomiczna i szybsza. Na końcu, Kiedy nawet obszar przeznaczony dla długowiecznych mieszkańców jest już zapchany, w grę wchodzi pełne sprzątanie. Tym samym najbardziej „ciężkie” narzędzie asemblera wykorzystywane jest tylko wtedy, gdy nie jest już potrzebne.
2. Jakie są rodzaje śmieciarek?
Java ma siedem typów modułów zbierających elementy bezużyteczne:
Seryjny zbieracz śmieci
Równoległy zbieracz śmieci
System zbierania śmieci CMS
Odbieracz śmieci G1
Urządzenie do zbierania śmieci firmy Epsilon
Śmietnik Z
Kolekcjoner śmieci Shenandoah
3. Czym są „generacje” obiektów
Wszystkie obiekty w Survival Space podzielone są na generacje. Każdemu obiektowi przypisana jest generacja na podstawie liczby operacji wyrzucania elementów bezużytecznych, które wystąpiły. Jeśli jest, należy do „Generacji 1”, jeśli 5 – do „Pokolenia 5”.
4. Do czego służy SoftReference?
Obiekt, do którego odwołują się wyłącznie miękkie odniesienia, może zostać usunięty, jeśli w programie zabraknie pamięci. Jeśli w programie nagle zabraknie pamięci, przed zgłoszeniem wyjątku OutOfMemoryException moduł zbierający elementy bezużyteczne usunie wszystkie obiekty, do których odwołują się miękkie łącza, i spróbuje ponownie przydzielić pamięć programowi. Obiekt, który jest chroniony przed śmiercią tylko przez SoftReference, może przetrwać dowolną liczbę operacji wyrzucania elementów bezużytecznych i najprawdopodobniej zostanie zniszczony, jeśli w programie zabraknie pamięci.
5. Przykład wykorzystania SoftReference
SoftReferences zostały specjalnie zaprojektowane do buforowania. Załóżmy, że program kliencki często żąda różnych danych od programu serwera. Następnie program serwera może część z nich buforować, używając w tym celu SoftReference. Jeśli obiekty chronione przed śmiercią przez miękkie referencje zajmują większość pamięci, moduł zbierający elementy bezużyteczne po prostu je usunie i to wszystko.
6. Przykład wykorzystania WeakReference
Jeśli istnieją tylko słabe odniesienia do obiektu, wówczas obiekt ten żyje, ale zostanie zniszczony podczas następnego wyrzucania elementów bezużytecznych. Obiekt, który jest chroniony przed śmiercią przez samo WeakReference, nie przetrwa następnego wyrzucania elementów bezużytecznych. Ale dopóki tak się nie stanie, możesz to uzyskać, wywołując metodę get()w WeakReference i wywołując jej metody lub wykonując coś innego. Przykładem użycia WeakReference jest WeakHashMap.
7. Dlaczego WeakHashMap jest potrzebny
WeakHashMap to HashMap, którego klucze są słabymi referencjami - WeakReference. W WeakHashMap przechowujesz pary obiektów - klucz i wartość. Ale WeakHashMap nie odnosi się bezpośrednio do kluczy, ale poprzez WeakReference. Dlatego też, gdy obiekty użyte jako klucze staną się nieosiągalne, zostaną zniszczone podczas kolejnego wyrzucania elementów bezużytecznych. Oznacza to, że ich wartości zostaną automatycznie usunięte z WeakHashMap. WeakHashMap jest bardzo wygodny do przechowywania dodatkowych informacji o niektórych obiektach. Po pierwsze, bardzo łatwo jest go zdobyć, jeśli użyjesz samego przedmiotu jako klucza. Po drugie, jeśli obiekt zostanie zniszczony, zarówno on, jak i wszystkie powiązane z nim dane znikną z HashMap. Przykładowo program posiada wątek monitorujący pracę niektórych obiektów zadań i zapisujący o nich informacje do logu. Następnie ten wątek może przechowywać śledzone obiekty w takiej WeakHashMap. Gdy tylko obiekty nie będą już potrzebne, moduł zbierający elementy bezużyteczne usunie je, a odniesienia do nich z WeakHashMap zostaną automatycznie usunięte.
8. Co to jest rejestrator
Obiekt Logger służy do rejestrowania komunikatów dla określonego systemu lub komponentu aplikacji. Dziennik to lista zdarzeń, które miały miejsce. Najczęściej do logu zapisywane są informacje o parametrach metody z jaką została wywołana, wszystkich przechwyconych błędach oraz mnóstwo informacji pośrednich. Cały proces logowania składa się z trzech części.
Pierwsza część to zbieranie informacji.
Druga część to filtrowanie zebranych informacji.
Trzecia część to zapis wybranych informacji.
9. Jak skonfigurować rejestrator
Dodaj zależność do pom.xml.
Dodaj plik log4j.properties do zasobów.
Zazwyczaj ustawienia rejestratora log4j są ustawiane w pliku log4j.properties. W tym pliku możesz określić kilka appenderów - obiektów, do których będą zapisywane dane.
Dodaj do zajęć logikę biznesową private static final Logger log = Logger.getLogger(ххх.class);.
GO TO FULL VERSION