java.lang.OutOfMemoryError in Schleifenkonstrukt

[Johannes7146]

das ganze ist eine rein firmen interne Anwendung. Bei uns wird nur Windows eingesetzt. Daher halb so wild, aber danke für den Heinweiß.

Die Counter setze ich zwar hoch, dass ist richtig. Aber ich manipuliere nicht die durchläufe der aktuellen schleifen (Glaube das ist auch ein absolutes No-Go!)
Das ganze ist nur für den Fall das das ganze von außen angehalten wird. Daraufhin werden die Counter (in bestimmten fällen) einmalig geändert und zwischengespeichert.

Ich habe mir gerade die testversion von JProfiler 5.5.2 geladen und lasse die Anwendung damit laufen.

 

[Johannes7146]

So wie das ganze ausschaut schaukelt sich da irgendetwas hoch.
Die Sprünge (abwärts) sind denke ich der GC.

Die 3 ersten Zeilen aus dem 1. Bild sind für

• String
• Object[]
• char[]

Aber die anwendung ist bei 256 mb damals immer nach ca 20 bis 25min abgeschmiert.
Nun läuft sie seit ca 66min mit 128mb.

Liegt das daran das mit der überwachung von JProfiler das ganze langsamer läuft?

Die Anwendung wird mit der abarbeitung noch einige Stunden (oder Tage) brauchen. Mal schauen wie weit er kommt.

Edit: Es kann natürlich auch sein, dass die Daten die pro Maschine kommen nach und nach mehr werden. Dieses Verhalten sollte sich aber irgendwann eingependelt haben.
Das liegt daran, dass das ganze chonologisch abgearbeitet wird und die ersten Maschinen noch nicht ganz so viele Daten liefern.
naja.... abwarten

 

[zeja]

Schau mal auf die Hotspots. Daran sieht man eigentlich immer am schnellsten was nun ganz viel Speicher verbraucht.

Je nachdem wie du den Profiler beim Startup konfigurierst, braucht er natürlich unterschiedlich lang. Das wird in der Konfiguration aber auch angezeigt. In deinem Fall brauchst du eigentlich erstmal nur das Memory-Profiling und da auch nur das von eigenen Klassen und nicht von den Java-Klassen. Den Rest kannst du ausmachen. Dann dauerts nicht ganz so viel länger.

 

[Johannes7146]

In deinem Fall brauchst du eigentlich erstmal nur das Memory-Profiling und da auch nur das von eigenen Klassen und nicht von den Java-Klassen. Den Rest kannst du ausmachen. Dann dauerts nicht ganz so viel länger.

Was wenn ich dann zb irgendwo eine Liste mit Strings hab und die immer größer wird?
Das würde mir dann doch entgehen oder nicht?

 

[Johannes7146]

So sieht das ganze nun nach 140min aus. Ich denke in den nächsten 30min wirds gleich nochmals zum Überlauf kommen.

Wenn ich das Tool richtig verstanden hab, liegt es also daran das sich zu viele char[]. strings und Object[] ansammeln. ricihtg?

 

[Johannes7146]

Mhhh die Software bietet die Möglichkeit den GC von außerhalb aufzurufen. Hab das grad mal getestet....Dabei ist der genutze Speicher von knapp 100mb auf ca 20mb abgesunken.

Kann es sein das aus irgendwelchen Gründen der GC nicht automatisch aufgerufen wird?
In dem Fall könnte ich ihn manuell einmap par Schleifendurchlauf aufrufen.

Pro / kontra?

 

[Johannes7146]

Vielen Dank zeja für den Tipp mit JProfiler.
Ich habe meinen Code nochmals durchgescahut und es gab eigentlich nur eine Stelle wo char[] Strings und Object[] gesammelt werden.
Beim export werden Daten aus der DB geholt und in char[] und Object[] gepackt.

if (messungstyp.equalsIgnoreCase(Messungstyp.ALARMMELDUNG)) {

                CSVAlarmExporter export = new CSVAlarmExporter(maschine,
                                                               vonMitStdAngabe.getTime(),
                                                               bismitStdAngabe.getTime(),
                                                               save_path,
                                                               "Alarm-CSV.csv",
                                                               loc);

                /* CVS-File erstellen */
                log
                        .info("ArchivierenThread_archiviere-->Erstelle CSV für: "
                                + maschine.getSeriennummer() + " " + messungstyp + " "
                                + ernteTag);

                export.createCSVExport();
                export = null;
            } else {

                CSVExportNew export = new CSVExportNew(collection,
                                                       vonMitStdAngabe.getTime(),
                                                       bismitStdAngabe.getTime(),
                                                       messungstyp,
                                                       loc,
                                                       true,
                                                       save_path);

                /* CVS-File erstellen */
                log
                        .info("ArchivierenThread_archiviere-->Erstelle CSV für: "
                                + maschine.getSeriennummer() + " " + messungstyp + " "
                                + ernteTag);
                export.buildCSVFile();
                export = null;
            }
            HibernateSessionFactory.clearSession();
            System.gc();
          //ENDE schleife über Locales
        }

habe nach beiden exporten den export auf Null gesetzt. Danach jeweils den GC aufgerufen.
Ergebniss: Die Anwendung läuft nun durch (seit gestern) und nimmt nicht mehr als 50mb des Speichers der Vm in Anspruch.