Stack...

[izoards]

Hallo,

Eine Frage, wenn ich z.B. in einer Endlosschleife, jeweils immer wieder neue Variablen definiere, gibt das irgendwann ein Problem?
Also wird der Stack damit belastet und kommt es dann irgendwann zur Laufzeit zu Problemen?
Danke für die Hilfe

 

[KonradN]

Hallo,

Eine Frage, wenn ich z.B. in einer Endlosschleife, jeweils immer wieder neue Variablen definiere, gibt das irgendwann ein Problem?
Also wird der Stack damit belastet und kommt es dann irgendwann zur Laufzeit zu Problemen?
Danke für die Hilfe

Also eine Variable in einer Endlosschleife zu deklarieren führt zu keinen Problemen. Eine Endlosschleife arbeitet auch nicht mit dem Stack. Die lokalen Variablen, die Du in der Endlosschleife nutzt, sind ja in einer Methode und zu dieser gehören diese.

Wenn Du mit definieren eine Zuweisung meinst, dann kann es prinzipiell problematisch sein, so Du hier immer neuen Speicher belegst (z.B. durch die Erzeugung von neuen Instanzen). So diese noch referenziert werden (z.B. in einer Liste), dann ist irgendwann der Speicher voll. Wenn Du die nicht mehr Referenzierst, dann muss der Speicher aufgeräumt werden - das macht der GC und das kann in bestimmten Situationen durchaus problematisch sein.

 

[izoards]

Hallo Konrad, herzlichen Dank für die rasche und immer sehr nette und kompetente Rückmeldung.
Mit definieren meine ich z.B. das:

int answer = communication.waitForConfirmation("commandXY", timeout * 1000);

oder auch das:

BufferedReader bin = new BufferedReader(
                                new InputStreamReader(none.openStream()));

Edit: Gibt es eine Möglichkeit das zu beobachten? Also ob der Stack dauernd wächst? Kann das mittels Task Manager Memory Auslastung gemacht werden?

 

[Jw456]

Das erste sollte keine Probleme machen. Ist ja statisch.

Das zweite ist dynamisch (new) könnte irgendwann, wenn nicht freigeben wird, den Speicher füllen

ps wird wohl nicht passiren da BufferedReader das sicher begrenzen wird.

 

[KonradN]

Der erste Fall ist einfach: Du hast eine "value type" Variable - da wird also nur ein Wert gespeichert. Es wird also eine Methode aufgerufen mit allem drum und dran: Auf den Stack kommt Platz für die Rückgabe, die Rücksprungadresse, die beiden parameter, die lokalen Variablen der Methode. Dann läuft die Methode ab und am Ende wird alles vom Stack genommen und mit dem letzten Schritt die Rückgabe vom Stack in der Variablen gespeichert. Das ist also absolut neutral.

Der Zweite Fall ist kritischer. Hier erzeugst Du neue Instanzen (BufferedReader, InputStreamReader und ein InputStream, der von openStream zurück kommt). So Du diese nur in der Variablen bin referenzierst, ist es egal - der GC kann das sehr gut erkennen und verarbeiten. (Es gibt diverse Algorithmen für GCs daher gehe ich da nicht weiter drauf ein - aber klar ist: Das ist ein typischer Fall, wie es ihn sehr oft gibt. Das muss also ein GC gut beherrschen!)
Problematisch ist hier aber, dass auch Ressourcen geöffnet werden, die ggf. geschlossen werden sollten. Da wäre ein try-with-resources der richtige Ansatz. (Oder halt sicher stellen, dass immer ein close() aufgerufen wird!)

 

[izoards]

Problematisch ist hier aber, dass auch Ressourcen geöffnet werden, die ggf. geschlossen werden sollten. Da wäre ein try-with-resources der richtige Ansatz. (Oder halt sicher stellen, dass immer ein close() aufgerufen wird!)

Macht es denn Sinn, in einer Endlosschleife, jeweils immer wieder zu schliessen close()? Um dann bald wieder zu öffnen... (ca. alle sekunden)
Oder wäre es besser, wenn ich kein (new) in der Schleife habe, und dann erst schliesse, wenn die Schleife doch mal verlassen wird. (Beim schliessen des Programmes)

 

[KonradN]

