Garbage Collection Frage

[tanechka]

Hallo,

brauche Hilfe die Antwort auf die Frage nachzuvollziehen:

class Beta{}
class Alpha{
  static Beta b1;
  Beta b2;
}

public class Tester{
 public static void main(String[] args){

  Beta b1 = new Beta(); Beta b2 = new Beta();
  Alpha a1 = new Alpha(); Alpha a2 = new Alpha();
  a1.b1=b1;
  a1.b2 = b1;
  a2.b2=b2;
  a1=null; b1=null; b2=null;

//do stuff        //line16
}
}

When line 16 is reached, how many objects will be eligble for g.c.?

A.0
B.1
C.2
D.3
E.4
D.5

Ich verstehehe so:
a1->a1.b1->b1 (a1, b1 ist null)
a1->a1.b2->b1 (a1,b1,b2 ist null)
a2->a2.b2->b2 (b2 ist null)
Also, wenn gefragt wird "will be eligible for g.c." heißt das die Objekte die zu Null gemacht wurden oder die die bleiben? Es bleibt also 1 Objekt: a1, die anderen a1,b1,b2 sind null.

 

[SlaterB]

> Also, wenn gefragt wird "will be eligible for g.c." heißt das die Objekte die zu Null gemacht wurden oder die die bleiben?

die, die nicht mehr greifbar sind, siehe auch (*)


> Es bleibt also 1 Objekt: a1, die anderen a1,b1,b2 sind null.

da ist schon ein sprachlicher Fehler, a1 hast du 2x aufgeführt, a2 gar nicht

(*) wichtig ist nicht nur, wie die ursprünglichen Variablen aussehen, sondern auch sonstige Referenzen im Programm

das Alpha-Objekt, welches ursprünglich in der Variablen a2 stand, bleibt dort die ganze Zeit, steht am wenigsten in Frage,
'a2' ist garantiert noch da,

in a2.b2 wurde das Beta-Objekt b2 abgelegt,
auch wenn b2 dann auf null gesetzt wird, ist diese Objekt in Zeile 16 noch bekannt, über a2.b2 verwendbar, zugreifbar, also ist auch 'b2' noch erhalten

so, die anderen beiden bitte selber überlegen

 

[hasso]

Der GC räumt in dem Fall gar nix weg, darf er gar nicht.

Im übrigen "eligible" bedeutet geeignet/annehmbar, d.h. die Frage ist, wenn in Zeile 16 der GC losläuft, was wird er wegräumen.

 

[SlaterB]

@hasso
meinst du damit irgendeine (technische) Spitzfindigkeit?
die Aufgabe ist offensichtlich, herauszufinden, welche der Objekt erzeugt wurden und nicht mehr erreichbar sind,
da gibt es mindestens eins, dafür garantiere ich

 

[Pippl]

Der GC räumt in dem Fall gar nix weg, darf er gar nicht.

Im übrigen "eligible" bedeutet geeignet/annehmbar, d.h. die Frage ist, wenn in Zeile 16 der GC losläuft, was wird er wegräumen.

Warum darf er 'a1' nicht wegräumen?

 

[freez]

die Aufgabe ist offensichtlich, herauszufinden, welche der Objekt erzeugt wurden und nicht mehr erreichbar sind,
da gibt es mindestens eins, dafür garantiere ich

Ich denke auch ... wenn ich jetzt GC wäre, würde ich nur ein Objekt entsorgen.

 

[hasso]

Es sind sogar zwei die abgeräumt werden, bin durcheinander gekommen mit den ganzen a1, a2, b1, b2 :toll:

 

[SlaterB]

Es sind sogar zwei die abgeräumt werden, bin durcheinander gekommen mit den ganzen a1, a2, b1, b2 :toll:

immer diese klaren Angaben ,
auch das muss ich korrigieren bevor was falsches steht, meiner Meinung nach nur eines,
steht ja auch schon in den anderen beiden Postings

 

[hasso]

Und wie kommst du noch an b1 nachdem du a1 und b1 null gesetzt hast ?

 

[SlaterB]

die statische Variable geht immer
so, nun haben wir auch das diskutiert

 

[freez]

Wir schaffen das noch, dass am Ende des Tages die richtige Lösung da steht, ohne dass der TO nachdenken muss

 

[hasso]

Dafür hab ich doppelt gedacht, das zählt auch

Hab das jetzt mal probiert weil mir irgendwie die Vorstellung dafür fehlt. B1 ist wirklich noch erreichbar, hätte ich gewusst das der Debugger statische Variablen nicht im Objekt anzeigt wären wir schneller fertig gewesen

 

[Spacerat]

Ich denke er wird genau nur 1 Objekt wegräumen: Und zwar a1.

b1 wird in Zeile 12 der statichen Variable b1 der Klasse Alpha zugewiesen und dürfte in Zeile 16 noch per Alpha.b1 erreichbar sein. In Eclipse ergeben solche Zuweisungen 'ne Warnung (object access on static member).

a2.b2 hat den Wert von b2 und da a2 selbst nicht null wird, ist b2 immer noch über a2.b2 erreichbar.

 

[SlaterB]

man kann sogar mit a1.b1 zugreifen, jedenfalls bei mir, empfehlenswert ist es sicher nicht

Eclipse meckert dann zwar 'Null pointer access: The variable a1 can only be null at this location' aber es kommt doch das Beta-Objekt raus..

 

[hasso]

Okay, da scheint meine IDE restriktiver. Bei a1.b1 kriege ich einen Fehler "a1.b1 cannot be referenced".

 

[Spacerat]

@SlaterB: Das ist Einstellungssache... Im Gegensatz zu Eclipses Einstellungen kann der Compiler die Klasse trotzdem erstellen und dabei den Access korregieren. Ich denke das tut er auch und zwar ohne das Eclipse davon was mitbekommt. Das Programm kann dann trotz Warnungen und sogar Fehlern problemlos ausgeführt werden. Aber dafür in Eclipse Einstellungen ändern, die an anderer Stelle hilfreich sein könnten? näääääh.