I Microsoft.Net er affaldsindsamling en mekanisme, der er vedtaget af Common Language Runtime (CLR) til at rydde op i de ressourcer, der forbruges af din applikation. Når du opretter objekter i .Net, gemmes de i den administrerede bunke. Mens du har brug for at oprette objekter, behøver du i de fleste tilfælde ikke være bekymret for at rense objekterne - runtime ville gøre det for dig.
Du bør dog vedtage bedste praksis i din ansøgning for at gøre det lettere at indsamle affald og hjælpe det med at rydde op i ressourcerne hurtigere. Selvom .Net er dygtige til at genvinde administrerede objekter, skal du følge visse retningslinjer for at lette hurtigere affaldsindsamling for at forbedre ydeevnen for din applikation. I denne artikel vil jeg gerne præsentere en diskussion om, hvordan affaldsindsamling fungerer, og de bedste fremgangsmåder, der er involveret for at lette affaldsindsamling i .Net.
Hvornår finder affaldsindsamling sted?
Affaldsindsamling finder sted, når systemet er lavt på den tilgængelige fysiske hukommelse eller GC.Collect () metode kaldes eksplicit i din applikations kode. Objekter, der ikke længere bruges eller ikke kan nås fra roden, er kandidater til affaldsindsamling. I det væsentlige renser affaldssamleren hukommelsen, der er optaget af objekter, der ikke har nogen referencer.
Generationer
Runtime organiserer den administrerede dyng i generationer. Det bruger disse generationer til at organisere objekter med kort og lang levetid. Det skal bemærkes, at affaldssamleren arbejder meget oftere i de lavere generationer end i de højere. Generation 0 indeholder kortvarige objekter såsom midlertidige objekter. Når et objekt oprettes, gemmes det i generation 0, medmindre det er et stort objekt. Hvis objektet er et stort objekt, gemmes det i LOH (Large Object Heap) i Generation 2. Generelt genvindes Generation 0-objekterne i affaldssamleren, når de kører i baggrunden.
Når du skriver kode, skal du overholde visse bedste fremgangsmåder. Som et eksempel skal du oprette objekter i det lokale omfang så meget som muligt for at lette affaldsindsamling. Objekter, der oprettes i det højere omfang, ligger generelt i hukommelsen i længere tid. Du kan drage fordel af CLR-profilen til at forstå fordelingsmønstrene for din applikation.
Du bør undgå at ringe til GC.Collect () metode, da den forårsager en fuld samling af alle generationer (Generation 0, 1 og 2). Når du ringer til GC.Collect () metode, kører runtime alle live objekter i din applikation. Dette tager lang tid og er derfor en meget dyr operation. Som et resultat er det ikke en god praksis at ringe til GC.Collect () metode.
Hvis du skal ringe til GC.Collect () metode, skal du ringe GC.WaitForPendingFinalizers () efter opkaldet til GC.Collect () for at sikre, at den aktuelle udførende tråd venter, indtil finaliseringen af alle objekterne er blevet udført.
Dernæst skal du ringe til GC.Collect () metode igen for at sikre, at du samler de døde genstande, der er tilbage. Disse døde objekter, der muligvis er oprettet på grund af kaldet til finaliseringsmetoden på objekterne. Følgende kodestykke viser, hvordan disse metoder bruges.
System.GC.Collect ();
System.GC.WaitForPendingFinalizers ();
System.GC.Collect ();
Du skal sikre dig, at du minimerer skjulte tildelinger og skriver din kode på en sådan måde, at chancerne for reklame for kortvarige objekter til højere generationer elimineres. Du bør ikke henvise til kortvarige objekter fra de langtidsholdte for at undgå promovering af de kortvarige objekter til højere generationer.
Du bør også undgå at skrive færdiggørere til dine klasser. Hvis du har implementeret en finalizer i din klasse, bliver objekter fra sådanne klasser objekter med lang levetid, da kørselstiden skal promovere de færdiggørelige objekter til ældre generationer. Du skal indstille objekter til null, før du foretager et langvarigt opkald, hvis applikationen ikke har brug for sådanne objekter. Hvis du ikke længere har brug for et statisk objekt eller andre objekter i din applikation, skal du indstille det til null, inden du foretager et langvarigt opkald. Du bør ikke indstille lokale variabler til null, da det ikke er nødvendigt; runtime kan bestemme, hvilket lokalt objekt der ikke henvises til i din kode eller ikke bruges yderligere, så du behøver ikke indstille nogen lokal variabel til nul eksplicit.
