Arbeta med generationer av objekt
Java sophämtare implementerar en generationsstrategi för sophämtning som kan klassificera objekt efter ålder.
Ett sådant behov (att markera och komprimera alla objekt) i JVM kan kallas ineffektivt. Eftersom ett stort antal objekt allokeras, växer deras lista, vilket leder till en ökning av sophämtningstiden. Empirisk analys av applikationer har visat att de flesta objekt i Java är kortlivade.
Högminnesområdet i JVM är uppdelat i tre sektioner:
![Arbeta med generationer av objekt](https://cdn.codegym.cc/images/article/8aab6bd2-292b-4ecd-9ecc-9ee2a44d3c82/1024.jpeg)
Yngre generation
Nyskapade objekt börjar i den yngre generationen. Den yngre generationen är ytterligare indelad i två kategorier.
- Eden Space - Alla nya objekt börjar här, de tilldelas initialt minne.
Survivor Spaces (FromSpace och ToSpace) - Objekt flyttas hit från Eden efter att ha överlevt en sophämtningscykel.
Processen när föremål är sopor som samlas in från den yngre generationen kallas en mindre sophämtningshändelse.
När Edens utrymme är fyllt med föremål utförs en liten sophämtning. Alla döda föremål tas bort och alla levande flyttas till ett av de återstående två utrymmena. Den lilla GC kontrollerar också föremål i överlevande utrymme och flyttar dem till ett annat (nästa) överlevande utrymme.
Låt oss ta följande sekvens som ett exempel.
- Det finns föremål av båda typerna (levande och döda) i Eden.
- En liten GC inträffar - alla döda föremål tas bort från Eden. Alla levande objekt flyttas till space-1 (FromSpace). Eden och space-2 är nu tomma.
- Nya objekt skapas och läggs till i Eden. Vissa objekt i Eden och space-1 blir döda.
- En liten GC inträffar - alla döda föremål tas bort från Eden och space-1. Alla levande föremål flyttas till space-2 (ToSpace). Eden och space-1 är tomma.
Så när som helst är ett av överlevandeutrymmena alltid tomt. När överlevande når en viss tröskel för att röra sig genom överlevande utrymmen, avancerar de till en äldre generation.
Du kan använda flaggan -Xmn för att ställa in den unga generationens storlek .
Äldre generation
Föremål som lever en betydande tid (till exempel större delen av ett programs livstid) blir så småningom äldre föremål - hundraåringar. Den är också känd som den vanliga generationen och innehåller föremål som har legat kvar i Survivor Spaces under lång tid.
Ett objekts livslängdströskel avgör hur många sophämtningscykler det måste genomgå innan det flyttas till den äldre generationen. Processen när föremål skickas till soporna från den äldre generationen kallas huvudsopsamlingshändelsen.
Du kan använda flaggorna -Xms och -Xmx för att ställa in den initiala och maximala minnesstorleken .
Eftersom Java använder generationsbaserad sophämtning, ju fler sophämtningshändelser ett objekt upplever, desto längre rör sig det på högen. Han börjar i den yngre generationen och hamnar så småningom i den vanliga generationen om han lever tillräckligt länge.
För att förstå främjandet av objekt mellan utrymmen och generationer, överväg följande exempel:
När ett föremål skapas, placeras det först i den unga generationens Eden-rum.
Så fort en liten sophämtning inträffar flyttas levande föremål från Eden till FromSpace. När nästa mindre sophämtning inträffar flyttas levande föremål från både Eden och rymden till ToSpace.
Denna cykel fortsätter ett visst antal gånger. Om objektet fortfarande är "i drift" efter denna punkt, kommer nästa sophämtningscykel att flytta det till äldre generationsutrymmen.
Permanent generation och metaspace
Metadata som klasser och metoder lagras i beständig generering. JVM fyller i den vid körning baserat på klasserna som används av applikationen. Klasser som inte längre används kan gå från permanent generation till sopor.
Du kan använda flaggorna -XX:PermGen och -XX:MaxPermGen för att ställa in den ursprungliga och maximala storleken för den permanenta generationen .
metautrymme
Sedan Java 8 har PermGen-utrymmet ersatts av MetaSpace-minnesutrymmet. Implementeringen skiljer sig från PermGen - detta heaputrymme ändras nu automatiskt.
Detta undviker programmets problem utan minne som uppstår på grund av den begränsade storleken på PermGens heaputrymme. Metaspace-minne kan samlas in som skräp, och klasser som inte längre används kommer att rensas upp automatiskt när metaspace når sin maximala storlek.