Mer om sophämtaren

Hej! På förra lektionen bekantade vi oss först med Javas inbyggda sopsamlare och fick en ungefärlig uppfattning om hur det fungerar. Det fungerar i bakgrunden medan ditt program körs och samlar in onödiga objekt som kommer att raderas senare. Således frigör det minne som kan användas för att skapa nya objekt i framtiden. I den här lektionen kommer vi att diskutera mer i detalj hur det fungerar. Till exempel, hur och när blir ett föremål onödigt? Och hur får sopsamlaren reda på det? Det här är frågor vi kommer att besvara under dagens lektion :) Lektionen blir mer som en översikt: du behöver inte lära dig det här materialet utantill. Avsikten är främst att utöka din vision angående hur minnet och sopsamlaren fungerar, så det är bara att läsa igenom och hitta något nytt för dig själv :) Let's go! Det första du behöver komma ihåg är att sopsamlaren arbetar parallellt med ditt program. Det är inte en del av ditt program. Den körs separat (i förra lektionen jämförde vi detta med en robotdammsugare) Men det var inte alltid så. Sophämtning brukade utföras på samma tråd som ditt program. På något schema (en gång med några minuters mellanrum) skulle sophämtaren kontrollera förekomsten av oönskade föremål i programmet. Problemet var att programmet skulle hänga (inte köras) under denna kontroll och skräphämtning. Föreställ dig att du sitter på ditt kontor på jobbet. Men så kommer städerskan in för att tvätta golven. Hon kör bort dig från din dator i 5 minuter och du väntar tills hon har städat klart. Under den här tiden kan du inte arbeta. Ungefär så fungerade sophämtning förr :) Denna mekanism ändrades senare, och nu kör sophämtaren i bakgrunden, inte hindrar själva programmets arbete. Du vet redan att ett objekt dör när det inte längre har referenser. I verkligheten,sopsamlaren räknar inte objektreferenser . För det första kan det här ta lång tid. För det andra är det inte särskilt effektivt. Föremål kan ju hänvisa till varandra! Figuren visar ett exempel där 3 objekt hänvisar till varandra, men ingen annan hänvisar till dem. Med andra ord, resten av programmet behöver dem inte. Om sopsamlaren helt enkelt räknade referenser skulle dessa 3 objekt inte samlas in och minnet skulle inte frigöras (det finns referenser till dem!). Vi kan jämföra detta med en rymdfarkost. Under flygningen bestämmer sig astronauterna för att kontrollera listan över reservdelar som är tillgängliga för reparation. Bland annat hittar de en ratt och pedaler från en vanlig bil. Uppenbarligen behövs de inte här och tar upp plats i onödan (även om dessa två delar är relaterade till varandra och har vissa funktioner). Men inne i rymdskeppet är de värdelöst skräp som bör slängas. Följaktligen, i Java, togs beslutet att samla in sopor baserat inte på referensräkning,nåbar och oåtkomlig . Hur avgör vi om ett objekt är nåbart? Det hela är helt enkelt genialiskt. Ett objekt är nåbart om det refereras av ett annat nåbart objekt. Därmed får vi en "kedja av nåbarhet". Det startar när programmet startar och fortsätter under programmets varaktighet. Det ser ut ungefär så här: Pilen i figuren indikerar vårt programs körbara kod. Koden (till exempel metoden main()) skapar referenser till objekt. Dessa objekt kan referera till andra objekt, dessa objekt till ytterligare andra, och så vidare. Detta bildar en referenskedja. Om du kan spåra till kedja från ett objekt till "rotreferensen" (den som skapats direkt i körbar kod), så anses det nåbart. Sådana föremål är svartmarkerade på bilden. Men ett objekt går inte att nå om objektet faller ur denna kedja, dvs ingen av variablerna i koden som körs för närvarande refererar till det, och det kan inte nås genom "referenskedjan". I vårt program är två sådana objekt rödmarkerade. Observera att dessa "röda" objekt har referenser till varandra. Men som vi sa tidigare, Javas moderna sophämtare räknar inte referenser. Det avgör om ett objekt är nåbart eller oåtkomligt. Som ett resultat kommer den att gripa de två röda föremålen i figuren. Låt oss nu titta på hela processen från början till slut. När vi gör det kommer vi också att se hur minnet är ordnat i Java :) Alla Java-objekt lagras i ett speciellt minnesområde som kallas heapen . I vardagsspråket är en hög vanligtvis ett berg av föremål, där allt är blandat. Men det är inte vad högen är i Java. Dess struktur är mycket logisk och rimlig. Vid något tillfälle upptäckte Java-programmerare att alla deras objekt kunde delas in i två typer: enkla objekt och "långlivade objekt". "Långlivade föremål" är föremål som har överlevt många omgångar av sophämtning. De lever vanligtvis tills programmet slutar. Till slut delades hela högen, där alla föremål är lagrade, upp i flera delar. Den första delen har ett vackert namn: eden(från den bibliska "Edens trädgård"). Det här namnet är passande, eftersom det är här objekt hamnar efter att de har skapats. Detta är den del av minnet där nya objekt skapas när vi använder nyckelordet ny. Många objekt kan skapas. När detta område får ont om utrymme börjar en första "snabb" sophämtning. Vi måste säga att sopsamlaren är väldigt smart. Den väljer en algoritm baserat på om högen har mer skräp eller fler levande objekt. Om nästan alla föremål är skräp, markerar samlaren de levande föremålen och flyttar dem till ett annat minnesområde. Då är det aktuella området helt röjt. Om det inte finns mycket sopor och högen mestadels består av levande föremål, markerar samlaren skräpet, rensar det och packar ihop de andra föremålen. Vi sa "ett överlevnadsutrymme . Ett överlevnadsutrymme är i sin tur uppdelat i generationer . Varje föremål tillhör en viss generation, beroende på hur många omgångar av sophämtning det har överlevt. Om ett föremål har överlevt en omgång av sophämtning, så är det i "Generation 1"; om 5, sedan "Generation 5". Tillsammans bildar eden och ett överlevnadsutrymme ett område som kallas den unga generationen . Förutom den unga generationen har högen ett annat minnesområde som kallas den gamla generationen. Det är just det området där långlivade föremål som överlevt många omgångar av sophämtning hamnar. Det finns fördelar med att hålla dem åtskilda från alla andra. Full sophämtning utförs först när den gamla generationen är full, dvs det finns så många långlivade objekt i programmet att det inte finns tillräckligt med minne. Denna process involverar mer än ett minnesområde. I allmänhet involverar det alla objekt som skapats av Java-maskinen. Naturligtvis tar detta mycket mer tid och resurser. Detta är precis beslutet togs att lagra långlivade föremål separat. "Snabb sophämtning" utförs när andra områden får ont om utrymme. Det handlar bara om ett område, vilket gör det snabbare och mer effektivt. Slutligen, när även området för långlivade föremål är helt fyllt, full sophämtning utlöses. Således använder samlaren det "tyngsta" verktyget endast när det är omöjligt att undvika det. Här är en visuell representation av högstrukturen och sophämtning: