OOP Mehrere Instanzen auf ein Feld

[qdoi123]

Was passiert wenn ich ein Objekt erstelle zB.

Test t = new Test("Test1");

aber im nachhinein soetwas mache

//Code
t = new Test("Test2");
//Code
t = new Test("Test3");

Was läuft da im hintergrund ab? Ist das speicher und laufzeittechnisch gesehen eine Katastrophe oder ist das nicht weiter schlimm? Immerhin ruft der new-Operator, soweit ich weiß, nur den Konstruktur der Klasse auf. In diesem Fall würde ja nur ein String überschrieben werden.

 

[Thallius]

Es wäre einfach sinnfrei da die erste Instanz beim erzeugen der zweitn einfach wieder freigegeben wird.

Es ist genau das gleiche als würdest du

int a=3;
a=4;
a=5;

Schreiben

Claus

 

[qdoi123]

Ob sinnvoll ist oder nicht war ja nicht die Frage

Also sobald ich eine zweite Instanz erzeuge wird die erste freigegeben und der Speicher ist frei?

 

[Thallius]

Theoretisch ja, praktisch ist es natürlich etwas komplexer weil letztendlich der Garbage Collector bestimmt wann der Speicher wirklich wieder frei gegeben wird.

Claus

 

[stg]

Also sobald ich eine zweite Instanz erzeuge wird die erste freigegeben und der Speicher ist frei?

Nur, wenn sonst von nirgendwo dein Objekt referenziert wird (und auch dann nur, wenn, wie Thallius ja schon gesagt hat, auch wirklich der GC tätig geworden ist...)

Betrachten wir dazu zum Beispiel folgendes (durchaus fragwürdiges) Konstrukt:

class Test {
    private static final List<Test> list = new LinkedList<>();
    public Test() {
       Test.list.add(this);
    }
}

Dann hättest du bei deinem "Programm" von oben am Ende immer noch alle Objekte im Speicher, denn die interne private List der Klasse Test, referenziert alle Objekte, die jemals erstellt worden sind.

 

[Zet]

Spoiler: Hatte wohl das Fenster etwas lange offen :)

[Mich würde auch interessieren was da genau passiert.
Wenn das Erste Objekt T erstellt wird, wird speicher reserviert.
Nun sagt das Programm, ich möchte ein Objekt mit dem selben Namen (?) erstellen.
Merkt das Programm jetzt:
1.) oh der Speicher ist besetzt -> Ich ruf mal schnell den GarbageCollector und erstelle danach das Neue Objekt (würde ja vermutlich ordenlich Zeit benötigen?)
2.) Ich erstelle erstmal das Objekt irgendwo an einer Freien Stelle, und rufe garkeinen Garbage-Collector, da er ja eh irgendwann die tote Referenz bzw. das Objekt aufräumt??
3.) Ich überschreibe den Speicherbereich (das ist wohl nicht möglich?)
4.) Es existieren weiterhin beide Objekte, jedoch wird nur das neue Referenziert.
5.)... ?

Wie man sieht, ich habe eigentlich keine Ahnung was da genau passiert.
Kann das jemand eventuell genauer erläutern?


Grüße,
zet

 

[bartzer]

Hallo,

Bin selber noch Anfänger und Zet seine Frage würde mich auch interessieren.
ich denke es ist 4. bzw. 2. (siehe Zet´s post) weil:

Ein Objekt wird erstellt -> t zeigt auf den Referenzwert vom Objekt

Ein weiteres Objekt (mit neuem Referenzwert) wird erstellt -> t zeigt jetzt auf den Referenzwert deszweiten Objektes

GarbageCollector "dreht seine Runde" und merkt, dass das erste Objekt nicht mehr verwendbar ist -> wird entfernt


Also: erst existieren noch beide Objekte im Heap-Speicher, nachdem der GC dann durch ist nur noch das zweite
Kann das jemand bestätigen bzw. korrigieren?

Grüße

 

[franky27]

Ja 2 und 4. Das jetzt unreferenzierte Objekt fliegt immer noch auf dem Heap rum und wird irgendwann vom GC gefressen, sobald dieser es für nötig hält. Darauf hat man keinen Einfluss.

 

[qdoi123]

Das ist dann aber ziemlich sch...ade wenn man selbst keinen Einfluss nehmen kann auf das entfernen eines freien Objekts. Also ist man komplett abhänging vom gc

 

[Thallius]

Willkommen bei java. Programmier C und da geht es.

Gruß

Claus

 

[franky27]

Es gibt zwar die Methode gc() unter System mit der der GC "aufgerufen" wird. In Anführugszeichen deswegen, weil damit eher darum gebeten wird den GC aufzurufen. Es gibt aber keine Garantie dafür ob und wann die VM dies tut..

 

[Dompteur]

Das ist dann aber ziemlich sch...ade wenn man selbst keinen Einfluss nehmen kann auf das entfernen eines freien Objekts. Also ist man komplett abhänging vom gc

Man kann es auch anders sehen: Du brauchst dich nicht darum zu kümmern.
Dafür bleibt dir mehr Zeit, dich um die Lösung des eigentlichen Problems zu kümmern.

 

[ARadauer]

Das ist dann aber ziemlich sch...ade wenn man selbst keinen Einfluss nehmen kann auf das entfernen eines freien Objekts. Also ist man komplett abhänging vom gc

In der Realität ist es leider doch etwas komplexer. Da gibt es nicht den "einen" heap und GC geht da nicht einfach so drüber. Das ist ein hochkomplexes thema mit verschiedensten Algorithmen, Optimierungen und Einstellungen. Sei froh dass du dich um solche dinge in der Regel nicht kümmern musst.

Das sind mal nur die Basics.. Java Garbage Collection Basics

 

[stg]

Das ist dann aber ziemlich sch...ade wenn man selbst keinen Einfluss nehmen kann auf das entfernen eines freien Objekts. Also ist man komplett abhänging vom gc

Um es einfach mal auf den Punkt zu bringen: Sofern man wirklich hocheffiziente Speicherverwaltung betreiben muss ist Java als Programmiersprache einfach die falsche Wahl!
Bei "üblichen" Anwendungen ist das aber in der Regel sche**egal, das läuft alles so rasend schnell und es ist so viel Speicher verfügbar, dass man davon gar nix mitbekommt. Hakts beim Program irgendwo, so sind die Gründe eher an einer miesen Implementierung festzumachen, als an der Speicherverwaltung von Java. Sei froh, dass du dich damit nicht selbst herumschlagen musst, denn das ist ein wirklich hochkomplexes Thema...

Für anspruchsvollere Anwendungsfälle, wie zum Beispiel das Lösen partieller DGLn, bei denen zu lösende Gleichungssystem mit mehreren hundert tausend Gleichungen und Unbekannten das normalste der Welt sind, kannst du Java komplett vergessen. Erst recht, wenn es daran geht, solche Solver zu parallelisieren.
Oder auch, wenn du System-nah oder gar Hardware-nah programmieren musst. Da sind deine Möglicheiten mit Java ebenso stark eingeschränkt.

Für normale Büroanwendungen o.Ä. muss man solche Überlegungen aber gar nicht erst anstellen. Da überwiegen in der Regel dann doch die Vorteile, die Java bietet.