Anzeige:
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 15 von 21

Thema: Wann stirbt die Referenzierung oder woher weiss der Garbarge-Collector, dass ...

  1. #1
    Registrierter Benutzer
    Registriert seit
    16.06.2002
    Beiträge
    18

    Unhappy Wann stirbt die Referenzierung oder woher weiss der Garbarge-Collector, dass ...

    ... er aufräumen soll?

    guten Morgen,

    ehrlich gesagt, wird für mich Java immer unverständlicher. Das Speichermanagement wird für mich immer intransparenter. Bisher ging ich immer davon aus, dass ein Objekt solange initiiert ist und bleibt, bis entweder die letzte Referenz darauf geschlossen wird oder ein dispose() aufgerufen wird. Diese einfache Logik machte für mich auch Sinn, weil ja jedes Java-Programm mit einer Klasse startet. Sobald jedoch diese Klasse, welche alle anderen Objekte erzeugt und implizit auch darauf referenziert stirbt, müssen auch die erzeugten Objekte sterben.

    Nun habe ich mir jedoch das Singleton-Pattern angesehen. Auf dieses wird nicht referenziert. Es erzeugt sich selbst und bleibt im Speicher. Nun stellt sich mir die Frage: wie lange eigentlich? Und woher weiss der GC, dass er das Singleton aufräumen darf?

    Das Singleton ist für mich eine globales Objekt. Nur dachte ich, dass es genauso etwas in Java nicht gäbe? Jedenfalls verträgt sich das nicht mit meiner OO-Anschauung...

    Viele Grüße
    kit

  2. #2
    Registrierter Benutzer Avatar von peschmae
    Registriert seit
    14.03.2002
    Ort
    Schweizland
    Beiträge
    4.549
    Der Garbage Collector räumt grundsätzlich auf wann der will - d.h. speziell dann wenn der Speicher knapp wird (JVMs von Sun haben per default einen 64 MB Heap-Limit) und das Programm gerade sonst nichts tut.

    Grundsätzlich sollte dabei alles was nicht von irgendwo her referenziert wird abgeräumt werden dürfen. Wie das im Falle von einem Singleton aussieht weiss ich nicht, so Dinger habe ich bisher nur in C++ gesehen und dort sind die Probleme andere aber eigentlich ähnliche (wie zerstört man das Ding - wobei das kriegt man schon hin).
    Hast du da mal ein Beispiel von nem einfachen Singleton in Java?

    Hab gerade was gefunden: http://www.javacoffeebreak.com/articles/designpatterns/
    hier hast du immer mindestens eine Referenz auf das Ding - eine statische in der SingletonObject-Klasse (plus eventuell von getSingletonObject() herausgegebene Referenzen). Also wird da nix abgeräumt durch die Garbage-Colleciton.

    MfG Peschmä
    Geändert von peschmae (27-03-2005 um 12:32 Uhr)
    The greatest trick the Devil ever pulled was convincing the world he didn't exist. -- The Usual Suspects (1995)
    Hey, I feel their pain. It's irritating as hell when people act like they have rights. The great old one (2006)

  3. #3
    Registrierter Benutzer Avatar von fs111
    Registriert seit
    23.03.2002
    Beiträge
    594
    Zitat Zitat von kit

    Nun habe ich mir jedoch das Singleton-Pattern angesehen. Auf dieses wird nicht referenziert. Es erzeugt sich selbst und bleibt im Speicher. Nun stellt sich mir die Frage: wie lange eigentlich? Und woher weiss der GC, dass er das Singleton aufräumen darf?

    Das Singleton ist für mich eine globales Objekt. Nur dachte ich, dass es genauso etwas in Java nicht gäbe? Jedenfalls verträgt sich das nicht mit meiner OO-Anschauung...

    Viele Grüße
    kit
    Das Singleton wird gar nicht abgeräumt. Das soll es ja auch gerade nicht, denn seine Erzeugung ist teuer, und soll deshalb ja nur genau einmal geschehen. Das das Singleton seine einnzige Instanz selbst referenziert kann die GarbageCollection es nicht abräumen. Es gibt wohl einen Weg durch irgendwelche Events (habe nur davon gehört), auch dieses Objekt abzuräumen, das würde ja aber dem Sinn des Objektes widersprechen, denn man will es ja behalten bzw. schnell im Zugriff haben.

    fs111
    ....::::Mein Blag::::....

  4. #4
    Registrierter Benutzer
    Registriert seit
    16.06.2002
    Beiträge
    18
    Zitat Zitat von fs111
    Das Singleton wird gar nicht abgeräumt. Das soll es ja auch gerade nicht, denn seine Erzeugung ist teuer, und soll deshalb ja nur genau einmal geschehen. Das das Singleton seine einnzige Instanz selbst referenziert kann die GarbageCollection es nicht abräumen. Es gibt wohl einen Weg durch irgendwelche Events (habe nur davon gehört), auch dieses Objekt abzuräumen, das würde ja aber dem Sinn des Objektes widersprechen, denn man will es ja behalten bzw. schnell im Zugriff haben.

    fs111
    jo, genauso habe ich das verstanden. und genau das ist mein problem.
    folgendes beispiel: ich habe eine Klasse A und diese ist mein Hauptanwendung. Nun wird durch A an einer Stelle eine Nebenanwendung B (z.B. ein Steuerelement zum Auswählen eines Datums) aufgerufen. B initialisiert aber eine Singleton-Klasse (z.B. einen GregorianCalendar oder einen DateFormater), der aber nicht mehr gebraucht wird, wenn B wieder geschlossen wird, nachdem das Datum ausgewähl wurde.
    Heisst das nun, dass der Singleon die ganze Zeit bleibt, solange A läuft???? Ist das nicht wahnsinn? Was ist, wenn A ein GUI zur Steuerung ist und parktisch niemals stirbt? Bleiben dann alle Singletons von Steuerelementen, welche diese GUI anbietet geöffnet? Das hiese doch, dass nach einer Zeit die Summe aller Singletons im Speicher steht, selbst dann, wenn ich nur jeweils eines brauche???

    also irgendwie gefällt mir dieses Konzept nicht. Gibt es auch Sprachen, die soetwas sauber lösen, also wirklich OO (ist Singleton aus meiner Sicht nicht) und mit Freigabe, sobald die Referenz auf ein Objekt weg ist?

    viele Grüße
    kit

  5. #5
    Registrierter Benutzer Avatar von peschmae
    Registriert seit
    14.03.2002
    Ort
    Schweizland
    Beiträge
    4.549
    Es zwingt dich ja keiner Singletons zu verwenden wenn die nicht dem entsprechen was du willst. Es wäre ja nicht so dass das automatisch gutes Design wäre sowas zu verwenden nur weils einen Namen hat und im Design-Pattern Buch verewigt wurde...

    Um mal jemanden zu zitieren:
    Our group had a bad habit of using global data, so I did a study group on Singleton. The next thing I know Singletons appeared everywhere and none of the problems related to global data went away. The answer to the global data question is not, "Make it a Singleton." The answer is, "Why in the hell are you using global data?" Changing the name doesn't change the problem. In fact, it may make it worse because it gives you the opportunity to say, "Well I'm not doing that, I'm doing this" - even though this and that are the same thing. [Frieder Knauss]
    http://home.earthlink.net/~huston2/dp/singleton.html

    Wenn du das Objekt wieder loswerden willst ist die Frage wann. Wenn die Frage wann beantwortet ist dann machst du deinem Singleton-Klassendings halt noch eine Methode gibFreiZurGarbageCollection() hinzu die die static Referenz auf das Objekt auf null setzt - *dann* kann die GC auch zuschlagen weil es dann keine Referenz mehr auf das Objekt gibt.

    MfG Peschmä
    The greatest trick the Devil ever pulled was convincing the world he didn't exist. -- The Usual Suspects (1995)
    Hey, I feel their pain. It's irritating as hell when people act like they have rights. The great old one (2006)

  6. #6
    Registrierter Benutzer
    Registriert seit
    16.06.2002
    Beiträge
    18
    Zitat Zitat von peschmae
    Es zwingt dich ja keiner Singletons zu verwenden wenn die nicht dem entsprechen was du willst. Es wäre ja nicht so dass das automatisch gutes Design wäre sowas zu verwenden nur weils einen Namen hat und im Design-Pattern Buch verewigt wurde...
    das ist klar, nur scheinen nicht wenige Klassen in Java selbst als Singleton implementiert zu sein, nämlich alle, welche nicht als Konstruktor, sondern als getInstance() aufgerufen werden (zumindest vermute ich das wegen der Analogie in der Nomenklatur).

    wenn diese Vermutung stimmt, sind alle Klassen ala GregorianCalendar, Locale etc. ständig im Speicher, selbst wenn sie in der Anwendung nur einmal und kurz aufgerufen werden...

    und es käme dann gar nicht darauf an, ob ich selbst ein Singleton implementieren möchte oder ob nicht...

    weiss jemand, wie das in C# gelöst wurde? Ich werde mir wohl doch mal Ruby oder Haskel bzw. Eiffel anschauen.

    Viele Grüße
    kit

  7. #7
    Registrierter Benutzer Avatar von fs111
    Registriert seit
    23.03.2002
    Beiträge
    594
    Zitat Zitat von kit
    das ist klar, nur scheinen nicht wenige Klassen in Java selbst als Singleton implementiert zu sein, nämlich alle, welche nicht als Konstruktor, sondern als getInstance() aufgerufen werden (zumindest vermute ich das wegen der Analogie in der Nomenklatur).

    wenn diese Vermutung stimmt, sind alle Klassen ala GregorianCalendar, Locale etc. ständig im Speicher, selbst wenn sie in der Anwendung nur einmal und kurz aufgerufen werden...

    und es käme dann gar nicht darauf an, ob ich selbst ein Singleton implementieren möchte oder ob nicht...

    weiss jemand, wie das in C# gelöst wurde? Ich werde mir wohl doch mal Ruby oder Haskel bzw. Eiffel anschauen.

    Viele Grüße
    kit
    Die sind vermutlich ohnehin immer instanziiert, weil sie von verschiedenen anderen Klassen ohnehin benutzt werden, was bei Datums- und Zeitklassen für mich logisch erscheint.

    fs111
    ....::::Mein Blag::::....

  8. #8
    Registrierter Benutzer
    Registriert seit
    17.09.2001
    Beiträge
    1.182

    Hmm...

    Außerdem kann man einen Singleton ja so implementieren, dass die eigentliche Instanz erst beim ersten getInstance() erzeugt wird, somit ists wieder "kostenlos"...
    Geändert von Lin728 (21-08-2017 um 15:21 Uhr)

  9. #9
    Administrator Avatar von anda_skoa
    Registriert seit
    17.11.2001
    Ort
    Graz, Österreich
    Beiträge
    5.477
    Zitat Zitat von kit
    eine Singleton-Klasse (z.B. einen GregorianCalendar oder einen DateFormater)
    Bist du dir sicher daß es hier Singleton Instanzen sind?
    Referenzen nach zwei Aufrufen verglichen, eventuell gar mit einem GC Lauf dawzischen?

    Ciao,
    _
    Qt/KDE Entwickler
    Debian Benutzer

  10. #10
    Registrierter Benutzer
    Registriert seit
    16.06.2002
    Beiträge
    18
    Zitat Zitat von anda_skoa
    Bist du dir sicher daß es hier Singleton Instanzen sind?
    Referenzen nach zwei Aufrufen verglichen, eventuell gar mit einem GC Lauf dawzischen?

    Ciao,
    _
    hi,

    nein, ich bin mir nicht sicher und habe nur von der Nomenklatur ausgehend vermutet.
    Ich könnte allerdings mal in die Quellen des GCJ schauen...

    Viele Grüße
    kit

  11. #11
    Administrator Avatar von anda_skoa
    Registriert seit
    17.11.2001
    Ort
    Graz, Österreich
    Beiträge
    5.477
    Zitat Zitat von kit
    nein, ich bin mir nicht sicher und habe nur von der Nomenklatur ausgehend vermutet.
    Inwiefern schließt du da bei den als Beispielen genannten Factories (Calendar, Formatter) auf Singletons?

    Ich würde da eher davon ausgehen, daß die Factory jedesmal eine neue Instanz erzeugt solange nicht explizit etwas anderes angegeben ist.

    Ich könnte allerdings mal in die Quellen des GCJ schauen...
    Ein einfaches Beispiel (Referenzenvergleich) zeigt zumindest bei meiner JVM das zwei Calendar Instanzen verschieden sind.
    Was ansich auch sehr logisch ist, denn jede Instanz repräsentiert ja einen bestimmten Zeitpunkt.

    Ciao,
    _
    Qt/KDE Entwickler
    Debian Benutzer

  12. #12
    Registrierter Benutzer Avatar von RogerJFX
    Registriert seit
    13.04.2005
    Beiträge
    35

    Versteh ich nich

    Also wenn ich so ein Ding schreibe, verlasse ich doch wohl wissentlich alle OOP-Gefilde.

    Oder kürzer: was statisch ist, SOLL doch wohl die ganze Zeit im Speicher hängen. Und das will ich ja auch nicht anders in diesem Moment.

    Das ist alles eine Frage der Architektur. Ich KANN Singletons schreiben, sollte es aber wirklich erst dann tun, wenn ich genau weiß, was ich mache.

    Versuch doch mal, so ein Ding selbst zu entsorgen! Was soll dabei rauskommen?

    z.B. (in vereinfachtem Kontext):

    static object Feuerzeug = new String("foo");
    static void disposeFeuerzeug() {
    Feuerzeug = null;
    System.gc(); // das würde er an sich schon machen
    }

    Jetzt beantworte man mir mal die eine Frage: warum, verdammt, ist Feuerzeug statisch? Sollte da jetzt von irgendwoher zugegriffen werden, wäre Feuerzeug nach disposeFeuerzeug() null? Unmöglich! Was, wenn der nächste kommt? NullPointer?

    Meines Wissens geht das aber sogar. Man könnte also disposeFeuerzeug() schreiben. Und Feuerzeug wäre wohl wirklich null. Aber wer will sowas?

    Kurz: was statisch ist, wird nach System.exit(0) automatisch entsorgt, und das ist gut so.

    Und ein Singleton ist nix weiteres als eine statische Referenz auf die eigene (instantiierte) Klasse. Nicht zu entsorgen.

    Cheers,

    Roger
    if you can't dazzle em with brillance, baffle em with bullshit

  13. #13
    Registrierter Benutzer Avatar von RogerJFX
    Registriert seit
    13.04.2005
    Beiträge
    35

    noch kürzer

    delete kann nur aufräumen, was mit new erzeugt wurde. Statisches Zeug wird nie mit new instanziert. Ergo kann man es nicht aufräumen.

    Das ist in C++ also nicht anders.

    Nochmal cheers.
    if you can't dazzle em with brillance, baffle em with bullshit

  14. #14
    Registrierter Benutzer
    Registriert seit
    17.09.2001
    Beiträge
    1.182

    Hmm???

    Also wenn ich so ein Ding schreibe, verlasse ich doch wohl wissentlich alle OOP-Gefilde.

    Oder kürzer: was statisch ist, SOLL doch wohl die ganze Zeit im Speicher hängen. Und das will ich ja auch nicht anders in diesem Moment.
    Nein!
    Was statisch ist, gehört zur Klasse selbst und nicht zum Object - wird die KLasse entladen verschwinden logischerweise auch die Objekte auf die die statischen Referenzen zeigen wieder.

    So gesehen ists auch nicht Objektorientiert, weils ja nicht zum Objekt selbst gehört.

    Ein Singleton ist der Versuch, Sachen die sich nicht besonders gut mit OOP realisiseren lassen, um einen OOP-Wrapper zu packen, um somit OOP-konformer zu werden.
    Geändert von Lin728 (21-08-2017 um 15:21 Uhr)

  15. #15
    Registrierter Benutzer Avatar von RogerJFX
    Registriert seit
    13.04.2005
    Beiträge
    35

    ???

    In dem Moment, in dem etwas statisch ist, klar, gehört es zur Klasse (brav, brav!), aber die Klasse ist dann nur noch eine Art Namespace.

    Habe ich jetzt was übersehen, oder einfach nicht kapiert, worum es geht?
    if you can't dazzle em with brillance, baffle em with bullshit

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •