Quindi stavo leggendo una domanda su come forzare l'esecuzione del Garbage Collector C # in cui quasi ogni singola risposta è la stessa: puoi farlo, ma non dovresti - tranne alcuni casi molto rari . Sfortunatamente, nessuno lì elabora cosa siano questi casi.

Puoi dirmi in quale tipo di scenario è effettivamente una buona o ragionevole idea forzare la raccolta dei rifiuti?

Non sto chiedendo casi specifici per C #, ma piuttosto tutti i linguaggi di programmazione che hanno un garbage collector. So che non puoi forzare GC su tutte le lingue, come Java, ma supponiamo che tu possa farlo.

Non puoi davvero fare affermazioni generali sul modo appropriato di utilizzare tutte le implementazioni di GC. Variano selvaggiamente. Quindi parlerò con quello a cui ti riferivi originariamente.

È necessario conoscere il comportamento del GC piuttosto intimamente per farlo con qualsiasi logica o ragione.

L'unico consiglio sulla raccolta che posso dare è: non farlo mai.

Se conosci veramente i dettagli intricati del GC, non avrai bisogno dei miei consigli, quindi non importa. Se non lo sai già con la certezza del 100%, sarà di aiuto, e dovrai cercare online e trovare una risposta come questa: non dovresti chiamare GC.Collect , o in alternativa: dovresti andare a conoscere i dettagli di come funziona il GC dentro e fuori, e solo allora conoscerai la risposta .

C'è un posto sicuro in cui ha senso usare GC.Collect :

GC.Collect è un'API disponibile che puoi utilizzare per la profilazione dei tempi delle cose. Potresti profilare un algoritmo, raccogliere e profilare un altro algoritmo subito dopo sapendo che GC del primo algo non si stava verificando durante il secondo alterando i risultati.

Questo tipo di profilazione è la sola volta che suggerirei di raccogliere manualmente a chiunque.

Esempio contrastato comunque

Un possibile caso d'uso è se carichi cose molto grandi, finiranno nell'Heap degli oggetti grandi che andrà direttamente alla Gen 2, anche se ancora Gen 2 è per oggetti di lunga durata perché raccoglie meno frequentemente. Se sai che stai caricando oggetti di breve durata in Gen 2 per qualsiasi motivo, potresti eliminarli più rapidamente per mantenere la tua Gen 2 più piccola e le sue raccolte più veloci.

Questo è il miglior esempio che potrei trovare, e non è buono - la pressione LOH che stai costruendo qui causerebbe raccolte più frequenti, e le raccolte sono così frequenti come è - è probabile che eliminerebbe il LOH proprio come veloce mentre lo facevi esplodere con oggetti temporanei. Ho semplicemente non mi fido di me presumere una frequenza di raccolta migliore rispetto al GC in sé - messo a punto da persone lontane gran lunga più intelligenti di me

Quindi parliamo di alcune delle semantiche e dei meccanismi nel GC GC ... o ...

Tutto quello che penso di sapere sul GC GC

Per favore, chiunque trovi errori qui - correggimi. Gran parte del GC è ben noto per essere magia nera e mentre cercavo di tralasciare dettagli di cui non ero sicuro, probabilmente ho ancora sbagliato qualcosa.

Di seguito mancano di proposito numerosi dettagli di cui non sono sicuro, oltre a un corpus di informazioni molto più ampio di cui sono semplicemente ignaro. Utilizzare queste informazioni a proprio rischio.

Concetti GC

.NET GC si verifica in momenti incoerenti, motivo per cui si chiama "non deterministico", ciò significa che non si può fare affidamento sul fatto che si verifichi in momenti specifici. È anche un garbage collector generazionale, il che significa che suddivide i tuoi oggetti in quanti passaggi GC hanno attraversato.

Gli oggetti nell'heap di Gen 0 hanno attraversato 0 raccolte, queste sono state appena realizzate, quindi di recente non si è verificata alcuna raccolta dalla loro istanza. Gli oggetti nel tuo heap di Gen 1 hanno vissuto un passaggio di raccolta e allo stesso modo gli oggetti nel tuo heap di Gen 2 hanno vissuto 2 passaggi di raccolta.

