Classe System.GC

Questo articolo fornisce osservazioni supplementari alla documentazione di riferimento per questa API.

La GC classe controlla il Garbage Collector. Il Garbage Collector è un componente Common Language Runtime che controlla l'allocazione e il rilascio della memoria gestita. I metodi in questa classe determinano quando viene eseguita la Garbage Collection su un oggetto e quando vengono rilasciate le risorse allocate da un oggetto. Le proprietà di questa classe forniscono informazioni sulla quantità totale di memoria disponibile nel sistema e sulla categoria di età, o generazione, della memoria allocata a un oggetto .

Il garbage collector traccia e recupera gli oggetti allocati nella memoria gestita. Periodicamente, Il Garbage Collector esegue l'operazione di Garbage Collection per recuperare la memoria allocata agli oggetti per i quali non sono presenti riferimenti validi. La Garbage Collection viene eseguita automaticamente quando una richiesta di memoria non può essere soddisfatta usando la memoria disponibile. In alternativa, un'applicazione può forzare l'operazione di garbage collection usando il metodo Collect.

La raccolta dei rifiuti si compone dei seguenti passaggi:

1. Il Garbage Collector cerca gli oggetti gestiti a cui viene fatto riferimento nel codice gestito.
2. Il Garbage Collector tenta di finalizzare gli oggetti a cui non viene fatto riferimento.
3. Il Garbage Collector libera gli oggetti a cui non viene fatto riferimento e ne recupera la memoria.

Risorse non gestite

Durante una raccolta, Il Garbage Collector non libera un oggetto se trova uno o più riferimenti all'oggetto nel codice gestito. Tuttavia, Il Garbage Collector non riconosce i riferimenti a un oggetto da codice non gestito e potrebbe liberare oggetti usati esclusivamente nel codice non gestito, a meno che non sia esplicitamente impedito di farlo. Il KeepAlive metodo fornisce un meccanismo che impedisce al Garbage Collector di raccogliere oggetti ancora in uso nel codice non gestito.

Oltre alle allocazioni di memoria gestita, le implementazioni di Garbage Collector non mantengono informazioni sulle risorse contenute in un oggetto, ad esempio handle di file o connessioni di database. Quando un tipo usa risorse non gestite che devono essere rilasciate prima che vengano recuperate istanze del tipo, il tipo può implementare un finalizzatore.

Nella maggior parte dei casi, i finalizzatori vengono implementati sovrascrivendo il metodo Object.Finalize. Tuttavia, i tipi scritti in C# o C++ implementano distruttori, che i compilatori trasformano in una sovrascrittura di Object.Finalize. Nella maggior parte dei casi, se un oggetto dispone di un finalizzatore, il Garbage Collector lo chiama prima di liberare l'oggetto. Tuttavia, il garbage collector non è tenuto a chiamare i finalizzatori in tutte le situazioni; ad esempio, il metodo SuppressFinalize impedisce esplicitamente di chiamare il finalizzatore di un oggetto. Inoltre, il garbage collector non deve utilizzare un thread specifico per finalizzare gli oggetti, né garantire l'ordine in cui i finalizzatori vengono chiamati per gli oggetti che si riferiscono a vicenda, ma che sono altrimenti disponibili per la garbage collection.

Negli scenari in cui le risorse devono essere rilasciate in un momento specifico, le classi possono implementare l'interfaccia IDisposable , che contiene il IDisposable.Dispose metodo che esegue attività di gestione delle risorse e pulizia. Le classi che implementano Dispose devono specificare, come parte del contratto di classe, se e quando gli utenti della classe chiamano il metodo per liberare l'oggetto. Per impostazione predefinita, il Garbage Collector non chiama il Dispose metodo. Tuttavia, le implementazioni del Dispose metodo possono chiamare metodi nella GC classe per personalizzare il comportamento di finalizzazione del Garbage Collector.

Per altre informazioni sulla finalizzazione degli oggetti e sul modello dispose, vedere Pulizia delle risorse non gestite.

Invecchiamento degli oggetti e generazioni

Il garbage collector nel Common Language Runtime supporta l'invecchiamento degli oggetti usando le generazioni. Una generazione è un'unità di misura dell'età relativa degli oggetti in memoria. Il numero di generazione, o età, di un oggetto indica la generazione a cui appartiene un oggetto. Gli oggetti creati più di recente fanno parte delle generazioni più recenti e hanno numeri di generazione inferiori rispetto agli oggetti creati in precedenza nel ciclo di vita dell'applicazione. Gli oggetti nella generazione più recente sono nella generazione 0. Questa implementazione di Garbage Collector supporta tre generazioni di oggetti, generazioni 0, 1 e 2. È possibile recuperare il valore della MaxGeneration proprietà per determinare il numero di generazione massimo supportato dal sistema.

L'invecchiamento degli oggetti consente alle applicazioni di destinare la raccolta dei rifiuti a un insieme specifico di generazioni anziché richiedere al garbage collector di valutare tutte le generazioni. Gli overload del metodo Collect che includono un parametro generation consentono di specificare la generazione più vecchia da sottoporre a raccolta di rifiuti.

Non consentire l'operazione di Garbage Collection

Il garbage collector supporta una modalità di latenza senza GC che può essere usata durante l'esecuzione di percorsi critici in cui la garbage collection può influenzare negativamente le prestazioni di un'app. La modalità di latenza senza GC richiede che tu specifichi una quantità di memoria che può essere allocata senza interferenze da parte del garbage collector. Se il runtime può allocare tale memoria, il runtime non eseguirà un'operazione di Garbage Collection mentre il codice nel percorso critico è in esecuzione.

È possibile definire l'inizio del percorso critico dell'area non GC chiamando uno degli overload di TryStartNoGCRegion. Specificare la fine del percorso critico chiamando il EndNoGCRegion metodo .

Non è possibile annidare le chiamate al metodo TryStartNoGCRegion, e dovresti chiamare il metodo EndNoGCRegion solo se il runtime è attualmente in modalità di latenza della regione senza GC. In altre parole, non è consigliabile chiamare TryStartNoGCRegion più volte (dopo la prima chiamata al metodo, le chiamate successive non avranno esito positivo) e non ci si dovrebbe aspettare che le chiamate EndNoGCRegion abbiano esito positivo solo perché la prima chiamata a TryStartNoGCRegion ha avuto esito positivo.