I Microsoft.Net er søppeloppsamling en mekanisme som er tatt i bruk av Common Language Runtime (CLR) for å rydde opp i ressursene som brukes av applikasjonen din. Når du oppretter objekter i .Net, lagres de i den administrerte dyngen. Mens du trenger å lage objekter, trenger du i de fleste tilfeller ikke å være bekymret for å rydde opp i objektene - kjøretiden vil gjøre det for deg.
Du bør imidlertid vedta beste praksis i søknaden din for å lette søppeloppsamling og hjelpe den med å rydde opp ressursene raskere. Selv om .Net er dyktige i å gjenvinne administrerte objekter, bør du følge visse retningslinjer for å legge til rette for raskere søppeloppsamling for å forbedre ytelsen til applikasjonen din. I denne artikkelen vil jeg presentere en diskusjon om hvordan søppelinnsamling fungerer og de beste fremgangsmåtene som er involvert for å legge til rette for søppelinnsamling i .Net.
Når foregår søppelhenting?
Søppeloppsamling finner sted når systemet har lite tilgjengelig fysisk minne eller GC.Collect () metoden kalles eksplisitt i programmets kode. Objekter som ikke lenger er i bruk eller som ikke kan nås fra roten, er kandidater til søppeloppsamling. I det vesentlige renser søppeloppsamleren minnet okkupert av gjenstander som ikke har referanser.
Generasjoner
Kjøretiden organiserer den administrerte dyngen i generasjoner. Den bruker disse generasjonene til å organisere objekter med kort og lang levetid. Det skal bemerkes at søppeloppsamleren jobber mye oftere i de lavere generasjonene enn i de høyere. Generasjon 0 inneholder kortvarige objekter som midlertidige objekter. Når et objekt opprettes, lagres det i generasjon 0 med mindre det er et stort objekt. Hvis objektet er et stort objekt, lagres det i Large Object Heap (LOH) i generasjon 2. I de fleste tilfeller blir generasjon 0-objektene gjenvunnet av søppeloppsamleren når den kjører i bakgrunnen.
Når du skriver kode, bør du følge visse gode fremgangsmåter. Som et eksempel, bør du lage objekter i det lokale omfanget så mye som mulig for å lette søppeloppsamling. Objekter som er opprettet i det høyere omfanget ligger vanligvis i minnet over lengre tid. Du kan dra nytte av CLR-profilen for å forstå fordelingsmønstrene for applikasjonen din.
Du bør unngå å ringe GC.Collect () metoden da den forårsaker en full samling av alle generasjonene (Generasjon 0, 1 og 2). Når du ringer til GC.Collect () metode, besøker kjøretiden alle levende objekter i applikasjonen din. Dette tar lang tid og er følgelig en veldig kostbar operasjon. Som et resultat er det ikke god praksis å ringe GC.Collect () metode.
Hvis du må ringe GC.Collect () metode, bør du ringe GC.WaitForPendingFinalizers () etter samtalen til GC.Collect () for å sikre at den nåværende utførende tråden venter til ferdigbehandlingen av alle objektene er utført.
Deretter bør du ringe til GC.Collect () metoden igjen for å sikre at du samler de døde gjenstandene som er igjen. Disse døde objektene som kan ha blitt opprettet på grunn av kallet til finaliseringsmetoden på objektene. Følgende kodebit viser hvordan disse metodene brukes.
System.GC.Collect ();
System.GC.WaitForPendingFinalizers ();
System.GC.Collect ();
Du bør sørge for at du minimerer skjulte tildelinger og skriver koden din på en slik måte at sjansene for markedsføring av kortvarige gjenstander til høyere generasjoner elimineres. Du bør ikke referere til kortvarige gjenstander fra de langlivede for å unngå markedsføring av kortvarige gjenstander til høyere generasjoner.
Du bør også unngå å skrive ferdig til kursene dine. Hvis du har en finalizer implementert i klassen din, vil objekter av slike klasser bli langvarige objekter ettersom kjøretiden trenger for å markedsføre de endelige gjenstandene til eldre generasjoner. Du bør sette objekter til null før du ringer en langvarig samtale hvis slike objekter ikke er nødvendige av applikasjonen. Hvis du ikke lenger trenger et statisk objekt eller andre objekter i applikasjonen, bør du sette den til null før du ringer en langvarig samtale. Du bør ikke sette lokale variabler til null, da det ikke er nødvendig; kjøretiden kan bestemme hvilket lokalt objekt det ikke er referert til i koden din eller ikke brukes lenger, så du trenger ikke å sette noen lokal variabel til null eksplisitt.
