Te damos la bienvenida a nuestro sitio web, aquí vas a hallar la solucíon que estás buscando.
Solución:
Aquí hay un par de discusiones que explican por qué Dispose no es necesario para un DataSet.
¿Desechar o no desechar?:
El método Dispose en DataSet existe SÓLO debido al efecto secundario de la herencia; en otras palabras, en realidad no hace nada útil en la finalización.
¿Se debe llamar a Dispose en objetos DataTable y DataSet? incluye alguna explicación de un MVP:
El espacio de nombres system.data (ADONET) no contiene recursos no administrados. Por lo tanto, no es necesario deshacerse de ninguno de ellos siempre que no se haya agregado algo especial.
¿Comprende el método Dispose y los conjuntos de datos? tiene un comentario de la autoridad Scott Allen:
En la práctica, rara vez desechamos un conjunto de datos porque ofrece pocos beneficios “
Entonces, el consenso es que Actualmente no hay una buena razón para llamar a Dispose en un DataSet.
Actualización (1 de diciembre de 2009):
Me gustaría enmendar esta respuesta y admitir que la respuesta original era defectuosa.
El análisis original lo hace se aplican a objetos que requieren finalización, y el punto de que las prácticas no deben aceptarse en la superficie sin una comprensión precisa y profunda sigue en pie.
Sin embargo, resulta que DataSets, DataViews, DataTables suprimir la finalización en sus constructores – esta es la razón por la que llamar a Dispose () en ellos explícitamente no hace nada.
Presumiblemente, esto sucede porque no tienen recursos no administrados; así que a pesar del hecho de que MarshalByValueComponent hace concesiones para los recursos no administrados, estas implementaciones particulares no tienen la necesidad y, por lo tanto, pueden renunciar a la finalización.
(Que los autores de .NET se encarguen de suprimir la finalización en los mismos tipos que normalmente ocupan la mayor parte de la memoria habla de la importancia de esta práctica en general para los tipos finalizables).
No obstante, el hecho de que estos detalles todavía estén poco documentados desde el inicio de .NET Framework (hace casi 8 años) es bastante sorprendente (que esencialmente te dejen a tus propios dispositivos para tamizar material ambiguo y conflictivo para unir las piezas es frustrante a veces, pero proporciona una comprensión más completa del marco en el que confiamos todos los días).
Después de mucha lectura, aquí está mi comprensión:
Si un objeto requiere finalización, podría ocupar la memoria más tiempo del necesario; he aquí por qué: a) Cualquier tipo que define un destructor (o hereda de un tipo que define un destructor) se considera finalizable; b) En la asignación (antes de que se ejecute el constructor), se coloca un puntero en la cola de finalización; c) Un objeto finalizable normalmente requiere 2 colecciones para ser reclamado (en lugar del estándar 1); d) La supresión de la finalización no elimina un objeto de la cola de finalización (según lo informado por! FinalizeQueue en SOS). Este comando es engañoso; Saber qué objetos están en la cola de finalización (en sí mismo) no es útil; Sería útil saber qué objetos están en la cola de finalización y aún requieren finalización (¿hay un comando para esto?)
La supresión de la finalización se desactiva un poco en el encabezado del objeto, lo que indica al tiempo de ejecución que no necesita que se invoque su Finalizador (no es necesario mover la cola FReachable); Permanece en la cola de finalización (y continúa siendo informado por! FinalizeQueue en SOS)
Las clases DataTable, DataSet, DataView están todas enraizadas en MarshalByValueComponent, un objeto finalizable que puede (potencialmente) manejar recursos no administrados
- Debido a que DataTable, DataSet, DataView no introducen recursos no administrados, suprimen la finalización en sus constructores.
- Si bien este es un patrón inusual, libera a la persona que llama de tener que preocuparse por llamar a Dispose después de su uso.
- Esto, y el hecho de que las tablas de datos se pueden compartir potencialmente entre diferentes conjuntos de datos, es probablemente la razón por la que los conjuntos de datos no se preocupan por deshacerse de las tablas de datos secundarias.
- Esto también significa que estos objetos aparecerán debajo de! FinalizeQueue en SOS
- Sin embargo, estos objetos deben ser recuperables después de una sola colección, como sus contrapartes no finalizables.
4 (nuevas referencias):
- 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
Respuesta original:
Hay muchas respuestas engañosas y, en general, muy malas sobre esto: cualquiera que haya aterrizado aquí debe ignorar el ruido y leer las referencias a continuación con atención.
Sin lugar a dudas, desecha debiera ser llamado en cualquier objeto finalizable.
Tablas de datos están Finalizable.
Llamar a Dispose significativamente acelera la recuperación de la memoria.
MarshalByValueComponent llamadas GC.SuppressFinalize (esto) en su Dispose (): omitir esto significa tener que esperar docenas, si no cientos, de colecciones Gen0 antes de que se recupere la memoria:
Con esta comprensión básica de la finalización, ya podemos deducir algunas cosas muy importantes:
Primero, los objetos que necesitan finalización viven más tiempo que los objetos que no la necesitan. De hecho, pueden vivir mucho más tiempo. Por ejemplo, suponga que un objeto que está en gen2 necesita ser finalizado. Se programará la finalización, pero el objeto todavía está en gen2, por lo que no se volverá a recopilar hasta que se realice la siguiente recopilación de gen2. Eso podría ser mucho tiempo, de hecho, y, de hecho, si las cosas van bien, será mucho tiempo, porque las colecciones gen2 son costosas y, por lo tanto, queremos que sucedan con muy poca frecuencia. Los objetos más antiguos que necesitan finalización pueden tener que esperar decenas, si no cientos, de colecciones gen0 antes de que se recupere su espacio.
En segundo lugar, los objetos que necesitan finalización causan daños colaterales. Dado que los punteros de objeto internos deben permanecer válidos, no solo los objetos que necesitan finalización directamente permanecerán en la memoria, sino que todo lo que el objeto se refiere, directa e indirectamente, también permanecerá en la memoria. Si un gran árbol de objetos estuviera anclado por un solo objeto que requiriera finalización, entonces todo el árbol permanecería, potencialmente durante mucho tiempo, como acabamos de discutir. Por lo tanto, es importante utilizar los finalizadores con moderación y colocarlos en objetos que tengan la menor cantidad posible de punteros de objetos internos. En el ejemplo de árbol que acabo de dar, puede evitar fácilmente el problema moviendo los recursos que necesitan finalización a un objeto separado y manteniendo una referencia a ese objeto en la raíz del árbol. Con ese modesto cambio, solo un objeto (con suerte, un objeto pequeño y agradable) permanecería y el costo de finalización se minimiza.
Finalmente, los objetos que necesitan finalización crean trabajo para el hilo del finalizador. Si su proceso de finalización es complejo, el único subproceso del finalizador pasará mucho tiempo realizando esos pasos, lo que puede provocar una acumulación de trabajo y, por lo tanto, hacer que más objetos permanezcan esperando la finalización. Por lo tanto, es de vital importancia que los finalizadores hagan el menor trabajo posible. Recuerde también que, aunque todos los punteros a objetos siguen siendo válidos durante la finalización, podría darse el caso de que esos punteros lleven a objetos que ya se han finalizado y, por lo tanto, podrían no ser útiles. Por lo general, es más seguro evitar seguir los punteros a objetos en el código de finalización aunque los punteros sean válidos. Lo mejor es una ruta de código de finalización corta y segura.
Tómelo de alguien que ha visto cientos de MB de DataTables no referenciados en Gen2: esto es muy importante y las respuestas de este hilo lo pasan por alto por completo.
Referencias:
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 -colector-rendimiento-usando-finalizedispose-pattern.aspx
3 – http://codeidol.com/csharp/net-framework/Inside-the-CLR/Automatic-Memory-Management/
Debe asumir que hace algo útil y llamar a Dispose incluso si no hace nada en las encarnaciones actuales de .NET Framework. No hay garantía de que se mantenga así en versiones futuras, lo que provocará un uso ineficiente de los recursos.
Al final de la post puedes encontrar las críticas de otros gestores de proyectos, tú también tienes la opción de insertar el tuyo si dominas el tema.