1. Betydningen av avfallsresirkuleringsmekanismen
En bemerkelsesverdig egenskap ved Java-språket er innføringen av en søppelryddingsmekanisme, som løser det mest problematiske minnehåndteringsproblemet for C++-programmerere, slik at Java-programmerere ikke lenger trenger å vurdere minnehåndtering når de skriver programmer. På grunn av garbage collection-mekanismen har objekter i Java ikke lenger konseptet "scope", kun referansen til objektet har et "scope".Garbage collection kan effektivt forhindre minnelekkasje og bruke ledig minne effektivt.
ps:内存泄露是指该内存空间使用完毕之后未回收，在不涉及复杂数据结构的一般情况下，Java 的内存泄露表现为一个内存对象的生命周期超出了程序需要它的时间长度，我们有时也将其称为“对象游离”。
2. Algoritmer i søppelinnsamlingsmekanismer
Java-språkspesifikasjonen spesifiserer ikke eksplisitt hvilken søppelryddingsalgoritme som skal brukes i JVM, men enhver søppelryddingsalgoritme må vanligvis gjøre to grunnleggende ting: (1) finne unyttige informasjonsobjekter; (2) Gjenerobre minneplassen som er opptatt av ubrukelige objekter, slik at plassen kan brukes igjen av programmet.
1. Referansetellingsinnsamler
1.1 Algoritmeanalyse
Referansetelling er en tidlig strategi i søppelsamlere. I denne tilnærmingen er det en referansetelling for hver objektinstans i heapen. Når et objekt opprettes og objektinstansen tildeles en variabel, settes variabelantallet til 1. Når en annen variabel tildeles som referanse til dette objektet, legges tellingen til med 1 (a = b, da er telleren til objektinstansen referert til av b +1), men når en referanse til en objektinstans har overskredet levetiden eller settes til en ny verdi, trekkes referansetelleren til objektinstansen fra med 1. Enhver forekomst av et objekt med en referanseteller på 0 kan samles som søppel. Når en objektinstans samles inn i søppel, er referansetelleren til enhver objektinstans den refererer til minus 1.
1.2 Fordeler og ulemper
Fortjeneste:
Referansetellingssamleren kan utføres svært raskt, integrert i programmets løp. Det er fordelaktig for sanntidsmiljøer hvor programmer ikke trenger å avbrytes over lengre tid.
Brist:
Sirkulære referanser kan ikke oppdages. *Hvis foreldreobjektet har en referanse til et barneobjekt, refererer barneobjektet igjen til foreldreobjektet. På denne måten kan deres siteringsantall aldri være 0.
1.3 Referansetellingsalgoritmen kan ikke løse det sirkulære referanseproblemet, for eksempel:
/** * Java学习交流QQ群：589809992 我们一起学Java！ */public class Main { public static void main(String[] args) { MyObject object1 = new MyObject(); MyObject object2 = new MyObject(); object1.object = object2; object2.object = object1; object1 = null; object2 = null; }}
De to siste setningene tildeler objekt1 og objekt2 null, noe som betyr at objekt1 og objekt2 peker på ikke lenger kan nås, men fordi de refererer til hverandre, er referansetellerne deres ikke 0, så søppelsamleren vil aldri resirkulere dem.
2. Tracing Collector eller and sweep-algoritme
2.1 Rotsøkealgoritme
![]()
Rotsøkealgoritmen er introdusert fra grafteori i diskret matematikk, programmet betrakter alle referanserelasjoner som en graf, med start fra en node GC ROOT, leter etter den tilsvarende referansenoden, etter å ha funnet denne noden, fortsetter man å lete etter referansenoden til denne noden, når alle referansenodene er søkt, regnes de resterende nodene som urefererte noder, det vil si ubrukelige noder.
Java som kan brukes som GC-rot
1. Objekter referert i den virtuelle maskinstakken (tabell for lokale variabler)
2. Objektet referert til av det statiske attributtet i metodeområdet
3. Objektet som refereres til av konstanten i metodeområdet
4. Refererte objekter i den lokale metodestakken (native objekter)
2.2 Skjematisk diagram for sporingsalgoritmen
![]()
2.3 Analyse av markørryddingsalgoritmen
Tag-purge-algoritmen skanner fra rotsamlingen, markerer de overlevende objektene, og skanner deretter hele området etter umerkede objekter å resirkulere, som vist i figuren over. Tag-purge-algoritmen trenger ikke å flytte objekter, og behandler kun ikke-overlevende objekter, noe som er ekstremt effektivt når det er mange overlevende objekter, men fordi tag-purge-algoritmen direkte resirkulerer ikke-overlevende objekter, vil det føre til minnefragmentering.
3. Kompakteringsalgoritme eller label-finishing-algoritme
![]()
Tag-finish-algoritmen bruker samme metode som tag-clear-algoritmen for å merke objekter, men den er annerledes ved rensing; etter å ha gjenvunnet plassen som ikke overlevde objekter har opptatt, vil den flytte alle overlevende objekter til det ledige området i venstre ende og oppdatere den tilsvarende pekeren. Tag-finish-algoritmen er basert på tag-purge-algoritmen og flytter objekter, så den er dyrere, men den løser problemet med minnefragmentering. I implementeringen av collectors basert på Compacting-algoritmen legges vanligvis til håndtere- og håndtakstabeller.
4. Kopieringsalgoritme (Kompakteringssamler)
![]()
Algoritmen foreslås for å overvinne overheaden til håndtaket og løse søppelsamlingen av heap-rester. Når objektet er fullt, skanner søppelsamlingen basert på kopieringsalgoritmen det aktive objektet fra rotsettet, og kopierer hvert aktivt objekt til den frie flaten (slik at det ikke er noen ledige hull mellom minnet som det aktive objektet opptar), slik at den frie flaten blir objektflaten, den opprinnelige objektflaten blir den frie flaten, og programmet allokerer minne i den nye objektflaten. En typisk søppelsamling basert på coping-algoritmen er stop-and-copy-algoritmen, som deler heapen inn i objektflater og frie områdeflater, og programmet pauser kjøringen under vekslingen mellom objektflater og frie områdeflater.
5. Generasjonssamler
![]()
Generasjonsstrategien for søppelgjenvinning er basert på atLivssyklusen til ulike objekter er forskjellig。 Derfor kan objekter med ulike livssykluser ta i bruk ulike resirkuleringsalgoritmer for å forbedre resirkuleringseffektiviteten.
Ung generasjon
1. Alle nylig genererte objekter plasseres først i den yngre generasjonen. Målet til den yngre generasjonen er å samle disse objektene med kort livssyklus så raskt som mulig.
2. Den nye generasjonens minne deles inn i én Eden-region og to overlevende (overlevende0, overlevende1) soner i henhold til forholdet 8:1:1. En Eden-sone, to overlevelsessoner (generelt). De fleste objektene spawnes i Eden-området. Når survivor0-området også er fullt, kopieres eden-området og survivor 0-området til et annet survivor1-område, og deretter tømmes eden- og survivor0-området, og survivor0-området er tomt, og survivor0-området og survivor1-området byttes ut. Det vil si, hold survivor1-området tomt, og så videre.
3. Når Survivor 1-området ikke er nok til å lagre de overlevende objektene fra Eden og Survivor0, lagres de overlevende objektene direkte til den gamle æraen. Hvis alderdommen også er full, vil det utløse en full GC, det vil si at den nye generasjonen og den gamle generasjonen vil bli resirkulert
4. GC for den nye generasjonen kalles også Minor GC, og frekvensen av MinorGC er relativt høy (den utløses ikke nødvendigvis når Eden-området er fullt)
Gammel generasjon
1. Gjenstander som fortsatt lever etter å ha opplevd N søppelgjenvinning i den yngre generasjonen, vil bli plassert i den eldre generasjonen. Derfor kan det betraktes som at den gamle generasjonen lagres i noen objekter med lang livssyklus.
2. Hukommelsen er også mye større enn for den nye generasjonen (det omtrentlige forholdet er 1:2), når hukommelsen om alderdommen er full, utløses Major GC, det vil si Full GC, er frekvensen av Full GC relativt lav, overlevelsestiden til det gamle objektet er relativt lang, og overlevelsesraten er høy.
Permanent generasjon
Brukes til å lagre statiske filer, som Java-klasser, metoder osv. Persistente genereringer har ingen betydelig innvirkning på søppelrydding, men noen applikasjoner kan dynamisk generere eller kalle noen klasser, som Hibernate osv., og i dette tilfellet må et relativt stort persistent genereringsområde settes for å lagre disse nye klassene under kjøretiden.
3. GC (Søppelsamler)Samlere brukt av den nye generasjonen samlere: Serial, PraNew, Parallel Scavenge
Samlere brukt av gamle tidssamlere: Seriell gammel, parallell gammel, CMS
![]()
Seriell samler (replikasjonsalgoritme)
Den nye generasjonen enkelttrådede samlere, merking og rengjøring er enkelttrådede, med fordelen av å være enkle og effektive.
Seriell gammel samler (etikett-finish-algoritme)
Old Age Single Thread Collector, Old Age versjon av Serial Collector.
ParNew-samler (stop-copy algoritme)
Den nye generasjonen collector kan betraktes som en flertrådet versjon av Serial collector, som har bedre ytelse enn Serial i et flerkjerners CPU-miljø.
Parallell Scavenge Collector (Stop-Copy-algoritme)
Parallelle kollektorer for høy gjennomstrømning og effektiv CPU-utnyttelse. Gjennomstrømningen er vanligvis 99 %, og gjennomstrømningen = brukertrådtid / (brukertrådtid + GC-trådtid). Den er egnet for scenarier som bakgrunnsapplikasjoner som ikke krever høy interaksjon tilsvarende.
Parallell gammel samler (stop-copy algoritme)
En eldre versjon av Parallel Scavenge-kollektoren, en parallellkollektor, med gjennomstrømningsprioritet
CMS (Concurrent Sweep) Collector (-Clean-algoritme)
Høy samtidighet, lav pause, jakt på korteste GC-gjenopprettingspausetid, høy CPU-bruk, rask responstid, kort pausetid, og flerkjerne-CPU som jakter på høy responstid
4. Implementeringsmekanismen til GCSiden objektet har blitt behandlet i ulike generasjoner, er også området og tidspunktet for søppelinnsamling forskjellig. Det finnes to typer GC: Scavenge GC og Full GC.
Scavenge GC
Normalt, når et nytt objekt genereres og ikke søker plass i Eden, vil Scavenge GC bli utløst, som vil GC Eden-området, rydde ikke-overlevende objekter og flytte de overlevende objektene til Survivor-området. Deretter sorterer du de to sonene i Survivor. GC utføres på denne måten i Eden-området til den yngre generasjonen og påvirker ikke den eldre generasjonen. Siden de fleste objekter starter fra Eden-området, og Eden-området ikke er tildelt særlig mye, utføres GC for Eden-området ofte. Derfor er det generelt nødvendig å bruke raske og effektive algoritmer her for å gjøre Eden gratis så raskt som mulig.
Full GC
Organiser hele bunken, inkludert Young, Tenured og Perm. Full GC er tregere enn Scavenge GC fordi det krever resirkulering av hele haugen, så antallet Full GCs bør reduseres så mye som mulig. En stor del av JVM-tuningprosessen er tuning av FullGC. Full GC kan skyldes følgende årsaker:
1. Tenured er skrevet fullt ut
2. Perm skrives fullt ut
3. System.gc() vises som et anrop
4. Heaps domeneallokeringsstrategi endres dynamisk etter siste GC
5. Java med GC vil også ha problemer med minnelekkasje1. Bruken av statiske samlingsklasser som HashMap, Vector osv. er mest utsatt for minnelekkasje, og livssyklusen til disse statiske variablene er den samme som for applikasjonen, og alle objekter kan ikke frigis, fordi de alltid vil bli brukt av Vector og andre.
Statisk vektor v = ny vektor(); for (int i = 1; i<100; i++) { Objekt o = nytt Objekt(); v.add(o); o = null; }
I dette eksempelet finnes det en referanse v for Vector-objektet og en referanse o for Object-objektet i kodestakken. I For-løkken fortsetter vi å generere nye objekter, legger dem til Vector-objektet, og nulliserer deretter o-referansen. Spørsmålet er, når o-referansen nulliseres, hvis GC oppstår, kan Objektobjektet vi opprettet resirkuleres av GC? Svaret er nei. Fordi når GC sporer referanser i kodestakken, finner den v-referanser, og hvis du fortsetter å spore nedover, vil du oppdage at det finnes referanser til objektobjekter i minnerommet som v-referanser peker på. Dette betyr at selv om o-referansen er tømt, finnes det fortsatt andre referanser til Objektobjektet som kan nås, så GC kan ikke frigjøre dem. Hvis objektobjektet etter denne løkken ikke har noen effekt på programmet, antar vi at Java-programmet har en minnelekkasje.
2. Ulike tilkoblinger, databaseforbindelser, nettverksforbindelser, IO-tilkoblinger osv. viser ikke samtalen nær til lukket, og blir ikke gjenbrukt av GC, noe som resulterer i minnelekkasje.
3. Bruken av lyttere kan også føre til minnelekkasje når lytteren ikke slettes mens objektet slippes.
|
Publisert på 04.12.2017 20:26:51
|
|
|