Ora vale la pena notare il motivo per cui qualifica queste specifiche generazioni e partizioni di conseguenza. .NET GC riconosce solo queste tre generazioni, perché i passaggi di raccolta che superano questi tre cumuli sono leggermente diversi. Alcuni oggetti potrebbero sopravvivere a passaggi di raccolta migliaia di volte. Il GC lascia semplicemente questi dall'altro lato della partizione heap di Gen 2, non ha senso partizionarli ulteriormente perché sono in realtà Gen 44; il passaggio di raccolta su di essi è uguale a tutto nell'heap di seconda generazione.

Ci sono scopi semantici per queste generazioni specifiche, così come meccanismi implementati che le onorano, e arriverò a quelli in un momento.

Cosa c'è in una collezione

Il concetto di base di un passaggio di raccolta GC è che controlla ogni oggetto in uno spazio heap per vedere se ci sono ancora riferimenti attivi (radici GC) a questi oggetti. Se viene trovata una radice GC per un oggetto, significa che attualmente l'esecuzione del codice può ancora raggiungere e utilizzare quell'oggetto, quindi non può essere eliminato. Tuttavia, se una radice GC non viene trovata per un oggetto, significa che il processo in esecuzione non ha più bisogno dell'oggetto, quindi può rimuoverlo per liberare memoria per i nuovi oggetti.

Ora dopo aver finito di ripulire un gruppo di oggetti e di lasciarne alcuni da soli, ci sarà uno sfortunato effetto collaterale: spazi vuoti tra gli oggetti vivi dove sono stati rimossi quelli morti. Questa frammentazione della memoria, se lasciata sola, sprecherebbe semplicemente memoria, quindi le raccolte in genere fanno ciò che viene chiamato "compattazione" dove prendono tutti gli oggetti vivi rimasti e li stringono insieme nell'heap in modo che la memoria libera sia contigua su un lato dell'heap per Gen 0.

Ora, data l'idea di 3 cumuli di memoria, tutti partizionati dal numero di passaggi di raccolta che hanno vissuto, parliamo del perché esistono queste partizioni.

Collezione Gen 0

Essendo la gen 0 gli oggetti più recenti in assoluto, tende ad essere molto piccola, quindi puoi tranquillamente raccoglierla molto frequentemente . La frequenza assicura che l'heap rimanga piccolo e le raccolte siano molto veloci perché si stanno accumulando su un heap così piccolo. Questo si basa più o meno su un'euristica che afferma: una grande maggioranza di oggetti temporanei che crei sono molto temporanei, così temporanei che non saranno più utilizzati o referenziati quasi immediatamente dopo l'uso, e quindi possono essere raccolti.

Collezione Gen 1

Essendo la 1a generazione oggetti che non rientravano in questa categoria di oggetti molto temporanea, potrebbero avere una vita piuttosto breve, poiché ancora - una vasta porzione degli oggetti creati non viene utilizzata a lungo. Pertanto anche la Gen 1 raccoglie piuttosto frequentemente, mantenendo di nuovo l'heap piccolo e le raccolte sono veloci. Tuttavia, il presupposto è minore dei suoi oggetti sono temporanei rispetto alla Gen 0, quindi raccoglie meno frequentemente della Gen 0

Dirò che sinceramente non conosco i meccanismi tecnici che differiscono tra i passi di raccolta della Gen 0 e quelli della Gen 1, se ce ne sono altri diversi dalla frequenza che raccolgono.

Collezione Gen 2

Gen 2 ora deve essere la madre di tutti i cumuli giusto? Bene, sì, è più o meno giusto. È dove vivono tutti i tuoi oggetti permanenti - l'oggetto in cui Main()vivi, per esempio, e tutto ciò che fa Main()riferimento perché saranno radicati fino al tuo Main()ritorno alla fine del tuo processo.