Macht es denn Sinn, in einer Endlosschleife, jeweils immer wieder zu schliessen close()? Um dann bald wieder zu öffnen... (ca. alle sekunden)
Oder wäre es besser, wenn ich kein (new) in der Schleife habe, und dann erst schliesse, wenn die Schleife doch mal verlassen wird. (Beim schliessen des Programmes)

Durch das new hast du ein ständiges Öffnen. Es sind immer neue Reader. Was wir nicht sehen, ist der Stream - wenn dies immer der gleiche Stream ist und nicht immer ein neu geöffneter, dann hast Du ggf. ein Problem. Denn wenn der Reader geschlossen wird, dann wird auch der zugrunde liegende Stream geschlossen. So ein Pattern, dass ein Stream immer wieder nach außen gegeben wird, ist somit zumindest sehr fehleranfällig.

Und man muss auch aufpassen: Du hast einen BufferedReader - der kann also auch etwas zwischenspeichern. Wenn Du aus einem Stream mehrfach etwas lesen willst, dann bedeutet dies, dass Daten verloren gehen könnten. Fiktives Beispiel (Das ist so nicht!): Angenommen der BufferedReader liest immer 2 Zeilen auf einmal - auch wenn Du nur 1 Zeile brauchst. Das sieht dann so aus:
Stream hat etwas wie
a
b
c
d

Unser BufferedReader würde beim Lesen der ersten Zeile gleich a und b lesen und das a weiter geben. Beim lesen der nächsten Zeile hätte der BufferedReader diese schon und könnte das b zurück geben.

Nun machen wir die Schleife immer mit neuen BufferedReadern (von unserem spezial BufferedReader!)

Erster Schleifendurchlauf: Stream hat noch a-d, erster BufferedReader soll eine Zeile lesen, liest a und b. Gibt b zurück.
Nächster Schleifendurchlauf: Stream hat nur noch c-d, erster BufferedReader hätte im Buffer noch das b, wir machen aber ein neuen BufferedReader und lesen damit dann eine Zeile: Er liest c und d und gibt c zurück.
==> Es gehen also Daten verloren!

Daher ist die typische Vorgehensweise immer:

• Ich erzeuge den Reader
• Dann gehe ich in der Schleife diesen Reader durch, bis ich alles gelesen habe
• dann am Ende schließe ich den Reader

Aber es hängt immer an den Anforderungen - wenn ich eine Datei mit ganz vielen Zeilen habe und ich will diese immer wieder durchgehen: Dann habe ich natürlich eine Schleife, in der die Datei geöffnet wird, der Inhalt der Datei ausgewertet und dann die Datei geschlossen wird. Und dann wird das immer wieder erneut gemacht. Sowas ist denkbar. Aber das ist halt kein typischer Anwendungsfall sondern ein sehr spezieller ...

Aber kommen wir zurück zu Deinem Anwendungsfall: Was macht denn die Methode openStream? Vom Namen her, wird ja ein Stream geöffnet. Es kommt also immer ein neues Stream zurück. Das wäre also so durchaus ok - Beispiel wäre: In einer Schleife gehst Du alle Dateien eines Verzeichnisses durch und verarbeitest diese. Etwas in der Art.

 

[izoards]

Also der openStream macht eigentlich nur einen http - Befehl auf einem lokal laufenden Programm

Bspsw:

URL off = new URL("http://localhost:55555/command?setcolors=off");

 

[KonradN]

Das sieht dann doch vernünftig aus. Bei dem Code sehe ich so erst einmal kein Problem. Das try with resources sollte angewendet werden, aber auch ohne dürfte der Code problemlos so laufen - da wird dann der GC halt das Aufräumen erledigen (nicht schön aber das ist ja nicht das eigentliche Thema).

 

[izoards]

Herzlichen Dank 😊

 

[izoards]

Ich muss hier doch nochmals nachfragen...
Habe jetzt bin.close() jeweils noch hinzugefügt... (Um sicherer zu sein)

BufferedReader bin = new BufferedReader(
                                new InputStreamReader(none.openStream()));

Wenn ich das Programm jedoch laufen lasse und die Arbeitsspeicher Auslastung im Task Manager beobachte, steigt dieser langsam, aber stetig an.

Das ist doch ein Zeichen, dass irgendwas nicht sauber ist, richtig? 🤦‍♂️

 

[KonradN]

Das ist doch ein Zeichen, dass irgendwas nicht sauber ist, richtig? 🤦‍♂️

