Garbage Collector kann Speicherressourcen nicht wiederherstellen

Question

Ich versuche zu testen, wie die schweren Objekte innerhalb der .net BlockingCollection behandelt werden.

Ich bekomme die schweren Objekte mit einigen API, und möchte es in mehreren Threads verarbeiten. Um dies zu tun, habe ich einen Thread, der die schweren Objekte liest und sie in mehrere Threads verschiebt, wobei jeder Thread seine eigene blockierende Sammlung hat und jeder dieser Threads das Objekt aus der Sammlung und dem Prozess herausnimmt. Ich erwarte, dass GC, wenn das Objekt aus der gesamten Sammlung entfernt wird, wo immer es sitzt, in der Lage sein sollte, es zu säubern. Das Aufräumen passiert nicht und mein Programm geht aus dem Speicher.

Calling GC.Collect() dazwischen hilft mir, den Prozess abzuschließen, aber es hat erhebliche Leistungseinbußen, die ich mir nicht leisten kann zu nehmen.

Meine einzige Frage ist, warum Garbage Collector die Ressourcen hier nicht freigeben kann, auch wenn die Objekte nicht in Reichweite sind.

public class DummyProcessor 
{ 
    List<BlockingCollection<object>> listOfBlockingCollection = null; 

    void ProcessCollection(object blockingCollection) 
    { 
     BlockingCollection<object> collection = (BlockingCollection<object>)blockingCollection; 

     while (collection.IsCompleted == false) 
     { 
      object heavyObject = collection.Take(); 

      CallExternalProcess(heavyObject); 
     } 
    } 

    private void CallExternalProcess(object heavyObject) 
    { 
     throw new NotImplementedException(); 
    } 

    public void Analyze(object heavyObject) 
    { 
     if (listOfBlockingCollection == null) 
     { 
      listOfBlockingCollection = new List<BlockingCollection<object>>(); 

      for (int i = 0; i < 25; i++) 
      { 
       BlockingCollection<object> coll = new BlockingCollection<object>(); 

       listOfBlockingCollection.Add(coll); 

       Thread pt = new Thread(new ParameterizedThreadStart(ProcessCollection)); 

       pt.Start(coll); 
      } 
     } 

     for (int i = 0; i < 25; i++) 
     { 
      listOfBlockingCollection[i].Add(heavyObject); 
     } 
    } 
} 

Answer 1

Nachdem ich die Anwendung über dotMemory ausgeführt hatte, stellte ich fest, dass die schweren Objekte zu schnell erzeugt wurden, dass sie in großer Anzahl über den Computerspeicher hinaus angesammelt wurden.
Mein ausdrücklicher Aufruf an GC.Collect funktionierte nicht, weil es das verwendete schwere Objekt freigab, aber es fügte Art der Pause zur schweren Gegenstandproduktion ein, die Verbrauchergewinnen mehr Zeit gab, um zu klären, was bereits im BlockingCollection ist.
Also musste ich warten zwischen dem schweren Objekt Hersteller und Verbraucher, so dass ich nicht den verfügbaren Speicher überbeanspruchen.Dafür benutze ich die AutoResetEvent. Ich rufe AutoResetEvent.WaitOne an, nachdem die Sammlungsgröße etwas Reichweite erreicht und sobald es unter den Bereich fällt, rufe ich AutoResetEvent.Set an, um den Produzenten wieder zu laufen.

Vielen Dank für Ihre Eingabe zu diesem Thema.

Answer 2

Im Moment kann ich keine Bedrohungen in diesem Code sehen, wenn die Analyze in Thread-sichere Weise aufgerufen wird. Wenn es eine Analyse aus dem dotMemory gibt, fügen Sie sie bitte zur Frage hinzu.

Allerdings möchte ich darauf hinweisen, wie Sie die Analyze Methode aufrufen. Zunächst initialisieren Sie listOfBlockingCollection Variable in nicht Thread-sicherer Weise, denn wenn Sie eine zwei Threads ausführen die Analyze Methode, können Sie das Rennen und eine Situation, in der mehr als ein Thread führt die if Klausel in Ihrem Code .

In diesem Fall erstellen Sie mindestens 25 Geister Threads und mehr signifikant, können Sie die Situation dann listOfBlockingCollection haben mehr als 25 Artikel bekommen: nach wie vor, wenn einige Thread bereits aus if-Klausel und andere erstellt Threads und fügt Sammlungen zur Liste hinzu (Sie können zum Beispiel die listOfBlockingCollection.Count auschecken). Ein Thread ist mindestens 2 MB im Speicher und als IDisposable Objekt wird er nicht so schnell wie gewünscht gesammelt.

Andere Problem mit Ihrem Code ist, dass 25 Threads eine nicht effiziente Anzahl von Threads ist (nur wenn Sie einen Supercomputer mit 32 Kernen haben, könnte dies eine Option sein) wegen der Kontextwechsel. Es ist besser, die Anzahl der Threads zu verwenden, die der Anzahl der Kerne in Ihrem System entspricht, oder, besser, wechseln Sie Ihren Code auf Task -orientiert (Sie können problemlos 25 Tasks für die Verarbeitung erstellen und in ihnen eine Schleife einfügen).

Eine weitere Option, wenn Sie einen zusätzlichen Daten-Workflow benötigen, können Sie in Ihrer Anwendung eine TPL DataFlow-Bibliothek mit 25 ActionBlocks verwenden, die 25 verschiedene Flüsse startet. Nachdem Sie die schwere Objektwarteschlange beendet haben, können Sie ganz einfach send the Complete command über die Blöcke hinweg ausführen und Ihre Ausführung beenden.