¿Flujos de cierre, siempre necesarios? .net

Question

Siempre es necesario cerrar flujos o, dado que .net es código administrado, se cerrará automáticamente tan pronto como se salga del alcance (suponiendo que no haya excepciones).

Ilustrado:

static string SerialiseObjectToBase64(object obj) 
{ 
    var mstream = new MemoryStream(); 
    ... 
    return Convert.ToBase64String(mstream.ToArray());   
} 

es aceptable el código anterior?

Answer 1

Con un MemoryStream que es un poco de un punto discutible - ya que en última instancia está hablando con un logrado byte[] (por lo que todavía va a esperar a que la recolección de basura de rutina). Pero en general, sí: debe cerrar (mejor: Dispose() a través de using, por lo que se cierra en caso de excepción) cuando la secuencia finaliza; de lo contrario, es posible que no vacíe algunos datos en el destino subyacente (no administrado). Y hay algunas transmisiones que en realidad no se "limpian" completamente en Flush() - necesitan para ser Close() d (especialmente las corrientes de compresión).

Answer 2

Es una buena práctica cerrar las transmisiones. Use la instrucción using, y se llamará al Dispose() cuando caiga fuera del alcance (o si se lanza una excepción), lo que a su vez cerrará la transmisión.

static string SerialiseObjectToBase64(object obj) 
{ 
    using (var mstream = new MemoryStream()) 
    { 
     ... 
     return Convert.ToBase64String(mstream.ToArray()); 
    } 
} 

Answer 3

. El GC de la red es muy ... flojo. El hecho de que se haya perdido una referencia no significa que sea inmediatamente barrida, triturada y enviada al vertedero. Siempre es una buena idea cerrar los recursos abiertos y deshacerse de los objetos que implementan IDisposable por esa misma razón.

Answer 4

Cerrar las transmisiones y deshacerse de los objetos son dos cosas diferentes. El cierre de flujos vacía el buffer de escritura y escribe cualquier dato no escrito en la transmisión. La eliminación de la secuencia simplemente liberará la memoria utilizada por la variable de flujo.