Fragliche Funktionsweise des GC

[reibi]

Hallo zusammen, ich habe eine Frage in Bezug auf den Garbage-Collector. In diesem Fall bin ich mir nicht mehr so richtig sicher wie er in meinem speziellen Fall funktioniert. Ich habe 2 Experten gefragt, welche mir dazu unterschiedliche Meinungen hatten. Beide sind wie gesagt Experten was es für mich nicht einfacher macht.

Also es wäre schön wenn möglichst viele Leute ihren Senf dazugeben würden. Danke im Voraus ;-)

Mein Kleines Beispiel besteht aus 2 Klassen:

public class Logger {
	private static String myString;

	public Logger(String str) {
		myString=str;
	} // end Logger()

	public static String getStr() {
		return myString;
	} // end getStr()
} // end Logger

und

public class Main {
	public static void main(String[] arschparade) {
		new Logger("Hallo2");
		//Ist das Zufall oder kommt hier irgendwann noch mal der GC vorbei
		System.out.println(Logger.getStr());
	} // end main()
} // end Main

Die erste Klasse heisst nur aus Zufall Logger, weil sich darin z.B. auch ein LoggerOBJ befinden könnte. Der Einfachheit halber habe ich darin einfach einen kleinen String abgespeichert.

Die zweite Klasse namens Main soll das Hauptprogramm darstellen.


Zur Klasse Logger:
Hier ist dabei zu achten, dass die einzige Membervariable statisch ist. Das würde bedeuten sie würde bei jedem Constructoraufruf überschrieben und existiert für meinetwegen 10 Objekte nur ein mal.
Des weiteren gibts einen Constructor(natürlich dynamisch)
und ... eine statische Methode, welche mein OBJ zurückliefert und später folgendermassen aufgerufen werden kann: Logger.getStr()


Zur Klasse Main:
Dieses Einfache Beispiel ist ja selbsterklärend!
ABER: Stellt euch einfach vor das Programm ist SehrSehrSehr-Gross und besteht aus; sagen wir 1000Klassen, welche die verschiedensten Teilaufgaben übernehnen.
UND: zwischen den beiden gezeigten Aufrufen liegt ein halbes Jahr


Jetzt kommts:Ist sichergestellt, dass der GC meine variable "myString" am Leben erhällt?

(viele Antworten unterschiedlichster Personen erwünscht)

vielen Dank fürs lange lesen und beantworten ;-)

 

[Wildcard]

-Eine statische Variable ist an das Klassen-Objekt gebunden, bleibt also so lange im Speicher wie das Klassen Objekt vorhanden ist.
-Eine Klasse wird so lange nicht entladen wie ihr Classloader erreichbar ist.
-Ein Standard-Java Classloader ist immer erreichbar

-> Das static field bleibt erhalten wenn du nicht mutwillig einen eigenen Classloader verwendest und diesen wegwirfst

Wenn das allerdings keine hypotetische Frage ist bleibt mir nur übrig dich wegen sehr schlechtem Code zu beglückwünschen, denn mit sauberem Stil hat das so gar nichts mehr zu tun.

 

[AlArenal]

Wer ist ein Exüperte? Der Einäugige unter den Blinden?

 

[Wildcard]

Wer ist ein Exüperte?

Das ist keine Person, sondern ein Rechtschreibfehler :lol:

 

[merlin2]

Auf welchen Exüperten bezieht er sich wohl? ???:L

 

[AlArenal]

Alder, kennsu nisch Exüperte?

 

[reibi]

Danke wildcard ;-)

Aber ganz hab ichs noch nich geschnallt, geht aber in die richtige Richtung.

Also: Ich schreib natürlich sauberen Code! Das hier soll nur ne eventuelle Möglichkeit sein bei einem großen Programm(mit ca. 1000 speziellen Methoden) einen Logger zu benutzen(mitZuSchleifen), welchen ich nicht für 1000Methoden extra als Parameter mitgeben will. Diesen Logger würde ich dann praktisch mit ner statischen Methode jeweils abhohlen.

Das mit dem ClassLoader hab ich nicht verstanden:
Also ich weiss natürlich was ein Classloader ist! Wenn ich zB meinen DatenbankTreiber dynamisch laden will...und wie dieses funktioniert weiss ich auch.

NUR: Weiss ich nicht was das mit meiner Klasse zu tun hat.

Dort rufe ich explizit gar kein Classloader auf, ist auch nicht geplant.
Meist Du vielleicht dass sowas im Hintergrund passiert?

Vielen Dank für erklären ;-)

 

[Wildcard]

Dort rufe ich explizit gar kein Classloader auf, ist auch nicht geplant.
Meist Du vielleicht dass sowas im Hintergrund passiert?

Das habe ich auch nicht vermutet. Ich weise dich nur darauf hin, dass die Möglichkeit besteht ein statisches Feld zu entladen wenn man den zum Laden der Klasse verwendeten Classloader wegwirft.

 

[bygones]

Also: Ich schreib natürlich sauberen Code! Das hier soll nur ne eventuelle Möglichkeit sein bei einem großen Programm(mit ca. 1000 speziellen Methoden) einen Logger zu benutzen(mitZuSchleifen), welchen ich nicht für 1000Methoden extra als Parameter mitgeben will. Diesen Logger würde ich dann praktisch mit ner statischen Methode jeweils abhohlen.

nunja... so ist das aber nicht sauber.. du mixt hier statische sachen mit instanzsachen... eine statische variable im konstruktor zu setzen ist nicht sinnvoll....

new Logger("ersterString");
// .. dein programm loggt schoen usw
new Logger("zweiterString");
//.. ups auf einmal hat sich was veraendert

ich hoff du siehst die problematik....

 

[SnooP]

Nein - wenn du keinen zweiten dir heranholst oder einen eigenen herzauberst, dann ist alles kein Problem...

Wenn man mehrere ClassLoader verwendet, dann könnten zwei Versionen einer statischen Variable existieren.

Aber keine Panik - läuft schonn *g*

P.S. nichtsdestoweniger kann ich mich meinen Vorrednern natürlich nur anschließen

 

[reibi]

Hallo Ihr beiden letzten Vorredner ;-)

1.) Das Beispiel war lediglich ein Beispiel, welches verdeutlichen sollte, dass erstmal im Hintergrund was erstellt wird. Das hätte ich natürlich auch mit ner Statischen Methode anstatt eines Constructors machen können. Nur war ich mir bei der statischen methode nicht sicher ob er das OBJ aufheben tut.

Offensichtlich schon.

2.) Das ich keine Referenzvariable abgehoben habe:

new Logger("ersterString");

sollte verdeutlichen, dass es für den GC aus dynamischer Sicht keinen Grund gäbe dieses OBJ aufzuheben, weill es ja ins Nirvana geschrieben wurde.

und 3.) Hatte das Hauptprogramm mit Beispielcharakter ja nur 2 zeilen, da kann man ja (fast) keinen schlechten Programmierstiel dran festmachen.

ABER: hätte ich solche UNWIRKLICHEN Zeilen gesehen, hätte ich auch gesagt, dass das schlechter Code ist ;-)

Danke an alle :roll: