Manca la perdita in. Net threads

Question

Questo mi ha effettivamente morso un paio di volte. Se fai un codice semplice come questo:

private void button1_Click(object sender, EventArgs e) 
    { 

     for (int i = 0; i < 1000000; i++) 
     { 
      Thread CE = new Thread(SendCEcho); 
      CE.Priority = ThreadPriority.Normal; 
      CE.IsBackground = true; 
      CE.Start(); 
      Thread.Sleep(500); 
      GC.Collect(); 
     } 
    } 

    private void SendCEcho() 
    { 
     int Counter = 0; 

     for (int i = 0; i < 5; i++) 
     { 
      Counter++; 
      Thread.Sleep(25); 
     } 
    } 

Esegui questo codice e guarda le maniglie volare! Thread.Sleep è così puoi spegnerlo e non prendere il controllo del tuo computer. Questo dovrebbe garantire che il thread lanciato muoia prima dell'avvio del thread successivo. Chiamando GC.Collect(); non fa nulla. Dalla mia osservazione questo codice perde 10 handle ogni aggiornamento al task manager al normale aggiornamento.

Non importa ciò che è nella funzione SendCEcho() del vuoto, contare fino a cinque se si desidera. Quando il filo muore, c'è una maniglia che non viene pulita.

Con la maggior parte dei programmi questo non ha molta importanza perché non vengono eseguiti per lunghi periodi di tempo. Su alcuni dei programmi che ho creato devono essere eseguiti per mesi e mesi.

Se si esercita questo codice più e più volte, è possibile perdere le maniglie fino al punto in cui il sistema operativo Windows diventa instabile e non funzionerà. Riavvio richiesto.

ho risolto il problema utilizzando un pool di thread e il codice come questo:

ThreadPool.QueueUserWorkItem(new WaitCallback(ThreadJobMoveStudy)); 

La mia domanda però è perché c'è una tale perdita in .Net, e perché è esistito così a lungo? Dal momento che come 1.0? Non sono riuscito a trovare la risposta qui.

Answer 1

Prova ad aggiungere GC.WaitForPendingFinalizers(); dopo la chiamata a GC.Collect(); Penso che ti prenderà ciò che cerchi. fonte completa di seguito:

EDIT

anche dare un'occhiata a questo dal 2005: https://bytes.com/topic/net/answers/106014-net-1-1-possibly-1-0-also-threads-leaking-event-handles-bug. Quasi lo stesso codice del tuo.

using System; 
using System.Threading; 

class Program 
{ 
    static void Main(string[] args) 
    { 
     for (int i = 0; i < 1000000; i++) 
     { 
      Thread CE = new Thread(SendCEcho); 
      CE.Priority = ThreadPriority.Normal; 
      CE.IsBackground = true; 
      CE.Start(); 
      Thread.Sleep(500); 
      CE = null; 
      GC.Collect(); 
      GC.WaitForPendingFinalizers(); 
     } 
    } 

    public static void SendCEcho() 
    { 
     int Counter = 0; 
     for (int i = 0; i < 5; i++) 
     { 
      Counter++; 
      Thread.Sleep(25); 
     } 
    } 
} 

Answer 2

Stai creando thread che non finiscono mai. Il ciclo for in SendCEcho non termina mai, quindi i thread non terminano mai e quindi non possono essere recuperati. Se aggiusto il tuo codice loop, i thread terminano e vengono recuperati come previsto. Non riesco a riprodurre il problema con il codice qui sotto.

static void SendCEcho() 
{ 
    int Counter = 0; 

    for (int i = 0; i < 5; i++) 
    { 
     Counter++; 
     Thread.Sleep(25); 
    } 
} 

Answer 3

for (int i = 0; i < 5 + i++;) 

Abbastanza bizzarro errore di battitura, non hai ricreato il problema reale. Ce n'è uno, un oggetto Thread consuma 5 handle di sistema operativo, il suo finalizzatore interno li rilascia. Una classe .NET normalmente ha un metodo Dispose() per garantire che tali handle possano essere rilasciati in anticipo ma Thread non ne ha uno. Si trattava di un design coraggioso, un tale metodo Dispose() sarebbe molto difficile da chiamare,.

Quindi dover fare affidamento sul finalizzatore è un requisito irrinunciabile. In un programma che ha un metodo "SendEcho" e non fa altro, si corre il rischio che il garbage collector non venga mai eseguito. Quindi il finalizzatore non può fare il suo lavoro. Spetta a te chiamare GC.Collect(). Considereresti di farlo ogni, diciamo, 1000 discussioni che inizi. Oppure usa ThreadPool.QueueUserWorkItem() o Task.Run() in modo da riciclare i thread, l'approccio logico.

Utilizzare Perfmon.exe per verificare che il GC non sia effettivamente in esecuzione. Aggiungi il contatore delle memorie CLR .NET> # Gen 0 per il tuo programma.