Hej! Jeg tror ikke, du ville blive meget overrasket, hvis jeg fortalte dig, at din computer har en begrænset mængde hukommelse :)
Selv din harddisk (som er mange, mange gange så stor som RAM) kan blive fyldt med dine yndlingsspil, tv-shows og andre ting. For at forhindre dette i at ske, skal du overvåge den aktuelle tilstand af din computers hukommelse og slette unødvendige filer. Hvordan hænger alt dette sammen med Java-programmering? Helt direkte! Når alt kommer til alt, vil oprettelse af ethvert objekt få Java-maskinen til at allokere hukommelse til det . Et stort program i den virkelige verden skaber titusindvis eller hundredtusindvis af objekter, og en del af hukommelsen er allokeret til hver af dem. Men hvad tror du, hvor mange af disse genstande findes der? Er de "levende" alt imens vores program kører? Selvfølgelig ikke. Selv med alle deres fordele, er Java-objekter ikke udødelige :) Objekter har deres egen livscyklus. I dag tager vi en lille pause fra at skrive kode og udforsker denne proces :) Det er også meget vigtigt for at forstå, hvordan et program fungerer, og for at administrere ressourcer. Så hvor begynder et objekts liv? Som et menneske, fra fødslen, altså når det er skabt.
Først tildeler den virtuelle Java-maskine den nødvendige hukommelse til at skabe objektet. Så opretter den en reference til det (i vores tilfælde, cat) for at gøre det muligt at holde styr på det. Så initialiseres alle variablerne, konstruktøren kaldes, og vores friske objekt lever nu sit eget liv :) Objektlevetider varierer. Der er ingen nøjagtige tal her. Under alle omstændigheder lever et objekt i programmet og udfører dets funktioner i et vist tidsrum. For at være præcis er objektet "levende", så længe der er referencer til det. Så snart der ikke er nogen referencer, "dør" objektet. For eksempel:
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 ophører "Lamborghini Diablo" Car-objektet med at være i live på anden linje. Der var kun én reference til den, og referencen blev sat til null. Da der ikke er nogen tilbageværende referencer til Diablo, bliver det "skrald". En reference behøver ikke at være sat til nul for at dette kan ske:
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;
}
}
Her har vi oprettet et andet objekt og tildelt det til lamborghini-referencen. Nu peger to referencer på Lamborghini Gallardoobjektet, men Lamborghini Diabloobjektet har ingen. Det betyder, at Diablogenstanden bliver til affald. Det er her, Javas indbyggede garbage collector (GC) starter.
Skraldesamleren er en intern Java-mekanisme, der er ansvarlig for at frigøre hukommelse, dvs. fjerne unødvendige genstande fra hukommelsen. Der er en grund til, at vi valgte at repræsentere det med en robotstøvsuger. Skraldesamleren fungerer på nogenlunde samme måde: den "bevæger sig" i dit program i baggrunden og samler affald. Du behøver praktisk talt ikke at interagere med det. Dens opgave er at slette objekter, der ikke længere bruges i programmet. Det frigør således hukommelse til andre objekter. Kan du huske, at du i begyndelsen af lektionen sagde i det virkelige liv skal overvåge din computers tilstand og slette gamle filer? Hvis vi taler om Java-objekter, gør garbage collector dette for dig. Skraldesamleren startes mange gange, mens dit program kører: du behøver ikke udtrykkeligt at kalde det og give det kommandoer (selvom det er teknisk muligt). Vi taler mere om skraldesamleren senere og analyserer, hvordan den fungerer mere detaljeret. Når skraldemanden når frem til en genstand – lige før den bliver ødelagt – finalize()kaldes objektets specielle metode. Denne metode kan påberåbes for at frigive visse yderligere ressourcer, der bruges af objektet. Metoden finalize()tilhører klassen Object. Med andre ord ligner det equals(), hashCode()og toString()(som du tidligere har mødt). Hver genstand har det . Det adskiller sig fra andre metoder ved, at...hvordan skal vi sige dette...det er meget bevidst. Med det mener vi detdet kaldes ikke altid før et objekt er ødelagt . Programmering er en meget præcis aktivitet. Programmøren fortæller computeren at gøre noget, og computeren gør det. finalize()Jeg går ud fra, at du er blevet vant til denne form for adfærd, så i starten kan det være svært for dig at acceptere følgende idé: "Før et objekt ødelægges, kaldes Object-klassens metode. Eller ej. Hvis vi er heldige! " Alligevel er dette virkelighed. Java-maskinen bestemmer selv, om finalize() skal kaldes fra sag til sag. Som et eksperiment, lad os prøve at køre følgende kode:
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 opretter et Catobjekt, og i næste linje nulstiller vi den eneste reference til det. Og det gør vi en million gange. Vi har eksplicit tilsidesat finalize()metoden. Hver gang et Catobjekt ødelægges, skal det vise en streng - i alt en million gange. Men nej! For at være præcis, på min computer blev det kun udført 37346 gange! Med andre ord besluttede min Java-maskine kun at kalde finalize()metoden i 1 ud af 27 tilfælde. I de andre tilfælde involverede affaldsindsamling ikke dette opkald. Prøv selv at køre denne kode. Du vil højst sandsynligt få et andet resultat. Som du kan se, er det svært at kalde finalize()en pålidelig partner :) Så her er et lille tip til fremtiden: Stol ikke på metoden finalize()til at frigive kritiske ressourcer.JVM kalder det måske, eller måske ikke. Hvem ved? Hvis dit objekt havde nogle præstationskritiske ressourcer (for eksempel en åben databaseforbindelse), mens det var i live, ville det være bedre at oprette og eksplicit kalde en speciel metode til at frigive dem, når objektet ikke længere er nødvendigt. På den måde ved du med sikkerhed, at dit programs ydeevne ikke lider skade. Vi startede med at sige, at arbejdet med hukommelse og skraldindsamling er meget vigtige emner, og det er de faktisk. Misbrug af ressourcer og misforståelse af, hvordan unødvendige genstande bliver ryddet op, kan føre til en af de mest ubehagelige fejl: hukommelseslækager . Dette er en af de mest kendte programmeringsfejl. Den har endda sin egen Wikipedia- artikel. Dårligt skrevet kode kan skabe en situation, hvor hukommelse tildeles hver gang til nyoprettede objekter, men gamle, unødvendige objekter er utilgængelige til affaldsindsamling. Da vi allerede har lavet en robotstøvsugeranalogi, så forestil dig, hvad der ville ske, hvis du, inden du kørte robotten, spredte sokker ud over hele huset, smadrede en glasvase og efterlod lego-stykker over hele gulvet. Naturligvis ville robotten forsøge at gøre noget, men en dag vil den gribe fat.
For at støvsugeren kan køre ordentligt, skal du holde gulvet i ordentlig stand og samle alt op, som den ikke kan klare. Affaldssamleren følger samme princip. Hvis et program har mange genstande, som det ikke kan rydde op (som en sok eller Lego til vores robotstøvsuger), vil vi en dag løbe tør for hukommelse. Ikke kun vil dit program hænge, alle de andre programmer, der tilfældigvis kører på computeren, vil også. De vil trods alt heller ikke have nok hukommelse (for at vende tilbage til vores analogi, stopper glasset på gulvet ikke kun støvsugeren, men også de mennesker, der bor i hjemmet). Kort sagt, sådan ser objektlivscyklus og affaldsopsamling ud i Java. Du behøver ikke at huske dette: det er nok blot at forstå, hvordan det fungerer. I næste lektion skal vi vender tilbage til disse processer mere detaljeret. Men indtil videre kan du vende tilbage til at løse CodeGym-opgaver :) Held og lykke!
GO TO FULL VERSION