Dato che Gen 2 è un secchio praticamente per tutto ciò che le altre generazioni non sono riuscite a collezionare, i suoi oggetti sono in gran parte permanenti o almeno longevi. Quindi riconoscere molto poco di ciò che è nella Gen 2 sarà effettivamente qualcosa che può essere raccolto, non ha bisogno di essere raccolto frequentemente. Ciò consente alla raccolta di essere anche più lenta, poiché viene eseguita molto meno frequentemente. Quindi questo è fondamentalmente il punto in cui hanno affrontato tutti i comportamenti extra per scenari strani, perché hanno il tempo di eseguirli.

Mucchio di oggetti di grandi dimensioni

Un esempio dei comportamenti extra di Gen 2 è che esegue anche la raccolta sull'heap di oggetti di grandi dimensioni. Fino ad ora ho parlato interamente di Small Object Heap, ma il runtime .NET alloca cose di determinate dimensioni a un heap separato a causa di ciò che ho definito compattazione sopra. La compattazione richiede lo spostamento di oggetti quando le raccolte finiscono nell'heap di piccoli oggetti. Se c'è un oggetto 10mb vivente nella prima generazione, ci vorrà molto più tempo per completare la compattazione dopo la raccolta, rallentando così la raccolta della prima generazione. In modo che l'oggetto 10mb sia allocato all'heap di oggetti di grandi dimensioni e raccolto durante la Gen 2 che viene eseguito di rado.

finalizzazione

Un altro esempio sono gli oggetti con finalizzatori. È stato inserito un finalizzatore su un oggetto che fa riferimento a risorse oltre l'ambito di .NETs GC (risorse non gestite). Il finalizzatore è l'unico modo in cui il GC può richiedere la raccolta di una risorsa non gestita: implementate il finalizzatore per eseguire la raccolta / rimozione / rilascio manuale della risorsa non gestita per garantire che non fuoriesca dal processo. Quando il GC esegue l'esecuzione del finalizzatore degli oggetti, l'implementazione eliminerà la risorsa non gestita, rendendo il GC in grado di rimuovere l'oggetto senza rischiare una perdita di risorse.

Il meccanismo con cui i finalizzatori eseguono questa operazione è il riferimento diretto in una coda di finalizzazione. Quando il runtime alloca un oggetto con un finalizzatore, aggiunge un puntatore a tale oggetto nella coda di finalizzazione e blocca l'oggetto in posizione (chiamato pinning) in modo che la compattazione non lo sposti, interrompendo il riferimento alla coda di finalizzazione. Man mano che si verificano i passaggi di raccolta, alla fine il tuo oggetto non avrà più una radice GC, ma la finalizzazione deve essere eseguita prima di poter essere raccolta. Quindi, quando l'oggetto è morto, la raccolta sposta il suo riferimento dalla coda di finalizzazione e inserisce un riferimento su quella che è nota come coda "FReachable". Quindi la raccolta continua. In un altro momento "non deterministico" nel futuro, un thread separato noto come thread Finalizer passerà attraverso la coda FReachable, eseguendo i finalizzatori per ciascuno degli oggetti a cui viene fatto riferimento. Al termine, la coda FReachable è vuota e si è capovolta un po 'nell'intestazione di ogni oggetto che dice che non necessita di finalizzazione (Questo bit può anche essere capovolto manualmente conGC.SuppressFinalizeche è comune nei Dispose()metodi), sospetto anche che abbia sbloccato gli oggetti, ma non citarmi su questo. La prossima collezione che si presenta su qualsiasi heap in cui si trova questo oggetto, finalmente lo raccoglierà. Le raccolte Gen 0 non prestano nemmeno attenzione agli oggetti con quel bit necessario per la finalizzazione, li promuove automaticamente, senza nemmeno controllare la loro radice. Un oggetto non rootato che necessita di finalizzazione in Gen 1, verrà lanciato in FReachablecoda, ma la collezione non fa altro, quindi vive in Gen 2. In questo modo, tutti gli oggetti che hanno un finalizzatore e non GC.SuppressFinalizesarà raccolto in Gen 2.

Purtroppo, nessuno là elabora su cosa siano tali casi.

Darò alcuni esempi. Tutto sommato è raro che forzare un GC sia una buona idea, ma può valerne la pena. Questa risposta è dalla mia esperienza con la letteratura .NET e GC. Dovrebbe generalizzare bene su altre piattaforme (almeno quelle che hanno un GC significativo).

