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 influiscono sull'esecuzione di 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 tiene traccia e recupera gli oggetti allocati in 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 Collect metodo .

Garbage Collection è costituito dai passaggi seguenti:

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 eseguendo l'override del Object.Finalize metodo. Tuttavia, i tipi scritti in C# o C++ implementano distruttori, che i compilatori trasformano in un override 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 è necessario per chiamare i finalizzatori in tutte le situazioni; Ad esempio, il SuppressFinalize metodo impedisce esplicitamente di chiamare il finalizzatore di un oggetto. Inoltre, il Garbage Collector non è necessario usare un thread specifico per finalizzare gli oggetti o garantire l'ordine in cui i finalizzatori vengono chiamati per gli oggetti che fanno riferimento tra loro, ma sono altrimenti disponibili per 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 i consumer di classi chiamano il metodo per pulire 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 in Common Language Runtime supporta l'invecchiamento degli oggetti usando 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 della generazione più recente si trovano 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 garbage collection a un set specifico di generazioni anziché richiedere al Garbage Collector di valutare tutte le generazioni. Gli overload del Collect metodo che includono un generation parametro consentono di specificare la generazione meno recente da sottoporre a Garbage Collection.

Non consentire l'operazione di Garbage Collection

Il Garbage Collector supporta una modalità di latenza dell'area GC che può essere usata durante l'esecuzione di percorsi critici in cui garbage collection può influire negativamente sulle prestazioni di un'app. Per la modalità di latenza dell'area GC non è necessario specificare 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 TryStartNoGCRegion metodo e chiamare il EndNoGCRegion metodo solo se il runtime non è attualmente in modalità di latenza dell'area 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.