Hei! Jeg tror du ikke ville bli veldig overrasket om jeg fortalte deg at datamaskinen din har begrenset mengde minne :)
Selv harddisken din (som er mange, mange ganger så stor som RAM) kan bli stappfull av favorittspillene dine, TV-programmene og andre ting. For å forhindre at dette skjer, må du overvåke den nåværende tilstanden til datamaskinens minne og slette unødvendige filer. Hvordan forholder alt dette seg til Java-programmering? Ganske direkte! Når alt kommer til alt, får Java-maskinen til å tildele minne for det å lage et objekt . Et stort program i den virkelige verden lager titusenvis eller hundretusenvis av objekter, og en del av minnet er tildelt hver av dem. Men hva tror du, hvor mange av disse gjenstandene finnes? Er de "levende" mens programmet vårt kjører? Selvfølgelig ikke. Selv med alle sine fordeler, er ikke Java-objekter udødelige :) Objekter har sin egen livssyklus. I dag tar vi en liten pause fra å skrive kode og utforsker denne prosessen :) Det er også veldig viktig for å forstå hvordan et program fungerer og for å administrere ressurser. Så, hvor begynner et objekts liv? Som et menneske, fra fødselen, altså når det er skapt.
Først tildeler den virtuelle Java-maskinen minnet som er nødvendig for å lage objektet. Deretter oppretter den en referanse til den (i vårt tilfelle, cat) for å gjøre det mulig å holde styr på den. Deretter initialiseres alle variablene, konstruktøren kalles, og vårt ferske objekt lever nå sitt eget liv :) Objektlevetiden varierer. Det er ingen eksakte tall her. Uansett bor et objekt i programmet og utfører funksjonene i en viss tidsperiode. For å være presis er objektet "levende" så lenge det er referanser til det. Så snart det ikke er noen referanser, "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 slutter "Lamborghini Diablo" Car-objektet å være i live på den andre linjen. Det var bare én referanse til den, og referansen ble satt til null. Siden det ikke er noen gjenværende referanser til Diablo, blir den "søppel". En referanse trenger ikke settes til null for at dette skal skje:
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 laget et andre objekt og tilordnet det til lamborghini-referansen. Nå peker to referanser til objektet Lamborghini Gallardo, men Lamborghini Diabloobjektet har ingen. Dette betyr at Diabloobjektet blir søppel. Dette er når Javas innebygde søppeloppsamler (GC) starter.
Søppelsamleren er en intern Java-mekanisme som er ansvarlig for å frigjøre minne, dvs. fjerne unødvendige gjenstander fra minnet. Det er en grunn til at vi valgte å representere det med en robotstøvsuger. Søppelsamleren fungerer omtrent på samme måte: den "beveger seg rundt" programmet ditt i bakgrunnen og samler søppel. Du trenger praktisk talt ikke å samhandle med det. Dens jobb er å slette objekter som ikke lenger brukes i programmet. Dermed frigjør det minne for andre objekter. Husker du at du i begynnelsen av leksjonen sa i det virkelige liv må overvåke datamaskinens tilstand og slette gamle filer? Hvis vi snakker om Java-objekter, gjør søppelsamleren dette for deg. Søppelsamleren startes mange ganger mens programmet kjører: du trenger ikke eksplisitt kalle det og gi det kommandoer (selv om dette er teknisk mulig). Vi skal snakke mer om søppelsamleren senere og analysere hvordan den fungerer mer detaljert. Når søppelsamleren når en gjenstand – like før den blir ødelagt – finalize()kalles gjenstandens spesielle metode. Denne metoden kan påkalles for å frigjøre visse tilleggsressurser som brukes av objektet. Metoden finalize()tilhører klassen Object. Med andre ord, det ligner på equals(), hashCode()og toString()(som du tidligere har møtt). Hvert objekt har det . Det skiller seg fra andre metoder ved at...hvordan skal vi si dette...det er veldig bevisst. Med det mener vi detdet kalles ikke alltid før et objekt blir ødelagt . Programmering er en veldig presis aktivitet. Programmereren ber datamaskinen gjøre noe, og datamaskinen gjør det. finalize()Jeg antar at du har blitt vant til denne typen oppførsel, så i begynnelsen kan det være vanskelig for deg å akseptere følgende idé: "Før et objekt blir ødelagt, kalles Object-klassens metode. Eller ikke. Hvis vi er heldige! " Likevel er dette virkeligheten. Java-maskinen bestemmer selv om finalize() skal kalles fra sak til sak. La oss prøve å kjøre følgende kode som et eksperiment:
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 lager et Catobjekt, og i neste linje nullstiller vi den eneste referansen til det. Og det gjør vi en million ganger. Vi har eksplisitt overstyrt finalize()metoden. Hver gang et Catobjekt blir ødelagt, må det vise en streng – totalt én million ganger. Men nei! For å være nøyaktig, på min datamaskin ble det utført bare 37346 ganger! Med andre ord, min Java-maskin bestemte seg for å kalle finalize()metoden i bare 1 av 27 tilfeller. I de andre tilfellene innebar ikke søppelhenting denne samtalen. Prøv å kjøre denne koden selv. Du vil mest sannsynlig få et annet resultat. Som du kan se, er det vanskelig å kalle finalize()en pålitelig partner :) Så, her er et lite tips for fremtiden: ikke stol på finalize()metoden for å frigjøre kritiske ressurser.JVM kan kalle det, eller kanskje ikke. Hvem vet? Hvis objektet ditt hadde noen ytelseskritiske ressurser (for eksempel en åpen databaseforbindelse) mens det var i live, ville det være bedre å opprette og eksplisitt kalle en spesiell metode for å frigjøre dem når objektet ikke lenger er nødvendig. På den måten vil du være sikker på at programmets ytelse ikke vil lide. Vi startet med å si at arbeid med hukommelse og søppelinnsamling er veldig viktige temaer, og det er de faktisk. Feilhåndtering av ressurser og misforståelse av hvordan unødvendige gjenstander ryddes opp kan føre til en av de mest ubehagelige feilene: minnelekkasjer . Dette er en av de mest kjente programmeringsfeilene. Den har til og med sin egen Wikipedia- artikkel. Dårlig skrevet kode kan skape en situasjon der minne tildeles hver gang for nyopprettede objekter, men gamle, unødvendige objekter er utilgjengelige for søppelinnsamling. Siden vi allerede har laget en robotstøvsugeranalogi, forestill deg hva som ville skje hvis du før du kjørte roboten spredte sokker over hele huset, knuste en glassvase og la igjen legobiter over hele gulvet. Naturligvis ville roboten prøve å gjøre noe, men en dag vil den gripe tak.
For at støvsugeren skal gå som den skal, må du holde gulvet i grei form og plukke opp alt den ikke kan håndtere. Søppelsamleren følger samme prinsipp. Hvis et program har mange gjenstander som det ikke kan rydde opp i (som en sokk eller Lego for robotstøvsugeren vår), vil vi en dag gå tom for minne. Ikke bare vil programmet henge, det vil også alle de andre programmene som tilfeldigvis kjører på datamaskinen. Tross alt vil de heller ikke ha nok hukommelse (for å gå tilbake til vår analogi, det knuste glasset på gulvet stopper ikke bare støvsugeren, men også menneskene som bor i hjemmet). Kort sagt, dette er hvordan objektlivssyklus og søppelinnsamling ser ut i Java. Du trenger ikke å huske dette: det er nok å bare forstå hvordan det fungerer. I neste leksjon skal vi vil komme tilbake til disse prosessene mer detaljert. Men foreløpig kan du gå tilbake til å løse CodeGym-oppgaver :) Lykke til!
GO TO FULL VERSION