c# - net - ¿Es necesario disponer System.Timers.Timer si usa uno en su aplicación?
timer interval asp net (7)
En general, siempre debe disponer de los recursos desechables. Ciertamente lo buscaría en el caso que describa arriba. Si implementa IDisposable en la clase que implementa el temporizador, puede usar la clase en una instrucción de uso, lo que significa que los recursos se liberarán explícitamente cuando se elimine su clase.
Estoy usando la clase System.Timers.Timer en una de las clases de mi aplicación. Sé que la clase Timer tiene el método Dispose heredado de la clase componente primaria que implementa la interfaz IDisposable. Las instancias de la clase siguiente se crean muchas veces durante el ciclo de vida de mi aplicación; cada uno de ellos tiene una instancia de la clase Timer que genera eventos transcurridos de forma continua durante el ciclo de vida de la clase. ¿Debería implementar una interfaz IDisposable en la clase que usa la clase Timer para eliminar el objeto del temporizador? (He visto código que no hace esto en absoluto). Me temo que algunos recursos no administrados no se liberarán si utilizo la clase siguiente de esta manera:
SomeClass someClass = new SomeClass();
someClass.DoSomething();
someClass = null;
La clase:
using System.Timers;
public class SomeClass
{
private Timer m_timer;
public SomeClass()
{
m_timer = new Timer();
m_timer.Interval = 1000;
m_timer.Elapsed += new ElapsedEventHandler(m_timer_Elapsed);
m_timer.AutoReset = false;
m_timer.Start();
}
public void DoSomething()
{
}
private void m_timer_Elapsed(object sender, ElapsedEventArgs e)
{
try
{
//Do some task
}
catch (Exception ex)
{
//Ignore
}
finally
{
if (m_timer != null)
{
//Restart the timer
m_timer.Enabled = true;
}
}
}
}
Supongo que el objeto del temporizador crea o usa un hilo de trabajo para disparar los eventos del temporizador. La llamada de eliminación liberará el hilo y los recursos asociados con él. Si ese es el caso, sería una buena idea llamar a dispose para no tener hilos sin usar por mucho tiempo.
Estoy de acuerdo con Rowland.
Existe una regla en FxCop que encuentra clases que contienen objetos desechables, pero que no implementan correctamente IDisposable.
Veo que hiciste esta pregunta hace un año, pero déjame agregar mi valor de 2 centavos. Un poco menos debido a la inflación :). Recientemente descubrí en nuestra aplicación que no nos estábamos deshaciendo de los temporizadores. Teníamos una colección de objetos y cada objeto tenía un temporizador. Cuando eliminamos el artículo de la colección pensamos que debería haber sido recolectado. Por alguna razón, no es así con los temporizadores. Tuvimos que llamar a disponer sobre el objeto en la colección para deshacerse del temporizador antes de que los objetos fueran realmente basura.
El temporizador debe eliminarse, o continuará prendiendo fuego durante un tiempo después de haber "terminado" con él. Sin embargo, debido a problemas con el hilo, aún puede disparar un corto tiempo después de haberlo eliminado.
Al implementar Idisposable, podrá ordenar cualquier recurso interno que también implemente como no idisposable, como su temporizador.
Además, podría cambiar su código de llamada para usar la declaración de uso.
using (SomeClass someClass = new SomeClass())
{
someClass.DoSomething();
}
La regla práctica que uso es hacer cualquier cosa que tenga un objeto IDisposable, IDisposable por sí mismo (y eliminar los objetos secundarios solo cuando se llame explícitamente a Dispose)
Hay una buena discusión sobre IDisposable en el blog de Joe Duffy junto con muestras de código que se parecen mucho a las de mi copia del excelente libro de pautas de diseño de Framework.