2015-03-10 7 views
6

Ich habe nach der Möglichkeit gesucht, dass eine meiner Anwendungen ein Speicherleck haben könnte, also habe ich angefangen mit ein paar sehr einfachen Code Samples zu spielen. Eines, mit dem ich am Ende war, begann sich im Hinblick auf die Anzahl der Griffe (> 3000) stark zu erhöhen. Es ist eine sehr einfache Konsolenanwendung mit dem Code wie folgt:C# Handles Count

public static void Main(string[] args) 
{ 
    using (SqlConnection sqlConnection = new SqlConnection()) 
    { 
    } 

    Console.ReadLine(); 
} 

den SqlConnection Anruf herausnehmen entfernt alle Griffe zu erhöhen, so dass ich davon aus, es etwas mit dem Verbindungspool zu tun hat. Aber da dies nur einmal abläuft, bevor man auf die Eingabe wartet, warum steigt die Handle-Zahl weiter an?

Danke.

+1

Wie überprüfen Sie die Handleanzahl? – tia

+0

Ich benutze Task-Manager und auch Process Explorer (sysinternals). –

+0

ein Speicherverlust wird verursacht, wenn ein Programm Speicher für die eigene Verwendung reserviert und beim Herunterfahren nicht freigegeben wird oder das eigene Speicherkontingent überschreitet und in einen Block schreibt, der von einem anderen Prozess verwendet wird, sollte das Betriebssystem das zweite und das andere verhindern Das Framework verhindert die erste, es sei denn, Sie Marshal verwenden, um Speicher manuell zuzuordnen und nicht danach aufräumen Speicherverluste sind wahrscheinlich nicht das Problem – MikeT

Antwort

4
+0

Danke tia. Dies scheint das Problem zu sein. Ich habe im Projekt von Framework 4.5.1 auf 3.5 gewechselt, neu aufgebaut, und jetzt bleibt die Handle-Anzahl konstant. So geht das oben von Microsoft gepostete ist es nur langsam, aus dem Thread-Pool zu sammeln und die Handle-Zahl würde schließlich herunterkommen, wenn genug Aktivität in einer Anwendung verursacht die GC zu treten. Noch scheint ein seltsames Verhalten in .Net 4.0 einzuführen ... vielleicht mit Performance oder etwas zu tun ... Nun, zumindest macht es klar, was ich sehe. Prost. –

0

Sie, dass der größte Teil der Objekt-Cache zu finden, ist der Rahmen zusammengesetzt Objekte wie diejenigen erstellt, so dass Sie die Konfigurationsdateien und Ressourcen aus, die die Dateien manuell analysiert zugreifen können, um sie

IIRC die Standard-Objekt-Cache ist ungefähr 4000 Objekte.

Sie müssen bedenken, dass, nur weil Ihr nur die Erstellung und eines einzelnen Objekts Entsorgung bedeutet nicht, das ist der ganze Rahmen der Arbeit

tut
+0

Vielen Dank für die Antwort. Ich verstehe, dass das Framework viel mehr im Hintergrund tut. Aber ohne den SqlConnection-Aufruf der Erstellung bleibt die Handle-Anzahl der Anwendung konstant. Wenn Sie also wirklich versuchen herauszufinden, was genau dieser Aufruf auslöst oder initiiert, führt dies zu diesem Handle-Zählverhalten. –

+0

Wenn Sie sich die SQL-Verbindungsklasse ansehen, sehen Sie, dass sie andere Klassen enthält, wie zum Beispiel SqlConnection, DbProviderFactory, IContainer. ISite, SecureString., ConnectionState usw. Wenn Sie den using-Befehl ordnungsgemäß verwenden, um das Verbindungsobjekt nach der Verwendung zu entfernen, wird es beim nächsten Durchlauf des GC aufgenommen, so dass keine Lecks auftreten sollten. Sie zwingen den GC, mit GC.Collect() – MikeT

+0

Hallo MikeT, danke noch einmal für die Antwort. Ich ging mit tia, weil ich den Unterschied im Verhalten von 3.5 im Vergleich zu 4.0 und darüber aufgezeigt habe. Aber ja, wahrscheinlich hätte das Erzwingen des GC dazu geführt. Obwohl ich weiß, ist das etwas, das normalerweise nicht empfohlen wird. Kann nur auf 3,5 zurückfallen. –