Viene creata una perdita di memoria se un MemoryStream in .NET non è chiuso?

Ho il codice seguente:

MemoryStream foo(){
    MemoryStream ms = new MemoryStream();
    // write stuff to ms
    return ms;
}

void bar(){
    MemoryStream ms2 = foo();
    // do stuff with ms2
    return;
}

C'è qualche possibilità che il MemoryStream che ho allocato in qualche modo non possa essere smaltito in seguito?

Ho una revisione tra pari che insiste sul fatto che lo chiuda manualmente e non riesco a trovare le informazioni per dire se ha un punto valido o meno.

Se qualcosa è usa e getta, dovresti sempre smaltirlo. Dovresti usare una usingdichiarazione nel tuo bar()metodo per assicurarti che ms2venga eliminato.

Alla fine verrà ripulito dal Garbage Collector, ma è sempre buona norma chiamare Dispose. Se esegui FxCop sul tuo codice, lo contrassegnerà come un avviso.

Non trapelerai nulla, almeno nell'attuale implementazione.

La chiamata a Dispose non pulirà più velocemente la memoria utilizzata da MemoryStream. Esso sarà interrompere il flusso di essere valida per le chiamate di lettura / scrittura dopo la chiamata, che può o non può essere utile a voi.

Se sei assolutamente sicuro di non voler mai passare da un MemoryStream a un altro tipo di flusso, non ti farà alcun male non chiamare Dispose. Tuttavia, è generalmente buona pratica in parte perché se mai fare il cambiamento di utilizzare un diverso flusso, non si desidera ottenere morso da un bug difficile da trovare perché si è scelto la via più facile nella fase iniziale. (D'altra parte, c'è l'argomento YAGNI ...)

L'altro motivo per farlo comunque è che una nuova implementazione potrebbe introdurre risorse che verrebbero liberate su Dispose.

Sì, c'è una perdita , a seconda di come definisci LEAK e di quanto LATER intendi ...

Se per perdita intendi "la memoria rimane allocata, non disponibile per l'uso, anche se hai finito di usarla" e con quest'ultima intendi in qualsiasi momento dopo aver chiamato dispose, allora sì, potrebbe esserci una perdita, sebbene non sia permanente (cioè per la durata del runtime delle applicazioni).

Per liberare la memoria gestita utilizzata da MemoryStream, è necessario annullarne il riferimento, annullando il riferimento ad essa, in modo che diventi immediatamente idoneo per la garbage collection. Se non lo fai, crei una perdita temporanea dal momento in cui hai finito di usarlo, fino a quando il tuo riferimento esce dall'ambito, perché nel frattempo la memoria non sarà disponibile per l'allocazione.

Il vantaggio dell'istruzione using (rispetto alla semplice chiamata dispose) è che puoi DICHIARARE il tuo riferimento nell'istruzione using. Quando l'istruzione using termina, non solo viene chiamato dispose, ma il tuo riferimento esce dall'ambito, annullando di fatto il riferimento e rendendo immediatamente il tuo oggetto idoneo per la garbage collection senza che ti sia richiesto di ricordare di scrivere il codice "reference = null".

Sebbene non riuscire a togliere il riferimento a qualcosa subito non sia una classica perdita di memoria "permanente", ha sicuramente lo stesso effetto. Ad esempio, se mantieni il tuo riferimento a MemoryStream (anche dopo aver chiamato dispose), e un po 'più in basso nel tuo metodo provi ad allocare più memoria ... la memoria in uso dal tuo flusso di memoria ancora referenziato non sarà disponibile a te fino a quando non annulli il riferimento o non esce dall'ambito, anche se hai chiamato dispose e hai finito di usarlo.

La chiamata .Dispose()(o il wrapping con Using) non è richiesta.

Il motivo per cui chiami .Dispose()è rilasciare la risorsa il prima possibile .

Pensa in termini, ad esempio, al server Stack Overflow, in cui abbiamo un set limitato di memoria e migliaia di richieste in arrivo. Non vogliamo aspettare la garbage collection pianificata, vogliamo rilasciare quella memoria il prima possibile in modo che sia disponibile per nuove richieste in arrivo.

Questo ha già una risposta, ma aggiungerò solo che il buon vecchio principio di nascondere le informazioni significa che potresti in futuro voler eseguire il refactoring:

MemoryStream foo()
{    
    MemoryStream ms = new MemoryStream();    
    // write stuff to ms    
    return ms;
}

per:

Stream foo()
{    
   ...
}

Ciò sottolinea che ai chiamanti non dovrebbe interessare quale tipo di Stream viene restituito e rende possibile modificare l'implementazione interna (ad esempio, quando si prende in giro per test di unità).

Dovrai quindi essere nei guai se non hai usato Dispose nella tua implementazione della barra:

void bar()
{    
    using (Stream s = foo())
    {
        // do stuff with s
        return;
    }
}

Tutti i flussi implementano IDisposable. Avvolgi il tuo flusso di memoria in una dichiarazione di utilizzo e starai bene e dandy. Il blocco using garantirà la chiusura e l'eliminazione del flusso, qualunque cosa accada.

ovunque tu chiami Foo puoi farlo usando (MemoryStream ms = foo ()) e penso che dovresti comunque stare bene.

Non perderai memoria, ma il revisore del codice è corretto per indicare che dovresti chiudere lo stream. È educato farlo.

L'unica situazione in cui potresti perdere memoria è quando lasci accidentalmente un riferimento al flusso e non lo chiudi mai. Ancora non sono realmente che perde la memoria, ma si sta inutilmente estendere la quantità di tempo che si pretende di essere usarlo.

Suggerirei avvolgendo il MemoryStream in bar()in una usingdichiarazione soprattutto per la consistenza:

• In questo momento MemoryStream non libera la memoria .Dispose() , ma è possibile che in futuro possa farlo, o tu (o qualcun altro nella tua azienda) potresti sostituirlo con il tuo MemoryStream personalizzato che lo fa, ecc.
• È utile stabilire uno schema nel progetto per garantire che tutti gli stream vengano eliminati: la linea viene tracciata più saldamente dicendo "tutti gli stream devono essere eliminati" invece di "alcuni stream devono essere eliminati, ma alcuni non devono farlo" ...
• Se cambi il codice per consentire la restituzione di altri tipi di stream, dovrai cambiarlo per smaltirlo comunque.

Un'altra cosa che faccio di solito nei casi come foo()quando creo e restituisco un IDisposable è assicurarmi che qualsiasi errore tra la costruzione dell'oggetto e quello returnvenga intercettato da un'eccezione, elimini l'oggetto e rilanci l'eccezione:

MemoryStream x = new MemoryStream();
try
{
    // ... other code goes here ...
    return x;
}
catch
{
    // "other code" failed, dispose the stream before throwing out the Exception
    x.Dispose();
    throw;
}

Se un oggetto implementa IDisposable, devi chiamare il metodo .Dispose quando hai finito.

In alcuni oggetti, Dispose ha lo stesso significato di Chiudi e viceversa, in tal caso, uno dei due è buono.

Ora, per la tua domanda particolare, no, non perderai la memoria.

Non sono un esperto di .net, ma forse il problema qui sono le risorse, ovvero l'handle del file e non la memoria. Immagino che il garbage collector alla fine libererà il flusso e chiuderà l'handle, ma penso che sarebbe sempre buona pratica chiuderlo esplicitamente, per assicurarti di svuotare il contenuto su disco.

Lo smaltimento delle risorse non gestite non è deterministico nelle lingue raccolte in Garbage Collection. Anche se chiami Dispose in modo esplicito, non hai assolutamente alcun controllo su quando la memoria di supporto viene effettivamente liberata. Dispose viene chiamato implicitamente quando un oggetto esce dall'ambito, sia uscendo da un'istruzione using sia facendo apparire lo stack di chiamate da un metodo subordinato. Detto questo, a volte l'oggetto può effettivamente essere un wrapper per una risorsa gestita (ad esempio un file). Questo è il motivo per cui è buona pratica chiudere esplicitamente le istruzioni finalmente o utilizzare l'istruzione using. Saluti

MemorySteram non è altro che un array di byte, che è un oggetto gestito. Dimenticare di smaltire o chiudere questo non ha alcun effetto collaterale se non quello della finalizzazione.
Basta controllare il constuctor o il metodo di flush di MemoryStream nel riflettore e sarà chiaro perché non è necessario preoccuparsi di chiuderlo o eliminarlo se non per seguire la buona pratica.