• Benchmark di vario genere. Si desidera uno stato heap gestito noto quando inizia un benchmark in modo che il GC non si attivi casualmente durante i benchmark. Quando ripeti un benchmark vuoi lo stesso numero e la stessa quantità di lavoro GC in ogni ripetizione.
• Rilascio improvviso di risorse. Ad esempio chiudendo una finestra della GUI significativa o aggiornando una cache (e rilasciando così il vecchio contenuto della cache potenzialmente grande). Il GC non è in grado di rilevarlo perché tutto ciò che si sta facendo è impostare un riferimento su null. Il fatto che questo orfano un intero oggetto grafico non è facilmente rilevabile.
• Rilascio di risorse non gestite che sono trapelate . Questo non dovrebbe mai accadere, ovviamente, ma ho visto casi in cui una libreria di terze parti trapelava roba (come oggetti COM). Lo sviluppatore è stato costretto a volte a indurre una raccolta.
• Applicazioni interattive come i giochi . Durante i giochi i budget sono molto rigidi per frame (60Hz => 16ms per frame). Per evitare problemi, è necessaria una strategia per gestire i GC. Una di queste strategie è quella di ritardare il più possibile i GC G2 e forzarli in un momento opportuno come una schermata di caricamento o una scena tagliata. Il GC non può sapere quando è il momento migliore.
• Controllo della latenza in generale. Alcune applicazioni Web disabilitano i GC ed eseguono periodicamente una raccolta G2 mentre vengono disattivate dalla rotazione del bilanciamento del carico. In questo modo la latenza G2 non viene mai visualizzata all'utente.

Se il tuo obiettivo è il throughput, più raro è il GC, meglio è. In quei casi forzare una raccolta non può avere un impatto positivo (ad eccezione di problemi piuttosto artificiosi come l'aumento dell'utilizzo della cache della CPU rimuovendo gli oggetti morti intervallati da quelli attivi). La raccolta in lotti è più efficiente per tutti i collezionisti che conosco. Per l'app di produzione con consumo di memoria in stato stazionario indurre un GC non aiuta.

Gli esempi sopra riportati indicano la coerenza e la limitazione dell'utilizzo della memoria. In questi casi i GC indotti possono avere senso.

Sembra esserci un'idea diffusa che il CG sia un'entità divina che induce una raccolta ogni volta che è davvero ottimale farlo. Nessun GC che conosco è così sofisticato e in effetti è molto difficile essere ottimali per il GC. Il GC sa meno dello sviluppatore. Le sue euristiche si basano su contatori di memoria e cose come la velocità di raccolta e così via. L'euristica di solito è buona ma non cattura improvvisi cambiamenti nel comportamento dell'applicazione come il rilascio di grandi quantità di memoria gestita. È inoltre cieco alle risorse non gestite e ai requisiti di latenza.

Si noti che i costi GC variano in base alla dimensione dell'heap e al numero di riferimenti sull'heap. Su un piccolo mucchio il costo può essere molto piccolo. Ho riscontrato tassi di raccolta G2 con .NET 4.5 di 1-2 GB / sec su un'app di produzione con heap da 1 GB.

Come principio generale, un garbage collector raccoglierà quando si imbatterà in "pressione della memoria", ed è considerata una buona idea non farlo raccogliere in altri momenti perché potresti causare problemi di prestazioni o anche pause evidenti nell'esecuzione del tuo programma. E infatti, il primo punto dipende dal secondo: per un garbage collector generazionale, almeno, funziona in modo più efficiente quanto più alto è il rapporto tra immondizia e oggetti buoni, quindi al fine di ridurre al minimo il tempo impiegato a mettere in pausa il programma , deve procrastinare e lasciare che la spazzatura si accumuli il più possibile.

Il momento appropriato per invocare manualmente il Garbage Collector, quindi, è quando hai finito di fare qualcosa che 1) è probabile che abbia creato molta spazzatura, e 2) ci si aspetta che l'utente impieghi un po 'di tempo e lasci il sistema non risponde Comunque. Un esempio classico è alla fine del caricamento di qualcosa di grande (un documento, un modello, un nuovo livello, ecc.)

