Wie erzwinge ich löschen eines Objekts?

  • C#
  • .NET (FX) 4.5–4.8

Es gibt 9 Antworten in diesem Thema. Der letzte Beitrag () ist von thefiloe.

    Wie erzwinge ich löschen eines Objekts?

    Hallo Leute und danke fürs reinschauen...

    mein Problem ist eigentlich oben schon beschrieben....

    Kann ich irgend wie den Garbage Collector erzählen, dass ich das Objekt nicht mehr brauche und der es auflösen soll?

    Danke im Voraus.

    Wozu brauchst Du das? Der GC macht das doch immer richtig.
    Ansonsten kannste Deine Sachen halt selber disposen, indem Du IDisposable implementierst.

    Grüße
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:

    Ob ich es brauche oder nicht, ist hier nicht die Frage... Wenn ich danach frage, dann werde ich es wohl brauchen...

    Und sich rein auf GC verlassen, ist auch nicht immer die Lösung. Ich habe ein Objekt mit einem Hintergrundprozess, der sich nicht auflöst. Deswegen will ich es erzwingen...

    Wie @Trade bereits grsagt hat: Das Interface IDisposable per Implements IDisposable implementieren, VS erstellt automatisch die Methoden, in denen kannst du dann, falls benötigt, interne Resourcen freigeben oder einfach nix machen, wenn du nix freizugeben hast.
    Anschließend mit ​Using-Block das Objekt erstellen und verwenden. Wenn der Programmablauf über das ​End Using hinaus geht, wird automatisch die Dispose Methode aufgerufen und das Objekt von det GC vernichtet.

    Soweit ich weiß gibt es auch noch die Object.Finalize Methode
    Hier der Unterschied zwischen Finalize() und Dispose():
    stackoverflow.com/questions/732864/finalize-vs-dispose

    Lg Radinator
    In general (across programming languages), a pointer is a number that represents a physical location in memory. A nullpointer is (almost always) one that points to 0, and is widely recognized as "not pointing to anything". Since systems have different amounts of supported memory, it doesn't always take the same number of bytes to hold that number, so we call a "native size integer" one that can hold a pointer on any particular system. - Sam Harwell

    EugenIS schrieb:

    Und sich rein auf GC verlassen, ist auch nicht immer die Lösung
    Doch eigentlich schon. Das sollte in der Regel passen.

    EugenIS schrieb:

    Ich habe ein Objekt mit einem Hintergrundprozess, der sich nicht auflöst.
    Dann hast du noch irgendwo Verweise auf das Objekt. Denk dran, wie Trade und Radinator bereits gesagt haben, wenn die Klasse des Objektes IDisposable implemetiert, dann musst du auch Dispose() aufrufen oder halt mit Usings arbeiten. Beliebt ist auch immer Events angehängt zu haben, die dann das Objekt halten. Die musst du wieder abhänge.

    Wenn du aber den GB zwingen willst mal los zu legen kannst du das so machen:

    C#-Quellcode

    1. GC.Collect();
    2. GC.WaitForPendingFinalizers();
    3. GC.Collect();

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Bluespide“ ()

    So etwas hab ich doch auch mal verwendet irgendwo. Der entläd ALLES aus dem Ram. Ich weiss nur nicht mehr woher ich dieses Snippets hab.Und daher wäre vorsichtig mit diesem Code. Unter bestimmten Umständen kann er zu einer enorm hohen Auslastung führen.

    VB.NET-Quellcode

    1. Public Class MemoryManagement
    3. Private Declare Function SetProcessWorkingSetSize Lib "kernel32.dll" ( _
    4. ByVal process As IntPtr, _
    5. ByVal minimumWorkingSetSize As Integer, _
    6. ByVal maximumWorkingSetSize As Integer) As Integer
    8. Public Shared Sub FlushMemory()
    9. GC.Collect()
    10. GC.WaitForPendingFinalizers()
    11. If (Environment.OSVersion.Platform = PlatformID.Win32NT) Then
    12. SetProcessWorkingSetSize(Process.GetCurrentProcess().Handle, -1, -1)
    13. End If
    14. End Sub
    16. End Class


    VB.NET-Quellcode

    1. ​'Aufrufen mit
    2. MemoryManagement.FlushMemory()


    Freundliche Grüsse

    exc-jdbi

    Trade schrieb:

    Der GC macht das doch immer richtig.
    Das ist so nicht ganz richtig.
    Wir haben eine App, wo eine native DLL per NET-Wrapper (das alles als Third Party) größere Datenmengen verwaltet. Da muss trotz .Dispose() gelegentlich ein GC.Collect() aufgerufen werden, damit der Speicher nicht vollläuft.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Aber sollte der GC das nicht spätestens dann machen, wenn du neuen Speicher anforderst und keiner mehr da ist? Wenn du z.B. in einem Button_Click ein Array erzeugst und verwendest wird das in der Regel am Ende der Methode auch nicht direkt abgeräumt, sonder erst wenn wieder eine größere Menge neu bezogen wird. Der GC räumt halt nicht immer alles sofort ab.

    Das Problem mit der GC ist folgendes: Du weißt einfach ned, WANN genau sie passiert.

    Auf der BASDA! Conferrence 2015 hat Andre Krämer mal in seinem Vortrag die GC erläutert.
    Schau einfach hier mal vorbei:

    Relativ am Anfang (ab Minute 2:30)

    Eigentlich ist das ganze Video sehr empfehlenswert
    In general (across programming languages), a pointer is a number that represents a physical location in memory. A nullpointer is (almost always) one that points to 0, and is widely recognized as "not pointing to anything". Since systems have different amounts of supported memory, it doesn't always take the same number of bytes to hold that number, so we call a "native size integer" one that can hold a pointer on any particular system. - Sam Harwell

    Kurz und bündig: der GC beendet keine Threads. Maximal über eine korrekt implementierte Dispose Methode. Da macht der aber auch nicht mehr als die aufzurufen.


    Opensource Audio-Bibliothek auf github: KLICK, im Showroom oder auf NuGet.

Facebook