¿Se crea una pérdida de memoria si MemoryStream en .NET no está cerrado?

Question

tengo el siguiente código:

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

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

¿Hay alguna posibilidad de que el MemoryStream que me ha asignado alguna manera dejar de ser eliminados más tarde?

Tengo una revisión por pares que insiste en que cierre manualmente esto, y no puedo encontrar la información para decir si tiene un punto válido o no.

Answer 1

Si algo es desechable, siempre debe desecharlo. Debería utilizar una instrucción using en su método bar() para asegurarse de que ms2 se disipe.

Eventualmente será limpiado por el recolector de basura, pero siempre es una buena práctica desechar. Si ejecuta FxCop en su código, lo marcará como una advertencia.

Answer 2

Todas las transmisiones implementan IDisposable. Envuelva su secuencia de memoria en una declaración de uso y estará bien y elegante. El bloque que usa se asegurará de que tu transmisión se cierre y elimine sin importar nada.

donde sea que llame a Foo puede hacerlo usando (MemoryStream ms = foo()) y creo que todavía debería estar bien.

Answer 3

Si un objeto implementa IDisposable, debe llamar al método .Dispose cuando haya terminado.

En algunos objetos, Eliminar significa lo mismo que Cerrar y viceversa, en ese caso, cualquiera de los dos es bueno.

Ahora, para su pregunta en particular, no, no perderá memoria.

Answer 4

No soy un experto en .net, pero tal vez el problema aquí sean los recursos, es decir, el identificador de archivo y no la memoria. Supongo que el recolector de basura eventualmente liberará la secuencia y cerrará el identificador, pero creo que siempre será una buena práctica cerrarla explícitamente, para asegurarse de que elimine el contenido del disco.

Answer 5

No es necesario llamar a .Dispose() (o envolver con Using).

La razón por la que llama .Dispose() es a liberar el recurso tan pronto como sea posible.

Piense en términos de, por ejemplo, el servidor Stack Overflow, donde tenemos un conjunto limitado de memoria y miles de solicitudes entrando. No queremos esperar la recolección programada de basura, queremos liberar esa memoria Lo antes posible, está disponible para nuevas solicitudes entrantes.

Answer 6

No perderá memoria, pero su revisor de código es correcto para indicar que debe cerrar la transmisión. Es educado hacerlo.

La única situación en la que puede perder memoria es cuando accidentalmente deja una referencia a la transmisión y nunca la cierra. Todavía no está realmente perdiendo memoria, pero es y extiende innecesariamente la cantidad de tiempo que dice que lo está usando.

Answer 7

No perderá nada, al menos en la implementación actual.

Calling Dispose no limpiará la memoria utilizada por MemoryStream más rápido. Es para evitar que su transmisión sea viable para las llamadas de Lectura/Escritura después de la llamada, lo que puede o no ser útil para usted.

Si está absolutamente seguro de que nunca quiere pasar de un MemoryStream a otro tipo de transmisión, no le hará ningún daño no llamar a Dispose. Sin embargo, en general es una buena práctica, en parte porque si alguna vez cambia para usar un Stream diferente, no querrá ser mordido por un error difícil de encontrar porque eligió la salida fácil desde el principio. (Por otro lado, está el argumento YAGNI ...)

La otra razón para hacerlo es que una nueva implementación puede introducir recursos que se liberarían en Dispose.

Answer 8

, recomendaría envolviendo el MemoryStream en bar() en un comunicado using principalmente para mantener la coherencia:

• En este momento MemoryStream no lo hace de memoria libre en .Dispose(), pero es posible que en algún momento en el futuro podría, o usted (u otra persona en su empresa) podría reemplazarlo con su propio MemoryStream personalizado, etc.
• Ayuda a establecer un patrón en su proyecto para asegurar todos Se eliminan las corrientes - la línea es más firme dibujado diciendo "todas las corrientes deben ser eliminadas" "en lugar de" algunas secuencias deben eliminarse, pero algunas no tienen que "...
• Si alguna vez cambia el código para permitir la devolución de otros tipos de flujos, tendrá que cambiarlo para eliminarlo de todos modos .

Otra cosa que suele hacer en casos como foo() la hora de crear y devolver un IDisposable es asegurar que cualquier fallo entre la construcción del objeto y de la return es capturado por una excepción, dispone el objeto, y relanzamientos la excepción:

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; 
} 

Answer 9

La eliminación de recursos no administrados no es determinista en los lenguajes recolectados. Incluso si llama a Dispose explícitamente, no tiene absolutamente ningún control sobre cuándo realmente se libera la memoria de respaldo. Dispose se llama implícitamente cuando un objeto sale del ámbito, ya sea saliendo de una instrucción using o apareciendo la pila de llamadas desde un método subordinado. Dicho todo esto, a veces el objeto puede ser un contenedor para un recurso administrado (por ejemplo, un archivo). Esta es la razón por la cual es una buena práctica cerrar de manera explícita en las sentencias finally o usar la instrucción using. Saludos

Answer 10

Esto ya está contestada, pero voy a añadir que el principio de buena pasada de moda de ocultación de información significa que es posible que en algún momento futuro querer refactorizar:

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

a:

Stream foo() 
{  
    ... 
} 

Esto enfatiza que a las personas que llaman no les debería importar qué tipo de flujo se está devolviendo, y hace posible cambiar la implementación interna (por ejemplo, cuando se burla para probar la unidad).

A continuación, tendrá que estar en problemas si no se ha utilizado Desechar en su aplicación barra:

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

Answer 11

Sí hay un fugas, dependiendo de cómo se defina la fuga y cuánto tiempo más tarde se significa ...

Si por fuga quiere decir "la memoria permanece asignada, no disponible para su uso, aunque haya terminado de usarla" y con esto quiere decir en cualquier momento después de llamar a disponer, entonces sí puede haber una fuga , aunque no es permanente (es decir, durante la vida de su aplicación tiempo de ejecución de las licaciones).

Para liberar la memoria administrada utilizada por MemoryStream, , necesita desvincularla, anulando su referencia a la misma, por lo que es elegible para la recolección de basura de inmediato. Si no puede hacer esto, entonces crea una fuga temporal desde el momento en que termina de usarla, hasta que su referencia quede fuera del alcance, porque mientras tanto, la memoria no estará disponible para la asignación.

El beneficio de la sentencia using (simplemente llamando a dispose) es que usted puede DECLARAR su referencia en la instrucción using. Cuando la instrucción using finaliza, no solo se llama a disposer, sino que su referencia queda fuera del alcance, anulando efectivamente la referencia y haciendo que su objeto sea elegible para la recolección de basura inmediatamente sin que tenga que recordar escribir el código "reference = null".

Si bien no dejar de hacer referencia a algo de inmediato no es una pérdida de memoria clásica "permanente", definitivamente tiene el mismo efecto. Por ejemplo, si mantiene su referencia al MemoryStream (incluso después de realizar una llamada a dispose), y un poco más abajo en su método, intenta asignar más memoria ... la memoria en uso por su secuencia de memoria aún referenciada no estará disponible para usted hasta que anule la referencia o se sale del alcance, a pesar de que llamó a disponer y ya lo hizo.

Answer 12

MemorySteram no es más que una matriz de bytes, que es un objeto gestionado. Olvídese de desechar o cerrar esto no tiene ningún efecto secundario que no sea por encima de la finalización.
Simplemente verifique el método de lavado o reflector de MemoryStream en el reflector y quedará claro por qué no tiene que preocuparse por cerrarlo o desecharlo, solo por cuestiones de buenas prácticas.