Una cosa che nessuno ha menzionato è che, mentre il GC di Windows è incredibilmente buono, il GC su Xbox è spazzatura (gioco di parole intenzionale) .

Quindi, quando si codifica un gioco XNA destinato a essere eseguito su XBox, è assolutamente fondamentale cronometrare la raccolta dei rifiuti in momenti opportuni, oppure si avranno orribili singhiozzi intermittenti FPS. Inoltre, su XBox è comune usare structs way, molto più spesso di quanto si farebbe normalmente, per ridurre al minimo il numero di oggetti che devono essere raccolti.

La garbage collection è innanzitutto uno strumento di gestione della memoria. Pertanto, i raccoglitori di rifiuti si raccoglieranno quando c'è pressione della memoria.

I moderni bidoni della spazzatura sono molto buoni e stanno migliorando, quindi è improbabile che tu possa migliorarli raccogliendoli manualmente. Anche se puoi migliorare le cose oggi, potrebbe darsi che un futuro miglioramento del tuo garbage collector scelto renderà la tua ottimizzazione inefficace o addirittura controproducente.

Tuttavia , i garbage collector in genere non tentano di ottimizzare l'uso di risorse diverse dalla memoria. In ambienti garbage collection, le risorse non di memoria più preziose hanno un closemetodo o simile, ma ci sono alcune occasioni in cui questo non è il caso per qualche motivo, come la compatibilità con un'API esistente.

In questi casi può avere senso invocare manualmente la garbage collection quando si sa che viene utilizzata una preziosa risorsa non di memoria.

RMI

Un esempio concreto di ciò è la chiamata a metodo remoto di Java. RMI è una libreria di chiamate di procedura remota. In genere si dispone di un server, che rende vari oggetti disponibili per l'uso da parte dei client. Se un server sa che un oggetto non viene utilizzato da alcun client, quell'oggetto è idoneo per la garbage collection.

Tuttavia, l'unico modo in cui il server lo sa è se il client lo dice e il client dice al server che non ha più bisogno di un oggetto una volta che il client ha raccolto la spazzatura qualunque cosa lo stia usando.

Ciò presenta un problema, poiché il client potrebbe disporre di molta memoria libera, pertanto potrebbe non essere in grado di eseguire la garbage collection molto frequentemente. Nel frattempo, il server potrebbe avere molti oggetti inutilizzati in memoria, che non può raccogliere perché non sa che il client non li sta usando.

La soluzione in RMI è che il client esegua periodicamente la garbage collection, anche quando ha molta memoria libera, per garantire che gli oggetti vengano raccolti prontamente sul server.

La migliore pratica è di non forzare una raccolta dei rifiuti nella maggior parte dei casi. (Ogni sistema su cui ho lavorato aveva forzato la raccolta dei rifiuti, aveva sottolineato problemi che se risolti avrebbero rimosso la necessità di forzare la raccolta dei rifiuti e accelerato notevolmente il sistema.)

Ci sono alcuni casi in cui si sa di più su l'utilizzo della memoria, allora il garbage collector fa. È improbabile che ciò sia vero in un'applicazione multiutente o in un servizio che risponde a più di una richiesta alla volta.

Tuttavia, in alcune elaborazioni di tipo batch , conosci più del GC. Ad esempio, considerare un'applicazione che.

• Viene fornito un elenco di nomi di file sulla riga di comando
• Elabora un singolo file, quindi scrive il risultato in un file di risultati.
• Durante l'elaborazione del file, crea molti oggetti interconnessi che non possono essere raccolti fino al completamento dell'elaborazione del file (ad esempio un albero di analisi)
• Non mantiene lo stato di corrispondenza tra i file che ha elaborato .

Si può essere in grado di fare un caso (dopo un'attenta) di test che si dovrebbe forzare una garbage collection completa dopo aver processo di ciascun file.

Un altro caso è un servizio che si sveglia ogni pochi minuti per elaborare alcuni elementi e non mantiene alcuno stato mentre è addormentato . Quindi può essere utile forzare una raccolta completa prima di andare a dormire .

L'unica volta che prenderei in considerazione la possibilità di forzare una raccolta è quando so che un sacco di oggetti sono stati creati di recente e pochissimi oggetti sono attualmente referenziati.

Preferirei avere un'API di Garbage Collection quando potrei dare suggerimenti su questo tipo di cose senza dover forzare un GC da solo.

Vedi anche " Rico Mariani's Performance Tidbits "

Esistono diversi casi in cui potresti voler chiamare tu stesso gc ().

• [ Alcune persone dicono che questo non va bene perché può promuovere oggetti nello spazio di vecchia generazione, che sono d'accordo non è una buona cosa. Tuttavia, NON è sempre vero che ci saranno sempre oggetti che possono essere promossi. È certamente possibile che dopo questa gc()chiamata rimangano pochissimi oggetti e tanto meno vengano spostati nello spazio di generazione precedente ] Quando si crea una grande raccolta di oggetti e si utilizza molta memoria. Volete semplicemente liberare quanto più spazio possibile di preparazione. È solo buonsenso. Chiamando gc()manualmente, non ci sarà controllo grafico di riferimento ridondante su parte di quella grande raccolta di oggetti che si sta caricando in memoria. In breve, se si esegue gc()prima di caricare molto in memoria, ilgc() indotto durante il caricamento avviene meno di almeno una volta quando il caricamento inizia creando la pressione della memoria.
• Dopo aver caricato una grande raccolta digrandeoggetti e difficilmente caricherai più oggetti in memoria. In breve, si passa dalla creazione della fase all'utilizzo della fase. Chiamando in gc()base all'implementazione, la memoria utilizzata verrà compattata, migliorando notevolmente la localizzazione della cache. Ciò comporterà un notevole miglioramento delle prestazioni che non otterrai dalla profilazione .
• Simile al primo, ma dal punto di vista che se lo fai gc()e l'implementazione della gestione della memoria supporta, creerai una continuità molto migliore per la tua memoria fisica. Questo rende di nuovo la nuova grande raccolta di oggetti più continua e compatta che a sua volta migliora le prestazioni

Un esempio reale:

Avevo un'applicazione Web che utilizzava un insieme molto ampio di dati che raramente cambiava e ai quali era necessario accedere molto rapidamente (abbastanza veloce per la risposta per battitura tramite AJAX).

La cosa abbastanza ovvia da fare qui è caricare il grafico rilevante in memoria e accedervi da lì anziché dal database, aggiornando il grafico quando il DB cambia.

Ma essendo molto grande, un carico ingenuo avrebbe assorbito almeno 6 GB di memoria con i dati a causa della crescita futura. (Non ho cifre esatte, una volta era chiaro che la mia macchina da 2 GB stava cercando di far fronte ad almeno 6 GB, avevo tutte le misure di cui avevo bisogno per sapere che non avrebbe funzionato).

Fortunatamente, c'era un gran numero di oggetti immutabili con ghiaccioli in questo insieme di dati che erano uguali tra loro; una volta scoperto che un determinato batch era uguale a un altro batch, ho potuto alias un riferimento all'altro consentendo la raccolta di molti dati e quindi adattando tutto in meno di mezzo concerto.

Tutto bene, ma per questo ancora sfornano oltre 6 GB di oggetti nello spazio di circa mezzo minuto per arrivare a questo stato. Lasciato a se stesso, GC non ce la fece; il picco di attività rispetto al solito schema dell'applicazione (molto meno pesante per deallocazioni al secondo) era troppo acuto.

Quindi chiamare periodicamente GC.Collect()durante questo processo di compilazione significava che tutto funzionava senza problemi. Naturalmente, non ho chiamato manualmente GC.Collect()il resto del tempo in cui l'applicazione viene eseguita.

Questo caso del mondo reale è un buon esempio delle linee guida su quando dovremmo usare GC.Collect():

1. Utilizzare con un caso relativamente raro di molti oggetti resi disponibili per la raccolta (sono stati resi disponibili megabyte di valore, e questa creazione di grafici è stata un caso molto raro per la durata dell'applicazione (circa un minuto a settimana).
2. Fallo quando una perdita di prestazioni è relativamente tollerabile; questo è accaduto solo all'avvio dell'applicazione. (Un altro buon esempio di questa regola è tra i livelli durante una partita o altri punti in una partita in cui i giocatori non saranno turbati da una pausa).
3. Profilo per essere sicuro che ci sia davvero un miglioramento. (Abbastanza facile; "Funziona" batte quasi sempre "non funziona").

Il più delle volte quando ho pensato che avrei potuto avere un caso in cui GC.Collect()valesse la pena chiamare, perché i punti 1 e 2 applicati, il punto 3 suggeriva che le cose peggioravano o almeno non rendevano le cose migliori (e con un miglioramento scarso o nullo avrei incline a non chiamare più di chiamare poiché l'approccio ha maggiori probabilità di dimostrarsi migliore nel corso della vita di un'applicazione).

Ho un uso per lo smaltimento dei rifiuti che è un po 'poco ortodosso.

C'è questa pratica sbagliata che è purtroppo molto diffusa nel mondo C #, di implementare lo smaltimento degli oggetti usando il brutto, goffo, inelegante ed incline linguaggio di errori noto come IDisposable-disposing . MSDN lo descrive a lungo e molte persone lo giurano, lo seguono religiosamente, passano ore e ore a discutere esattamente come dovrebbe essere fatto, ecc.

(Si noti che ciò che io chiamo brutto qui non è il modello di smaltimento dell'oggetto stesso; quello che io chiamo brutto è il particolare IDisposable.Dispose( bool disposing )linguaggio.)

Questo idioma è stato inventato perché è presumibilmente impossibile garantire che il distruttore dei tuoi oggetti sia sempre invocato dal garbage collector per ripulire le risorse, quindi le persone eseguono la pulizia delle risorse all'interno IDisposable.Dispose()e, nel caso in cui dimenticano, ci provano ancora all'interno del distruttore. Sai, per ogni evenienza.

Ma allora IDisposable.Dispose()potresti avere sia oggetti gestiti che non gestiti da ripulire, ma quelli gestiti non possono essere ripuliti quando IDisposable.Dispose()vengono invocati dall'interno del distruttore, perché sono già stati curati dal garbage collector in quel momento, quindi è questa necessità di un Dispose()metodo separato che accetta un bool disposingflag per sapere se sia gli oggetti gestiti che quelli non gestiti devono essere ripuliti o solo quelli non gestiti.

Mi scusi, ma questo è semplicemente folle.

Seguo l'assioma di Einstein, secondo il quale le cose dovrebbero essere il più semplici possibile, ma non più semplici. Chiaramente, non possiamo omettere la pulizia delle risorse, quindi la soluzione più semplice possibile deve includere almeno quella. La prossima soluzione più semplice prevede di disporre sempre di tutto nel momento esatto in cui dovrebbe essere disposto, senza complicare le cose facendo affidamento sul distruttore come alternativa alternativa.

Ora, a rigor di termini, è ovviamente impossibile garantire che nessun programmatore commetterà mai l'errore di dimenticare di invocare IDisposable.Dispose(), ma ciò che possiamo fare è usare il distruttore per cogliere questo errore. È molto semplice, davvero: tutto ciò che il distruttore deve fare è generare una voce di registro se rileva che il disposedflag dell'oggetto usa e getta non è mai stato impostato true. Pertanto, l'uso del distruttore non è parte integrante della nostra strategia di smaltimento, ma è il nostro meccanismo di garanzia della qualità. E poiché si tratta solo di un test in modalità debug, possiamo posizionare l'intero distruttore all'interno di un #if DEBUGblocco, in modo da non incorrere in alcuna penalità di distruzione in un ambiente di produzione. (Il IDisposable.Dispose( bool disposing )linguaggio lo prescriveGC.SuppressFinalize() dovrebbe essere invocato proprio per ridurre il sovraccarico di finalizzazione, ma con il mio meccanismo è possibile evitare completamente tale sovraccarico nell'ambiente di produzione.)

Ciò a cui si riduce è l'eterno errore duro rispetto all'argomento errore lieve : l' IDisposable.Dispose( bool disposing )idioma è un approccio di errore morbido e rappresenta un tentativo di consentire al programmatore di dimenticare di invocare Dispose()senza che il sistema fallisca, se possibile. L'approccio dell'errore grave dice che il programmatore deve sempre assicurarsi che Dispose()verrà invocato. La penalità solitamente prescritta dall'approccio dell'errore grave nella maggior parte dei casi è l'asserzione fallita, ma per questo caso particolare facciamo un'eccezione e riduciamo la penalità con una semplice emissione di una voce del registro errori.

Quindi, affinché questo meccanismo funzioni, la versione DEBUG della nostra applicazione deve eseguire uno smaltimento completo dei rifiuti prima di uscire, in modo da garantire che tutti i distruttori vengano invocati e quindi catturare tutti gli IDisposableoggetti che abbiamo dimenticato di smaltire.

Puoi dirmi in quale tipo di scenario è effettivamente una buona o ragionevole idea forzare la raccolta dei rifiuti? Non sto chiedendo casi specifici per C #, ma piuttosto tutti i linguaggi di programmazione che hanno un garbage collector. So che non puoi forzare GC su tutte le lingue, come Java, ma supponiamo che tu possa farlo.

Parlando in modo molto teorico e trascurando problemi come alcune implementazioni di GC che rallentano le cose durante i loro cicli di raccolta, lo scenario più grande che mi viene in mente di forzare la raccolta dei rifiuti è un software mission-critical in cui le perdite logiche sono preferibili a penzolare gli arresti anomali dei puntatori, ad esempio perché l'arresto anomalo in momenti inaspettati potrebbe costare vite umane o qualcosa del genere.

Se guardi alcuni dei più deboli giochi indie scritti usando linguaggi GC come i giochi Flash, perdono come un matto ma non si schiantano. Potrebbero essere necessari 20 volte la memoria in 20 minuti per giocare perché una parte della base di codice del gioco ha dimenticato di impostare un riferimento su null o rimuoverlo da un elenco e le frequenze dei fotogrammi potrebbero iniziare a risentirne, ma il gioco continua a funzionare. Un gioco simile scritto usando la scadente codifica C o C ++ potrebbe bloccarsi a causa dell'accesso a puntatori penzolanti a causa dello stesso tipo di errore di gestione delle risorse, ma non perderebbe così tanto.

Per i giochi l'incidente potrebbe essere preferibile nel senso che può essere rapidamente rilevato e risolto, ma per un programma mission-critical, lo schianto in momenti totalmente inaspettati potrebbe uccidere qualcuno. Quindi i casi principali che penso siano scenari in cui il non crash o altre forme di sicurezza sono assolutamente critici e una perdita logica è una cosa relativamente banale in confronto.

Lo scenario principale in cui penso sia male forzare GC è per cose in cui la perdita logica è in realtà meno preferibile di un incidente. Con i giochi, ad esempio, il crash non ucciderà necessariamente nessuno e potrebbe essere facilmente catturato e riparato durante i test interni, mentre una perdita logica potrebbe passare inosservata anche dopo la spedizione del prodotto a meno che non sia così grave da rendere il gioco ingiocabile in pochi minuti . In alcuni domini un arresto facilmente riproducibile che si verifica nei test è talvolta preferibile a una perdita che nessuno nota immediatamente.

Un altro caso che mi viene in mente dove potrebbe essere preferibile forzare GC in una squadra è per un programma di breve durata, come solo qualcosa eseguito dalla riga di comando che fa un compito e poi si spegne. In tal caso, la durata del programma è troppo breve per rendere non banale qualsiasi tipo di perdita logica. Le perdite logiche, anche per grandi risorse, di solito diventano problematiche solo ore o minuti dopo l'esecuzione del software, quindi è improbabile che un software che deve essere eseguito solo per 3 secondi abbia mai problemi con perdite logiche e potrebbe fare molto è più semplice scrivere programmi di così breve durata se il team ha appena usato GC.