"Hej! Jag bestämde mig för att ge dig ytterligare en liten lektion om sophämtning."
Som du redan vet övervakar Java-maskinen själv när ett objekt blir onödigt och tar bort det.
"Japp. Du och Rishi berättade om det tidigare. Jag kommer inte ihåg detaljerna."
"Okej. Låt oss då gå igenom det igen."
"Så snart ett objekt har skapats allokerar JVM minne för det. Intresset för objektet övervakas med hjälp av referensvariabler. Ett objekt kan raderas under skräphämtning, dvs. den procedur genom vilken minnet frigörs om det inte finns några variabler som refererar till objekt. "
"Berätta lite om sophämtaren - vad det är och hur det fungerar."
"OK. Skräphämtning brukade ske på huvudtråden. Var 5:e minut, eller oftare. Om det någonsin inte fanns tillräckligt med ledigt minne, skulle Java-maskinen stänga av alla trådar och ta bort oanvända objekt."
"Men det här tillvägagångssättet har övergetts nu. Nästa generations sophämtare arbetar bakom kulisserna och på en separat tråd. Detta kallas samtidig sophämtning."
"Jag förstår. Hur exakt fattas beslutet att ta bort ett objekt eller inte?"
"Att bara räkna antalet referenser till ett objekt är inte särskilt effektivt - det kan finnas objekt som refererar till varandra, men som inte refereras av andra objekt."
"Så Java tar ett annat tillvägagångssätt. Java delar in objekt i nåbara och oåtkomliga. Ett objekt är nåbart (levande) om det refereras av ett annat nåbart (levande) objekt. Nåbarheten bestäms utifrån trådar. Löpande trådar anses alltid nåbara (levande) , även om ingen refererar till dem."
"OK. Jag tror jag förstår."
"Hur går den faktiska sophämtningen till - raderingen av onödiga föremål?"
"Det är enkelt. I Java är minnet uppdelat i två delar enligt konvention, och när det är dags för sophämtning kopieras alla levande (nåbara) föremål till en annan del av minnet, och det gamla minnet släpps allt."
"Det är ett intressant tillvägagångssätt. Du behöver inte räkna referenser: kopiera alla nåbara objekt, och allt annat är skräp."
"Det är lite mer komplicerat än så. Java-programmerare fann att objekt vanligtvis delas in i två kategorier: långlivade (som existerar hela tiden programmet körs) och kortlivade (som behövs i metoder och för att utföra «lokala) " operationer)."
"Det är mycket effektivare att hålla långlivade föremål åtskilda från kortlivade. För att göra detta var det nödvändigt att komma på ett sätt att bestämma objektets livslängd."
"Så, de delade upp allt minne i «generationer». Det finns första generationens objekt, andra generationens objekt, etc. Varje gång minnet rensas, ökas generationsräknaren med 1. Om vissa objekt finns i flera generationer, då registreras som långlivade."
"Idag är sopsamlaren en mycket komplex och effektiv del av Java. Många av dess delar fungerar heuristiskt - baserat på algoritmer som gör gissningar. Som ett resultat av detta "lyssnar den ofta inte på" användaren."
"Menande?"
"Java har ett garbage collector-objekt ( GC ) som kan anropas med metoden System.gc ()."
"Du kan också använda System.runFinalization() för att tvinga anrop till finaliseringsmetoderna för objekten som ska raderas. Men faktum är att, enligt Java-dokumentationen, garanterar denna varken att sophämtning kommer att starta, eller att finalise( )-metoden kommer att anropas. Sopsamlaren bestämmer när den ska anropas och på vad. "
"Wow! Bra att veta."
"Men det finns mer. Som du vet, i Java refererar vissa objekt till andra. Detta nätverk av referenser används för att avgöra om ett objekt ska raderas."
"Och, titta. Java har speciella referenser som låter dig påverka den här processen. Det finns speciella omslagsklasser för dem. Här är de:"
" SoftReference är en mjuk referens."
" WeakReference är en svag referens."
" PhantomReference är en fantomreferens."
"Äh... Det här påminner mig om inre klasser, kapslade klasser, kapslade anonyma klasser och lokala klasser. Namnen är olika, men det är inte alls klart vad de är till för."
"Säg, Amigo, du har blivit en programmerare. Nu är du arg på grund av klassnamnen och säger "de är inte tillräckligt informativa, och det är omöjligt med ett namn(!) att avgöra vad den här klassen gör, hur, och varför"."
"Wow. Jag märkte inte ens det. Men det är så uppenbart."
"OK. Tillräckligt med ord. Låt mig berätta om SoftReferences."
"Dessa referenser var speciellt utformade för cachning, även om de kan användas för andra ändamål - allt efter programmerarens gottfinnande."
"Här är ett exempel på en sådan referens:"
// Create a Cat object
Cat cat = new Cat();
// Create a soft reference to a Cat object
SoftReference<Cat> catRef = new SoftReference<Cat>(cat);
// Now only the catRef soft reference points at the object
cat = null;
// Now the ordinary cat variable also references the object
cat = catRef.get();
// Clear the soft reference
catRef.clear();"Om de enda referenserna till ett objekt är mjuka, så fortsätter det att leva och kallas 'mjukt nåbart'."
"Men! Ett objekt som endast refereras av mjuka referenser kan raderas av sopsamlaren om programmet inte har tillräckligt med minne. Om programmet plötsligt inte har tillräckligt med minne, innan du kastar en OutOfMemoryException , kommer sopsamlaren att radera alla objekt refereras av mjuka referenser och försöker igen att allokera minne till programmet."
"Anta att ett klientprogram ofta begär olika data från ett serverprogram. Serverprogrammet kan använda en SoftReference för att cache en del av det. Om objekt som hålls från döden av mjuka referenser tar upp en stor del av minnet, så raderar sophämtaren dem helt enkelt alltihop. Det är vackert!"
"Ja. Jag gillade det själv."
"Tja, ett litet tillägg: SoftReference- klassen har två metoder. Get()-metoden returnerar objektet som refereras av SoftReference . Om objektet raderades av garbage collector, kommer get ()-metoden plötsligt att börja returnera null."
"Användaren kan också rensa SoftReference explicit genom att anropa metoden clear(). I det här fallet kommer den svaga länken inuti SoftReference -objektet att förstöras."
"Det var allt tills vidare."
"Tack för den intressanta historien, Ellie. Den var verkligen väldigt intressant."
GO TO FULL VERSION