Hej! Jag tror att du inte skulle bli sÀrskilt förvÄnad om jag berÀttade att din dator har en begrÀnsad mÀngd minne :)
Till och med din hĂ„rddisk (som Ă€r mĂ„nga, mĂ„nga gĂ„nger sĂ„ stor som RAM) kan bli fullproppad med dina favoritspel, TV-program och andra saker. För att förhindra att detta hĂ€nder mĂ„ste du övervaka det aktuella tillstĂ„ndet i din dators minne och radera onödiga filer. Hur hĂ€nger allt detta ihop med Java-programmering? Ganska direkt! NĂ€r allt kommer omkring gör att skapa ett objekt gör att Java-maskinen allokerar minne för det . Ett stort verkligt program skapar tiotals eller hundratusentals objekt, och en bit minne tilldelas för vart och ett av dem. Men vad tror du, hur mĂ„nga av dessa föremĂ„l finns det? Ăr de "levande" hela tiden vĂ„rt program körs? SjĂ€lvklart inte. Ăven med alla sina fördelar Ă€r Java-objekt inte odödliga :) Objekt har sin egen livscykel. Idag tar vi en liten paus frĂ„n att skriva kod och utforskar denna process :) Det Ă€r ocksĂ„ mycket viktigt för att förstĂ„ hur ett program fungerar och för att hantera resurser. SĂ„, var börjar ett objekts liv? Som en mĂ€nniska, frĂ„n födseln, alltsĂ„ nĂ€r den skapas.
Först allokerar den virtuella Java-maskinen det minne som krÀvs för att skapa objektet. Sedan skapar den en referens till den (i vÄrt fall, cat) för att göra det möjligt att hÄlla reda pÄ det. Sedan initieras alla variabler, konstruktorn anropas och vÄrt nya objekt lever nu sitt eget liv :) Objektets livslÀngder varierar. Det finns inga exakta siffror hÀr. I alla hÀndelser lever ett objekt i programmet och utför sina funktioner under en viss tidsperiod. För att vara exakt sÄ Àr föremÄlet "levande" sÄ lÀnge det finns referenser till det. SÄ fort det inte finns nÄgra referenser "dör objektet". Till exempel:
public class Car {
String model;
public Car(String model) {
this.model = model;
}
public static void main(String[] args) {
Car lamborghini = new Car("Lamborghini Diablo");
lamborghini = null;
}
}
I main()metoden upphör objektet "Lamborghini Diablo" Car att vara vid liv pÄ andra raden. Det fanns bara en referens till den, och referensen var instÀlld pÄ null. Eftersom det inte finns nÄgra kvarvarande referenser till Diablo blir det "skrÀp". En referens behöver inte vara noll för att detta ska hÀnda:
public class Car {
String model;
public Car(String model) {
this.model = model;
}
public static void main(String[] args) {
Car lamborghini = new Car("Lamborghini Diablo");
Car lamborghiniGallardo = new Car("Lamborghini Gallardo");
lamborghini = lamborghiniGallardo;
}
}
HÀr har vi skapat ett andra objekt och tilldelat det till lamborghini-referensen. Nu pekar tvÄ referenser till Lamborghini Gallardoobjektet, men Lamborghini Diabloobjektet har ingen. Detta innebÀr att DiabloföremÄlet blir skrÀp. Det Àr dÄ Javas inbyggda garbage collector (GC) slÄr in.
public class Cat {
private String name;
public Cat(String name) {
this.name = name;
}
public Cat() {
}
public static void main(String[] args) throws Throwable {
for (int i = 0 ; i < 1000000; i++) {
Cat cat = new Cat();
cat = null;// The first object becomes available for garbage collection here
}
}
@Override
protected void finalize() throws Throwable {
System.out.println("The Cat is destroyed!");
}
}
Vi skapar ett Catobjekt och pĂ„ nĂ€sta rad nollstĂ€ller vi den enda referensen till det. Och det gör vi en miljon gĂ„nger. Vi har uttryckligen Ă„sidosatt finalize()metoden. Varje gĂ„ng ett Catobjekt förstörs mĂ„ste det visa en strĂ€ng â totalt en miljon gĂ„nger. Men nej! För att vara exakt, pĂ„ min dator kördes det bara 37346 gĂ„nger! Med andra ord, min Java-maskin bestĂ€mde sig för att anropa finalize()metoden i endast 1 av 27 fall. I de andra fallen omfattade inte sophĂ€mtning detta samtal. Testa att köra den hĂ€r koden sjĂ€lv. Du kommer med största sannolikhet att fĂ„ ett annat resultat. Som du kan se Ă€r det svĂ„rt att kalla finalize()en pĂ„litlig partner :) SĂ„ hĂ€r Ă€r ett litet tips för framtiden: lita inte pĂ„ metoden finalize()för att frigöra kritiska resurser.JVM kan kalla det, eller sĂ„ kanske det inte. Vem vet? Om ditt objekt hade nĂ„gra prestandakritiska resurser (till exempel en öppen databasanslutning) medan det levde, skulle det vara bĂ€ttre att skapa och uttryckligen anropa en speciell metod för att frigöra dem nĂ€r objektet inte lĂ€ngre behövs. PĂ„ sĂ„ sĂ€tt vet du sĂ€kert att ditt programs prestanda inte blir lidande. Vi började med att sĂ€ga att arbetet med minne och sophĂ€mtning Ă€r vĂ€ldigt viktiga Ă€mnen, och det Ă€r de verkligen. Felhantering av resurser och missförstĂ„nd av hur onödiga föremĂ„l rensas upp kan leda till en av de mest obehagliga buggarna: minneslĂ€ckor . Detta Ă€r ett av de mest kĂ€nda programmeringsfelen. Den har till och med en egen Wikipedia- artikel. DĂ„ligt skriven kod kan skapa en situation dĂ€r minne tilldelas varje gĂ„ng för nyskapade objekt, men gamla, onödiga objekt Ă€r otillgĂ€ngliga för sophĂ€mtning. Eftersom vi redan har gjort en robotdammsugaranalogi, förestĂ€ll dig vad som skulle hĂ€nda om du innan du körde roboten spred strumpor över hela huset, krossade en glasvas och lĂ€mnade legobitar över hela golvet. Naturligtvis skulle roboten försöka göra nĂ„got, men en dag kommer den att gripa tag.
För att dammsugaren ska fungera som den ska mÄste du hÄlla golvet i hyfsad form och plocka upp allt som den inte klarar av. Sopsamlaren följer samma princip. Om ett program har mÄnga föremÄl som det inte kan stÀda upp (som en strumpa eller lego till vÄr robotdammsugare), kommer vi en dag att fÄ slut pÄ minne. Inte bara kommer ditt program att hÀnga sig, alla andra program som rÄkar köras pÄ datorn kommer ocksÄ att göra det. NÀr allt kommer omkring kommer de inte att ha tillrÀckligt med minne heller (om vi ÄtergÄr till vÄr analogi, det krossade glaset pÄ golvet stoppar inte bara dammsugaren, utan ocksÄ mÀnniskorna som bor i hemmet). Kort sagt, sÄ hÀr ser objekts livscykel och sophÀmtning ut i Java. Du behöver inte memorera detta: det rÀcker att bara förstÄ hur det fungerar. I nÀsta lektion, vi Äterkommer till dessa processer mer i detalj. Men för nu kan du ÄtergÄ till att lösa CodeGym-uppgifter :) Lycka till!
GO TO FULL VERSION