Nein, das muss es nicht bedeuten. Zum einen zeigt der Task Manager nur die Windows Sicht an und nicht die interne Java Sicht. Und wenn es genug freien Speicher gibt aus Sicht der JVM, dann gibt es auch keinen Druck, dass der GC irgendwas frei gibt.

Und dann ist auch wichtig:

• Der belegte Speicher muss ja nicht am BufferedReader liegen. Wir haben ja keinerlei Übersicht, was Du sonst noch so hast.
• Der manuelle close Aufruf ist nicht optimal. try-with-resources sollte verwendet werden wenn es möglich ist.

 

[izoards]

Also ist das ein normales verhalten, wenn man das nicht begrenzt?
Apropos begrenzen, kann das mittels Launch4J mit dem Max. Heap. begrenzt werden?
Gibt es da Probleme, wenn man das begrenzt? Ich meine einfach, dass es unschön ist, wenn mein Programm hier soviel Arbeitsspeicher belegt.

• Der belegte Speicher muss ja nicht am BufferedReader liegen. Wir haben ja keinerlei Übersicht, was Du sonst noch so hast.

Der Code ist zur Zeit noch nicht wirklich aufgeräumt / präsentierbar....
Aber dann denkst Du schon, dass der Code irgenwo noch unschönheiten hat, dass der Arbeitsspeicher kontinuierlich steigt?

• Der manuelle close Aufruf ist nicht optimal. try-with-resources sollte verwendet werden wenn es möglich ist.

Danke für den Hinweis, dann befasse ich mich mal noch mit "try-with-resources"

 

[KonradN]

Deine Fragen lassen sich pauschal nicht beantworten. Du weisst, was Dein Programm macht. Du kannst überschlagen, was da an Instanzen erzeugt wird und so. Damit kannst nur Du sagen, was da notwendig ist bzw. was Sinn macht.

Und wenn Du da nichts angibst, dann gelten die Default Werte, also beschränkt ist es so oder so. Die default Werte kannst Du mit einem Befehl wie
java -XX:+PrintFlagsFinal -version | findstr HeapSize
heraus finden. (Bei Linux / Mac statt findstr einfach grep verwenden).

 

[izoards]

Deine Fragen lassen sich pauschal nicht beantworten. Du weisst, was Dein Programm macht. Du kannst überschlagen, was da an Instanzen erzeugt wird und so. Damit kannst nur Du sagen, was da notwendig ist bzw. was Sinn macht.

Das Hauptprogramm startet einen Thread, welcher in einer Endlosschleife alle Sekunde dieselben Abfragen macht.
Im Hauptprogramm selbst, läuft noch ein Watchservice, welcher bei ankommen eines Files, den Thread stoppt. Das ansteigen des Arbeitsspeichers kann jedoch auf den Zusatzthread mit der Endlosschleife eingegrenzt werden bzw. auch dort, habe ich bereits viele Zeilen auskommentiert und kann den Grund für das ansteigen nicht finden... (Ist leider jedoch noch mit ziemlich verschachtelten if - statements programmiert)

IntelliJ meckert noch, dass ich in der Endlosschleife noch Thread.sleep() aufrufe...

Call to 'Thread.sleep()' in a loop, probably busy-waiting

Ansonsten sehe ich kein Grund für das Ansteigen des Arbeitsspeichers...

java -XX:+PrintFlagsFinal -version | findstr HeapSize

Das gibt bei mir für MaxHeapSize: 4'22'566'976kB, dann gibt das 4.22TB!?

Dann würde das Programm ohne Begrenzung soviel Speicherplatz einnehmen?

 

[KonradN]

Kann es sein, dass du das kB da selbst hinzu gefügt hast? Das dürfte einfach nur die Zahl sein und dan wären das Bytes … und da dort ja immer mit 1024 gerechnet wird sollten das 4GB als Maximum sein.

Und davon dürftest du sehr weit weg sein, so dass der GC vor allem idle ist (wäre jetzt meine Vermutung).

 

[izoards]

Ja das kB habe ich nach kurzem googeln hinzugefügt, 4GB macht mehr sinn..

Ja, bin anfänglich bei 60MB das Programm soll aber non stopp laufen, darum mache ich mir die Gedanken.. denke werde es eifach auf 100MB begrenzen, macht das Sinn?

 

[KonradN]

Ich würde Prozesse nicht zu sehr begrenzen. Aber du kannst mit so einem Limit testen, ob es weiter ansteigt oder ob der GC dem dann Einhalt gebietet.