Mere om skraldemanden

Hej! I sidste lektion stiftede vi først bekendtskab med Javas indbyggede skraldeopsamler og fik en nogenlunde idé om, hvordan den fungerer. Det fungerer i baggrunden, mens dit program kører, og samler unødvendige objekter, som vil blive slettet senere. Det frigør således hukommelse, der kan bruges til at skabe nye objekter i fremtiden. I denne lektion vil vi diskutere mere detaljeret, hvordan det fungerer. For eksempel, hvordan og hvornår bliver en genstand unødvendig? Og hvordan finder skraldemanden ud af det? Det er spørgsmål, vi vil besvare i løbet af dagens lektion :) Lektionen vil mere være et overblik: du behøver ikke lære dette materiale udenad. Hensigten er primært at udvide din vision med hensyn til, hvordan hukommelsen og skraldesamleren fungerer, så læs bare igennem og find noget nyt til dig selv :) Lad os gå! Det første du skal huske er, at skraldesamleren arbejder parallelt med dit program. Det er ikke en del af dit program. Den kører separat (i sidste lektion sammenlignede vi dette med en robotstøvsuger) Men det var det ikke altid. Affaldsindsamling plejede at blive udført på samme tråd som dit program. På en eller anden tidsplan (en gang hvert par minutter) ville skraldeopsamleren tjekke for tilstedeværelsen af ​​uønskede objekter i programmet. Problemet var, at programmet ville hænge (ikke køre) under denne kontrol og affaldsindsamling. Forestil dig, at du sidder på dit kontor på arbejde. Men så kommer rengøringsdamen ind for at vaske gulvene. Hun kører dig væk fra din computer i 5 minutter, og du venter, indtil hun er færdig med at gøre rent. I dette tidsrum er du ude af stand til at arbejde. Sådan plejede affaldsindsamlingen at virke :) Denne mekanisme blev senere ændret, og nu kører affaldsopsamleren i baggrunden, ikke hindrer selve programmets arbejde. Du ved allerede, at et objekt dør, når det ikke længere har referencer. I virkeligheden,affaldssamleren tæller ikke objektreferencer . For det første kan dette tage lang tid. For det andet er det ikke særlig effektivt. Objekter kan jo referere til hinanden! Figuren viser et eksempel, hvor 3 objekter refererer til hinanden, men ingen andre henviser til dem. Med andre ord har resten af ​​programmet ikke brug for dem. Hvis skraldesamleren blot talte referencer, ville disse 3 genstande ikke blive indsamlet, og hukommelsen ville ikke blive frigivet (der er referencer til dem!). Vi kan sammenligne dette med et rumfartøj. Under flyvningen beslutter astronauterne at tjekke listen over reservedele, der er tilgængelige til reparation. De finder blandt andet et rat og pedaler fra en almindelig bil. Det er klart, at de ikke er nødvendige her og fylder unødigt (selvom disse to dele er relateret til hinanden og har nogle funktioner). Men inde i rumfartøjet er de ubrugeligt affald, der bør kasseres. Derfor blev beslutningen i Java truffet om at indsamle skrald baseret på referencetælling,tilgængelig og uopnåelig . Hvordan afgør vi, om et objekt er tilgængeligt? Det hele er simpelthen genialt. Et objekt er tilgængeligt, hvis det refereres af et andet tilgængeligt objekt. Dermed får vi en "kæde af tilgængelighed". Det starter, når programmet starter, og fortsætter i hele programmets varighed. Det ser nogenlunde sådan ud: Pilen i figuren angiver vores programs eksekverbare kode. Koden (for eksempel metoden main()) skaber referencer til objekter. Disse objekter kan henvise til andre objekter, disse objekter til endnu andre, og så videre. Dette danner en referencekæde. Hvis du kan spore til kæde fra et objekt til "rodreferencen" (den der er oprettet direkte i eksekverbar kode), så anses det for at være tilgængeligt. Sådanne genstande er markeret med sort på billedet. Men et objekt er uopnåeligt, hvis objektet falder ud af denne kæde, dvs. ingen af ​​variablerne i den kode, der udføres i øjeblikket, refererer til det, og det kan ikke nås gennem "referencekæden". I vores program er to sådanne objekter markeret rødt. Bemærk, at disse "røde" objekter har referencer til hinanden. Men som vi sagde tidligere, tæller Javas moderne skraldeopsamler ikke referencer. Det bestemmer, om et objekt kan nås eller ikke kan nås. Som et resultat vil den gribe om de to røde genstande på figuren. Lad os nu se på hele processen fra start til slut. På den måde vil vi også se, hvordan hukommelsen er arrangeret i Java :) Alle Java-objekter er gemt i et særligt hukommelsesområde kaldet heapen . I daglig tale er en bunke som regel et bjerg af genstande, hvor alt er blandet. Men det er ikke, hvad dyngen er i Java. Dens struktur er meget logisk og rimelig. På et tidspunkt fandt Java-programmører ud af, at alle deres objekter kunne opdeles i to typer: simple objekter og "objekter med lang levetid". "Langlivede genstande" er genstande, der har overlevet mange omgange med affaldsindsamling. De lever normalt indtil programmet slutter. Til sidst blev den fulde bunke, hvor alle genstande er gemt, opdelt i flere dele. Den første del har et smukt navn: eden(fra den bibelske "Edens Have"). Dette navn er passende, for det er her, objekter ender, efter de er oprettet. Dette er den del af hukommelsen, hvor nye objekter skabes, når vi bruger nøgleordet ny. Der kan skabes mange objekter. Når dette område løber tør for plads, begynder en indledende "hurtig" affaldsindsamling. Vi må sige, at skraldesamleren er meget klog. Den vælger en algoritme baseret på, om dyngen har mere affald eller flere levende objekter. Hvis næsten alle genstandene er skrald, markerer samleren de levende genstande og flytter dem til et andet hukommelsesområde. Så er det nuværende område helt ryddet. Hvis der ikke er meget affald, og dyngen for det meste er levende genstande, markerer samleren affaldet, rydder det og pakker de andre genstande sammen. Vi sagde "et overlevelsesrum . Et overlevelsesrum er til gengæld opdelt i generationer . Hver genstand tilhører en bestemt generation, afhængigt af hvor mange runder af affaldsindsamling den har overlevet. Hvis en genstand har overlevet en omgang affaldsopsamling, så er den i "Generation 1"; hvis 5, så "Generation 5". Sammen danner eden og et overlevelsesrum et område kaldet den unge generation . Ud over den unge generation har bunken et andet hukommelsesområde kaldet den gamle generation. Det er netop det område, hvor langlivede genstande, der har overlevet mange omgange med affaldsindsamling, ender. Der er fordele ved at holde dem adskilt fra alle de andre. Fuld affaldsindsamling udføres kun, når den gamle generation er fuld, dvs. der er så mange langlivede objekter i programmet, at der ikke er nok hukommelse. Denne proces involverer mere end ét hukommelsesområde. Generelt involverer det alle de objekter, der er oprettet af Java-maskinen. Det tager naturligvis meget mere tid og ressourcer. Dette er netop beslutningen om at opbevare langlivede genstande separat. "Hurtig affaldsindsamling" udføres, når andre områder løber tør for plads. Dette involverer kun ét område, hvilket gør det hurtigere og mere effektivt. Endelig, når selv området for langlivede genstande er helt fyldt, fuld affaldsindsamling udløses. Således bruger samleren kun det "tyngste" værktøj, når det er umuligt at undgå det. Her er en visuel repræsentation af bunkens struktur og affaldsopsamling: