OutOfMemoryError: Java heap space

[Alex_winf01]

Hallo liebe Forengemeinde,

ich habe ein kleines Programm, das eine Verbindung zur Datenbank H2 Database herstellt (per JDBC). Nun bekomme ich folgende Fehlermeldung:

Fehler beim Daten auslesen org.h2.jdbc.JdbcSQLException: Allgemeiner Fehler: java.OutOfMemoryError
General error: java.lang.OutOfMemoryError: Java heap space [HY000-64]
at org.h2.messsage.Message.getSQLException(Mexxage.java:89)
at org.h2.message.Message.convert(Message.java:174)
at org.h2.command.Command.executeQueryLocal(Command.java:74)
at org.h2.server.TcpServerThread.process(TcpServerThread.java:227)
at org.h2.server.TcpServerThread.run(TcpServerThread.java:103)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.OutOfMemoryError: Java heap space

Und in meinem DOS-Fenster des Servers für die H2-Datenbank steht noch:

Exception in thread "H2 File Lock Watchdog c:\Programme\H2\bin\test.lock.dba.lang.OutOfMemoryError: Java heap space
Exception in thread "H2 TCP Server (tcp://localhost:9092) thread" java.lang.OutOfMemoryError: Java heap spache

In der bat-Datei, wo ich meine Anwendung starte sieht wie folgt aus:

java -cp -Xmx1024m -jar MeinProgramm.jar
pause

Woran kann das liegen? Das Programm lief über 1 Jahr problemlos. Derzeit greifen allerdings sehr viele Anwender gleichzeitig drauf zu und fügen Datensätze ein, löschen diese und bearbeiten diese auch.

 

[Wildcard]

Dann sind 1024 MiB wohl nicht mehr genug

 

[marcoK]

Ich würde mal von 1024 auf 1536 mb hochgehen!

 

[maki]

EIn Profiler kann helfen, Memoryleaks zu finden.

 

[Alex_winf01]

Meine Applikation läuft wie folgt ab:

Die GUI bildet einen Fragebogen mit vielen hunderten Fragen und Eigenschaften. Die Anwender bearbeiten diesen Fragebogen und schreiben diese in die Datenbank. Ich weiss, dass ich sehr viele Variablen benutze (lokal). Diese Variablen sind aber notwendig für die Realisierung. Die einzelnen Statements schließe ich nach der Durchführung des SQL-Befehls.

Derzeit arbeiten sehr viele Anwender mit der Applikation und lassen die Applikation auch laufen, wenn sie nicht am Rechner sitzen (für 1 oder 2 Stunden). Selbst bei 2048m läuft es irgendwann über. Das passiert zu unterschiedlichen Zeiten. Das kann mal nach 30 Minuten der Fall sein oder auch erst nach 3 Stunden. Jeder Anwender fügt einen Datensatz ein (per insert) oder verändert einen (per update). Kann das an der Anzahl der Anwender liegen? Schließlich lief das Programm 1 Jahr ohne diesen Fehler?

 

[maki]

Ein Profiler ist besser als Vermutungen

Einfach mal im Profiler durchlaufen lassen, dann weisst du schon wo dein Speicher bleibt.

Dafür reicht übrigens schon VisualVM (ab Java 6).

 

[Alex_winf01]

@ maki

Folgender Code-Teil scheint mir Problematisch, da ich in einer while-Schleife viele Objekte erzeuge (je mehr Anwender mit dem Programm arbeiten, desto mehr Objekte schwirren natürlich im Speicher rum):

