Devo disporre () DataSet e DataTable?

DataSet e DataTable implementano entrambi IDisposable, quindi, secondo le migliori pratiche convenzionali, dovrei chiamare i loro metodi Dispose ().

Tuttavia, da quello che ho letto finora, DataSet e DataTable in realtà non hanno risorse non gestite, quindi Dispose () in realtà non fa molto.

Inoltre, non posso semplicemente usarlo using(DataSet myDataSet...)perché DataSet ha una raccolta di DataTables.

Quindi, per sicurezza, avrei bisogno di scorrere attraverso myDataSet.Tables, eliminare ciascuna delle DataTables, quindi eliminare il DataSet.

Quindi vale la pena chiamare Dispose () su tutti i miei DataSet e DataTables?

Addendum:

Per quelli di voi che pensano che DataSet debba essere eliminato: in generale, lo schema per lo smaltimento è di usare usingo try..finally, perché si desidera garantire che verrà chiamato Dispose ().

Tuttavia, questo diventa brutto molto velocemente per una collezione. Ad esempio, cosa fai se una delle chiamate a Dispose () ha generato un'eccezione? Lo ingoiate (che è "cattivo") in modo da poter continuare a smaltire l'elemento successivo?

Oppure, mi suggerisci di chiamare myDataSet.Dispose () e di dimenticare di eliminare le DataTable in myDataSet.Tables?

Ecco un paio di discussioni che spiegano perché non è necessario disporre di un DataSet.

Smaltire o non smaltire? :

Il metodo Dispose in DataSet esiste SOLO a causa dell'effetto collaterale dell'ereditarietà, in altre parole, in realtà non fa nulla di utile nella finalizzazione.

Dispose deve essere chiamato su oggetti DataTable e DataSet? include alcune spiegazioni da un MVP:

Lo spazio dei nomi system.data (ADONET) non contiene risorse non gestite. Pertanto non è necessario smaltire nessuno di questi purché non vi sia stato aggiunto qualcosa di speciale.

Comprensione del metodo di eliminazione e dei set di dati? ha un commento dell'autorità Scott Allen:

In pratica raramente disponiamo di un DataSet perché offre pochi vantaggi "

Quindi, il consenso è che attualmente non esiste un buon motivo per chiamare Dispose su un DataSet.

Aggiornamento (1 dicembre 2009):

Vorrei modificare questa risposta e ammettere che la risposta originale era difettosa.

L'analisi originale si applica agli oggetti che richiedono la finalizzazione e il punto che le pratiche non dovrebbero essere accettate in superficie senza una comprensione accurata e approfondita rimane valido.

Tuttavia, si scopre che DataSet, DataViews, DataTables sopprimono la finalizzazione nei loro costruttori - questo è il motivo per cui chiamare Dispose () su di essi esplicitamente non fa nulla.

Presumibilmente, ciò accade perché non dispongono di risorse non gestite; quindi nonostante il fatto che MarshalByValueComponent tenga conto delle risorse non gestite, queste implementazioni particolari non hanno la necessità e possono quindi rinunciare alla finalizzazione.

(Che gli autori di .NET si preoccuperebbero di sopprimere la finalizzazione sui tipi che normalmente occupano la maggior parte della memoria parla dell'importanza di questa pratica in generale per i tipi finalizzabili.)

Ciononostante, questi dettagli sono ancora sotto documentati poiché la nascita di .NET Framework (quasi 8 anni fa) è piuttosto sorprendente (che in sostanza sei lasciato ai tuoi dispositivi per setacciare materiale ambiguo ma contrastante per mettere insieme i pezzi a volte è frustrante ma fornisce una comprensione più completa del quadro su cui facciamo affidamento ogni giorno).

Dopo molte letture, ecco la mia comprensione:

Se un oggetto richiede la finalizzazione, potrebbe occupare memoria più a lungo del necessario - ecco perché: a) Qualsiasi tipo che definisce un distruttore (o eredita da un tipo che definisce un distruttore) è considerato finalizzabile; b) Al momento dell'allocazione (prima che venga eseguito il costruttore), un puntatore viene posizionato sulla coda di finalizzazione; c) Un oggetto finalizzabile richiede normalmente la raccolta di 2 raccolte (anziché lo standard 1); d) La soppressione della finalizzazione non rimuove un oggetto dalla coda di finalizzazione (come riportato da! FinalizeQueue in SOS) Questo comando è fuorviante; Sapere quali oggetti si trovano nella coda di finalizzazione (di per sé) non è utile; Sapere quali oggetti si trovano nella coda di finalizzazione e richiedono ancora la finalizzazione sarebbe utile (esiste un comando per questo?)

La soppressione della finalizzazione si spegne un po 'nell'intestazione dell'oggetto indicando al runtime che non è necessario richiamare il finalizzatore (non è necessario spostare la coda FReachable); Rimane nella coda di finalizzazione (e continua a essere segnalato da! FinalizeQueue in SOS)

Le classi DataTable, DataSet, DataView sono tutte radicate in MarshalByValueComponent, un oggetto finalizzabile che può (potenzialmente) gestire risorse non gestite

• Poiché DataTable, DataSet, DataView non introducono risorse non gestite, eliminano la finalizzazione nei loro costruttori
• Sebbene questo sia un modello insolito, libera il chiamante dal doversi preoccupare di chiamare Dispose dopo l'uso
• Questo e il fatto che DataTables possono potenzialmente essere condivisi tra diversi DataSet, è probabilmente il motivo per cui i DataSet non si preoccupano di smaltire DataTables figlio
• Questo significa anche che questi oggetti appariranno sotto! FinalizeQueue in SOS
• Tuttavia, questi oggetti dovrebbero comunque essere recuperabili dopo una singola raccolta, come le loro controparti non finalizzabili

4 (nuovi riferimenti):

• http://www.devnewsgroups.net/dotnetframework/t19821-finalize-queue-windbg-sos.aspx
• http://blogs.msdn.com/tom/archive/2008/04/28/asp-net-tips-looking-at-the-finalization-queue.aspx
• http://issuu.com/arifaat/docs/asp_net_3.5unleashed
• http://msdn.microsoft.com/en-us/magazine/bb985013.aspx
• http://blogs.msdn.com/tess/archive/2006/03/27/561715.aspx

Risposta originale:

Ci sono molte risposte fuorvianti e generalmente molto povere su questo - chiunque sia atterrato qui dovrebbe ignorare il rumore e leggere attentamente i riferimenti qui sotto.

Senza dubbio, Dispose dovrebbe essere chiamato su qualsiasi oggetto Finalizable.

Le tabelle dei dati sono finalizzabili.

La chiamata a Dispose accelera notevolmente il recupero della memoria.

MarshalByValueComponent chiama GC.SuppressFinalize (this) nel suo Dispose () - saltare questo significa dover aspettare dozzine se non centinaia di raccolte Gen0 prima che la memoria venga recuperata:

Con questa comprensione di base della finalizzazione possiamo già dedurre alcune cose molto importanti:

Innanzitutto, gli oggetti che necessitano di finalizzazione vivono più a lungo degli oggetti che non lo fanno. In effetti, possono vivere molto più a lungo. Ad esempio, supponiamo che un oggetto in gen2 debba essere finalizzato. La finalizzazione verrà programmata ma l'oggetto è ancora in gen2, quindi non verrà nuovamente raccolto fino alla successiva raccolta gen2. Potrebbe essere davvero molto tempo e, in effetti, se le cose vanno bene, ci vorrà molto tempo, perché le raccolte gen2 sono costose e quindi vogliamo che accadano molto raramente. Gli oggetti più vecchi che necessitano di finalizzazione potrebbero dover attendere dozzine se non centinaia di raccolte gen0 prima che il loro spazio venga recuperato.

In secondo luogo, gli oggetti che necessitano di finalizzazione causano danni collaterali. Poiché i puntatori agli oggetti interni devono rimanere validi, non solo gli oggetti che necessitano direttamente di finalizzazione rimarranno nella memoria, ma tutto ciò a cui si riferisce l'oggetto, direttamente e indirettamente, rimarrà anche nella memoria. Se un enorme albero di oggetti fosse ancorato da un singolo oggetto che richiedeva la finalizzazione, allora l'intero albero rimarrebbe, potenzialmente per molto tempo, come abbiamo appena discusso. È quindi importante utilizzare i finalizzatori con parsimonia e posizionarli su oggetti con il minor numero possibile di puntatori interni. Nell'esempio dell'albero che ho appena dato, puoi facilmente evitare il problema spostando le risorse che necessitano di finalizzazione su un oggetto separato e mantenendo un riferimento a quell'oggetto nella radice dell'albero.

Infine, gli oggetti che necessitano di finalizzazione creano lavoro per il thread del finalizzatore. Se il processo di finalizzazione è complesso, l'unico thread del finalizzatore impiegherà molto tempo a eseguire tali passaggi, il che può causare un arretrato di lavoro e quindi far indugiare più oggetti in attesa della finalizzazione. Pertanto, è di vitale importanza che i finalizzatori facciano il minor lavoro possibile. Ricordare inoltre che sebbene tutti i puntatori a oggetti rimangano validi durante la finalizzazione, è possibile che tali puntatori portino a oggetti che sono già stati finalizzati e potrebbero quindi essere poco utili. È generalmente più sicuro evitare i seguenti puntatori oggetto nel codice di finalizzazione anche se i puntatori sono validi. Un percorso di codice di finalizzazione sicuro e breve è il migliore.

Prendilo da qualcuno che ha visto centinaia di MB di DataTable senza riferimenti in Gen2: questo è estremamente importante e completamente mancato dalle risposte su questo thread.

Riferimenti:

1 - http://msdn.microsoft.com/en-us/library/ms973837.aspx

2 - http://vineetgupta.spaces.live.com/blog/cns!8DE4BDC896BEE1AD!1104.entry http://www.dotnetfunda.com/articles/article524-net-best-practice-no-2-improve-garbage -collector-prestazioni-con-finalizedispose-pattern.aspx

3 - http://codeidol.com/csharp/net-framework/Inside-the-CLR/Automatic-Memory-Management/

Dovresti supporre che faccia qualcosa di utile e chiamare Dispose anche se non fa nulla in corrente. Incarnazioni di NET Framework, non vi è alcuna garanzia che rimarrà tale nelle versioni future portando a un uso inefficiente delle risorse.

Anche se l'oggetto non ha risorse non gestite, lo smaltimento potrebbe aiutare GC rompendo i grafici degli oggetti. In generale, se l'oggetto implementa IDisposable, dovrebbe essere chiamato Dispose ().

Se Dispose () fa effettivamente qualcosa o no dipende da una determinata classe. Nel caso di DataSet, l'implementazione di Dispose () viene ereditata da MarshalByValueComponent. Si rimuove dal contenitore e chiama l'evento Disposed. Il codice sorgente è di seguito (disassemblato con .NET Reflector):

protected virtual void Dispose(bool disposing)
{
    if (disposing)
    {
        lock (this)
        {
            if ((this.site != null) && (this.site.Container != null))
            {
                this.site.Container.Remove(this);
            }
            if (this.events != null)
            {
                EventHandler handler = (EventHandler) this.events[EventDisposed];
                if (handler != null)
                {
                    handler(this, EventArgs.Empty);
                }
            }
        }
    }
}

Crea tu stesso le DataTable? Perché l'iterazione attraverso i figli di qualsiasi oggetto (come in DataSet.Tables) di solito non è necessaria, poiché è compito del genitore disporre di tutti i suoi membri figlio.

Generalmente, la regola è: se l'hai creata e implementa IDisposable, eliminala. Se NON l'hai creato, NON lo getti, questo è il lavoro dell'oggetto genitore. Ma ogni oggetto può avere regole speciali, controlla la documentazione.

Per .net 3.5, dice esplicitamente "Smaltiscilo quando non lo usi più", quindi è quello che vorrei fare.

Chiamo dispose ogni volta che un oggetto implementa IDisposeable. È lì per un motivo.

I set di dati possono essere enormi porci di memoria. Prima possono essere contrassegnati per la pulizia, meglio è.

aggiornare

Sono passati 5 anni da quando ho risposto a questa domanda. Sono ancora d'accordo con la mia risposta. Se esiste un metodo dispose, dovrebbe essere chiamato quando hai finito con l'oggetto. L'interfaccia IDispose è stata implementata per un motivo.

Se la tua intenzione o il contesto di questa domanda è davvero la garbage collection, puoi impostare i set di dati e i database in modo esplicito su null o utilizzare la parola chiave usando e lasciarli fuori campo. Smaltire non fa molto come diceva Tetraneutron in precedenza. GC raccoglierà oggetti del set di dati che non fanno più riferimento e anche quelli che non rientrano nell'ambito.

Vorrei davvero che SO costringesse le persone a votare per scrivere un commento prima di votare la risposta.

I set di dati implementano MarshalByValueComponent completo IDisposable, che implementa IDisposable. Poiché i set di dati sono gestiti, non vi è alcun vantaggio reale nel chiamare disposose.

Prova a usare la funzione Clear (). Funziona benissimo per me per lo smaltimento.

DataTable dt = GetDataSchema();
//populate dt, do whatever...
dt.Clear();

Non è necessario disporre () poiché DataSet eredita la classe MarshalByValueComponent e l'interfaccia IDisposable dell'attrezzo MarshalByValueComponent