Różnica między „na stercie” i „poza stertą”
Odpowiedzi:
Magazyn na stercie odnosi się do obiektów, które będą obecne w stercie Java (a także będą podlegać GC). Z drugiej strony magazyn poza stertą odwołuje się do (serializowanych) obiektów, które są zarządzane przez EHCache, ale są przechowywane poza stertą (i również nie podlegają GC). Ponieważ magazyn poza stertą jest nadal zarządzany w pamięci, jest on nieco wolniejszy niż magazyn na stercie, ale nadal szybszy niż magazyn na dysku.
Wewnętrzne szczegóły związane z zarządzaniem i korzystaniem ze sklepu poza stertą nie są zbyt widoczne w linku zamieszczonym w pytaniu, więc rozsądnie byłoby zapoznać się ze szczegółami Terracotta BigMemory , która służy do zarządzania poza dyskiem sklep. BigMemory (magazyn poza stertą) ma być używany w celu uniknięcia narzutu GC na stercie, który ma kilka megabajtów lub gigabajtów. BigMemory wykorzystuje przestrzeń adresową pamięci procesu JVM za pośrednictwem bezpośrednich ByteBufferów , które nie podlegają GC w przeciwieństwie do innych natywnych obiektów Java.
z http://code.google.com/p/fast-serialization/wiki/QuickStartHeapOff
Co to jest rozładowywanie sterty?
Zwykle wszystkie alokowane obiekty nietrwałe są zarządzane przez moduł odśmiecania pamięci Java. Chociaż maszyna wirtualna wykonuje porządną robotę przy usuwaniu elementów bezużytecznych, w pewnym momencie musi wykonać tak zwane „pełne GC”. Pełny GC obejmuje skanowanie całego przydzielonego sterty, co oznacza, że przerwy / spowolnienia GC są proporcjonalne do rozmiaru sterty aplikacji. Nie ufaj więc nikomu, kto powie Ci, że „Pamięć jest tania”. W javie zużycie pamięci obniża wydajność. Dodatkowo możesz uzyskać znaczące przerwy, używając rozmiarów sterty> 1 GB. Może to być nieprzyjemne, jeśli masz jakieś rzeczy w czasie zbliżonym do rzeczywistego, w klastrze lub sieci proces Java może przestać odpowiadać i zostać usunięty z klastra.
Jednak dzisiejsze aplikacje serwerowe (często budowane w oparciu o rozbudowane frameworki ;-)) z łatwością wymagają dużo więcej niż 4Gb.
Jednym z rozwiązań tych wymagań dotyczących pamięci jest „odciążenie” części obiektów do stosu innego niż Java (przydzielanego bezpośrednio z systemu operacyjnego). Na szczęście java.nio udostępnia klasy do bezpośredniego przydzielania / odczytywania i zapisywania „niezarządzanych” fragmentów pamięci (nawet plików mapowanych w pamięci).
Można więc przydzielić duże ilości „niezarządzanej” pamięci i użyć jej do zapisywania tam obiektów. Aby zapisać dowolne obiekty w niezarządzanej pamięci, najbardziej realnym rozwiązaniem jest użycie serializacji. Oznacza to, że aplikacja serializuje obiekty do pamięci offheap, a później obiekt można odczytać za pomocą deserializacji.
Rozmiar sterty zarządzany przez maszynę wirtualną java może być mały, więc przerwy w GC są w milisach, wszyscy są zadowoleni, praca wykonana.
Jest oczywiste, że wydajność takiego bufora poza stertą zależy głównie od wydajności implementacji serializacji. Dobra wiadomość: z jakiegoś powodu serializacja FST jest dość szybka :-).
Przykładowe scenariusze użycia:
- Pamięć podręczna sesji w aplikacji serwera. Użyj pliku mapowanego w pamięci do przechowywania gigabajtów (nieaktywnych) sesji użytkowników. Gdy użytkownik zaloguje się do aplikacji, możesz szybko uzyskać dostęp do danych dotyczących użytkownika bez konieczności korzystania z bazy danych.
- Buforowanie wyników obliczeń (kwerendy, strony html,…) (dotyczy tylko sytuacji, gdy obliczenia są wolniejsze niż deserializacja obiektu wynikowego ofc).
- bardzo prosta i szybka trwałość przy użyciu plików mapowanych w pamięci
Edycja: W przypadku niektórych scenariuszy można wybrać bardziej wyrafinowane algorytmy zbierania śmieci, takie jak ConcurrentMarkAndSweep lub G1, aby obsługiwać większe sterty (ale ma to również ograniczenia przekraczające sterty 16 GB). Dostępna jest również komercyjna maszyna JVM z ulepszonym „bez wstrzymywania” GC (Azul).
Sterta to miejsce w pamięci, w którym żyją dynamicznie przydzielane obiekty. Jeśli użyłeś, newto jest na stercie. To w przeciwieństwie do miejsca na stosie, w którym znajduje się stos funkcji. Jeśli masz zmienną lokalną, to odniesienie to znajduje się na stosie. Sterta Javy podlega wyrzucaniu elementów bezużytecznych, a obiektów można używać bezpośrednio.
Magazyn poza stertą EHCache usuwa zwykły obiekt ze sterty, serializuje go i przechowuje jako bajty w porcji pamięci, którą zarządza EHCache. To jak przechowywanie go na dysku, ale nadal jest w pamięci RAM. W tym stanie obiekty nie nadają się do bezpośredniego użytku, należy je najpierw zdeserializować. Nie podlega również wyrzucaniu elementów bezużytecznych.
Nie 100%; wydaje się jednak, że sterta jest obiektem lub zestawem przydzielonej przestrzeni (w pamięci RAM), która jest wbudowana w funkcjonalność kodu albo samą Javę, albo, co bardziej prawdopodobne, funkcjonalność z samego ehcache, a pamięć RAM poza stertą ma własny system, jak dobrze; jednak wygląda na to, że jest o jedną wielkość wolniejszy, ponieważ nie jest tak zorganizowany, co oznacza, że może nie używać sterty (co oznacza jeden długi zestaw miejsca w pamięci RAM), a zamiast tego używa różnych przestrzeni adresowych, co prawdopodobnie czyni go nieco mniej wydajnym.
Oczywiście następnym niższym poziomem jest samo miejsce na dysku twardym.
Nie używam ehcache, więc możesz nie chcieć mi ufać, ale to właśnie zebrałem z ich dokumentacji.