while(result_nachname.next()
{
    Kunde_nachname anzeige_nachname_JList;
    anzeige_nachname_JList = new Kunde_nachname(result_nachname.getString("kunde_nachname"), 
    result_nachname.getString("kunde_vorname"), result_nachname.getString("kundennummer"));
   defaultlistmodel.addElement(anzeige_nachname_JList);
}

Wie kann ich den Code verbessern?

PS: Bitte keine Diskussion: "Wie scheisse programmierst Du denn?? Ich bin noch im Lernprozess!!! Ich denke, dass ist auch Zweck dieses Forums - Erfahrungsaustausch. Jeder hat mal angefangen.

 

[maki]

Folgender Code-Teil scheint mir Problematisch, da ich in einer while-Schleife viele Objekte erzeuge (je mehr Anwender mit dem Programm arbeiten, desto mehr Objekte schwirren natürlich im Speicher rum):

Hat dir das der Profiler "gesagt" oder ist das deine Vermutung?
In letzterem Falle solltest du wirklich einen Profiler nutzen, Vermutungen sind meist falsch wenn es um Flaschenhälse geht.

 

[faetzminator]

PS: Bitte keine Diskussion: "Wie scheisse programmierst Du denn?? Ich bin noch im Lernprozess!!! Ich denke, dass ist auch Zweck dieses Forums - Erfahrungsaustausch. Jeder hat mal angefangen.

Nö, das kann man auch konstruktiv machen, z.B. so:
Du solltest dich an die Standards halten, u.a. bei Namen:
- IchBinEineKlasse
- ichBinEineMethode()
- ichBinEineVariable
- ICH_BIN_EINE_KONSTANTE
- ichbineinpackage

 

[Alex_winf01]

@ maki

Die while-Schleife soll eine JList mit Daten füllen und das permanent. Da ich dort sehr viele Objekte erzeuge, ist genau dass das Problem. Das zeigt ja auch schon die Fehlermeldung des Kunden:

Fehler beim Daten auslesen org.h2.jdbc.JdbcSQLException: Allgemeiner Fehler: java.OutOfMemoryError[code=Java]

Wenn ich dieses Problem mit dem Profiler nachbilde, bestätigt sich genau diese Problematik: Je mehr Leute die Anwendung starten und nix weiter machen, als sich die JList anzuschauen, dann kommt nach einer gewissen Zeit eine Speicherspitze, an der sehr viel Speicher benötigt wird. Anschließend fällt diese Speicherspitze wieder ab und steigt dann wieder und fällt dann sofort wieder. Das geht solange, bis die VM komplett aussteigt.

 

[Xerxis13]

Korrigiere mich, wenn ich falsch liege, aber anscheinend weißt du doch, wo das Problem liegt.
Es liegt weniger am System, als viel mehr am Programmkonzept.

So wie du deine Erkenntnisse beschreibst, ist es ein einfacher Dreisatz (x User = X MB Memory; ? User = OOM).

Kannst du im Profiler nachvollziehen, das jeder User X-MB verbraucht?
Kannst du also sagen, 20 Benutzer brauchen 20x so viel Speicher wie 1 Benutzer?
Da kannst du dir ja selber ausrechnen, wo deine physikalischen Grenzen sind.
JavaHeapSize / MemoryUsagePerUser = MaxUser.

Oder verstehe ich dich gerade falsch?

Zum Profilen habe ich immer folgende Tools benutzt:
jConsole
VisualGC

Auch interessant, aber leider kommerziel:
jProfiler. Gibt da ne 14 Tage uneingeschränkte Testversion.

Willst du zum Zeitpunkt des OOM das Speicherabbild sehen, empfiehlt es sich, die VM mit folgendem Parameter zu starten:
-XX:+HeapDumpOnOutOfMemoryError
Damit schreibt die VM dir bei einer OOM Exception das gesamte Speicherabbild der VM auf die Platte. Wird dann halt ein 1GB großes File.

Dieses kannst du dir dann wiederum mit dem Memory Analyser anschauen(Eclipse Memory Analyzer Open Source Project).

 

[Alex_winf01]

@ all

ich habe heute mal einen Belastungstest mit meinem Programm gemacht (mit Hilfe des Profiler). Das Problem liegt bereits beim Einloggen an die Datenbank. Zu diesem Zeitpunkt muss ich einige Daten zur Verfügung stellen. Das ist Programmiertechnisch auch kein Problem, da ich innerhalb der while-Schleife keine Objekte erzeuge. Je mehr Anwender sich anmelden und das Programm laufen lassen, treten immer wieder Spitzen im Heap Space auf. Je mehr sich anmelden, um so höher werden diese Spitzen. Ich hab schon nachgeschaut, da kann ich nix mehr optimieren an dieser Stelle. Es scheint so, je mehr Fenster offen sind, desto höher werden die Spitzen.

Man muss dazu sagen, der Kunde hat ein Jar-File (meine Anwendung) und lässt alle Anwender dieses eine Jar-File über eine bat-Datei öffnen. Normalerweise kann die H2-Datenbank eine menge Anwender gleichzeitig vertragen.