Laden...

Alle Instanzen einer Klasse ermitteln

Erstellt von Palladin007 vor 10 Jahren Letzter Beitrag vor 10 Jahren 4.173 Views
Palladin007 Themenstarter:in
2.080 Beiträge seit 2012
vor 10 Jahren
Alle Instanzen einer Klasse ermitteln

Die Runtime organisiert das, sehr effizient, über eine interne Tabelle mittels Methoden- und Instanzeigern.

Kann ich dann theoretisch auch alle Instanzen einer Klasse, die in dem aktuellen Prozess erstellt wurden und noch nicht zum löschen frei gegeben wurden, abfragen?

Einen Sinn hat das vermutlich nicht, ich frage einfach nur aus Interesse.

NuGet Packages im Code auslesen
lock Alternative für async/await

Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.

49.485 Beiträge seit 2005
vor 10 Jahren

Hallo Palladin007,

irgendwie muss der GC alle Objekte (aller Klassen) ermitteln können und dann unterscheiden können, ob diese noch referenziert sind oder nicht. Da der GC allerdings parallel zum eigentlichen Programm laufen kann, bedeutet das nicht automatisch, dass es auch einen sauberen Schnitt gibt; möglicherweise sind nach dem Start des GCs Lauf neue Objekte hinzugekommen. Ich würde also nicht darauf wetten, dass es wirklich so funktionieren würde, wie du es beschreibst.

Anderseits kann man ohne weiteres einen Konstruktor schreiben, der sich alle Objekte der Klasse in einem eigenen Dictionary merkt. Wenn man sicherstellen will, dass dieses Objekte trotzdem freigegeben werden können, obwohl sie hier referenziert werden, kann man WeakReference-Klasse benutzen.

herbivore

1.361 Beiträge seit 2007
vor 10 Jahren

Hi Palladin007,

Kann ich dann theoretisch auch alle Instanzen einer Klasse, die in dem aktuellen Prozess erstellt wurden und noch nicht zum löschen frei gegeben wurden, abfragen?

Aus dem Programm heraus ist dies sicherlich schwierig. Aber mit dem Debugger WinDbg problemlos möglich. So liefert

!dumpheap -type System.String

alle Instanzen vom Typ String. Wie im Artikel Spotting a Memory Leak With WinDBG in .NET beschrieben, kann das sehr nützlich sein.

Beste Grüße
zommi

W
955 Beiträge seit 2010
vor 10 Jahren

Hi,

ich würde mir anschauen wie ein Memory Profiler das macht. Das ist genau sein Job.

5.742 Beiträge seit 2007
vor 10 Jahren

Kann ich dann theoretisch auch alle Instanzen einer Klasse, die in dem aktuellen Prozess erstellt wurden und noch nicht zum löschen frei gegeben wurden, abfragen?

Aus Performance-Gründen: Verwende einen (fertigen) MemoryProfiler, z.B. den von Jetbrains.

Zu Logging / Debug-Zwecken:
Füge im Konstruktor der Objekte eine WeakReferenz auf this in eine statische Liste ein (wie herbivore meinte); muss eigentlich kein Dictionary sein.

49.485 Beiträge seit 2005
vor 10 Jahren

Hallo winSharp93,

das war oben vielleicht etwas knapp beschrieben. Ich bin davon ausgegangen, dass es sich um Objekte mit IDs handelt und man diese unter ihrer ID ins Dictionary einträgt. Das hat die gleiche Aufwandsklasse wie das Anhängen an eine Liste (beides O(1)), aber die Prüfung, ob es ein Objekt mit einer bestimmten ID schon gibt, geht beim Dictionary in O(1) statt O(n) bei der Liste. Wenn in meinem Programmen der Wunsch nach einer Liste aller Objekte bestand, dann eigentlich immer wegen genau dieser (schnellen) Prüfmöglichkeit. Deshalb habe ich ein Dictionary empfohlen.

herbivore

Palladin007 Themenstarter:in
2.080 Beiträge seit 2012
vor 10 Jahren

Interessant, diese WeakReference-Klasse, aber hat das überhaupt einen Sinn, außer zu Test-Zwecken?

Die einzige Idee, die ich jetzt so hätte, wäre eine Art Pool, der dafür sorgt, dass Objekte mit bestimmten Eigenschaften nicht mehrfach erstellt werden. Wenn dann ein Objekt erstellt werden soll, dann wird erst geschaut, ob irgendwo schon ein Objekt dieser Art vorhanden ist, selbst wenn es keine feste Referenz mehr gibt.

Der einzige Vorteil, den das dann aber hat, ist wohl, dass die erstellten Objekte nicht im Speicher behalten werden müssen, was bei einer größeren Zahl von verschiedenen Varianten ja ganz sinnvoll sein könnte.

Einen wirklichen Vorteil, bei dem es praktisch notwendig ist, die WeakReference-Klasse zu nutzen, da hab ich keine Idee.

NuGet Packages im Code auslesen
lock Alternative für async/await

Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.

49.485 Beiträge seit 2005
vor 10 Jahren

Hallo Palladin007,

... Objekte mit bestimmten Eigenschaften ...

ich würde stattdessen sagen Objekte mit eindeutigen IDs. Dann stimmt es genau mit meiner Beschreibung überein. WeakReference ist sicher keine Klasse, die man ständig braucht.

In Schwache Verweise werden Nutzen, Anwendungsbereich und Grenzen eigentlich ganz gut beschrieben.

Damit sind wir allerdings schon wieder etwas vom eigentlichen Thema ab.

herbivore

P
660 Beiträge seit 2008
vor 10 Jahren

Hallo,

ja, z. B. bei Dependency Injections (Unity als Beispiel),
oder aber auch bei der Messenger-Klasse aus dem MVVMLight-Framework wird WeakReference verwendet.

MfG
ProGamer*Der Sinn Des Lebens Ist Es, Den Sinn Des Lebens Zu Finden! *"Wenn Unrecht zu Recht wird dann wird Widerstand zur Pflicht." *"Ignorance simplifies ANY problem." *"Stoppt die Piraterie der Musikindustrie"