Ich arbeite an einem SAX Parser, der verschiedene Metadatenwerte aus einer riesigen Datenbank herausliest und ausgibt.
Die Datenbank ist in zahlreiche Pages eingeteilt, wobei ich immer den Access-Token für die neue Page aus der alten herauslesen muss, eine neue URL daraus formen muss und danach einen neuen Parse-Request ausgebe.
Nach 'Page 750' bekomme ich folgende Fehlermeldung:
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl.createChunk(DeferredDocumentImpl.java:1921)
at com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl.ensureCapacity(DeferredDocumentImpl.java:1828)
at com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl.createNode(DeferredDocumentImpl.java:1840)
at com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl.createDeferredTextNode(DeferredDocumentImpl.java:534)
at com.sun.org.apache.xerces.internal.parsers.AbstractDOMParser.characters(AbstractDOMParser.java:1189)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:464)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
Schau mal unter "Run Configurations", da gibt es ein Tab mit einem Eingabefeld für die "VM Parameters" (oder Aguments?) wo man das
-Xmx1000m
reinschreiben kann.
Schau mal unter "Run Configurations", da gibt es ein Tab mit einem Eingabefeld für die "VM Parameters" (oder Aguments?) wo man das
-Xmx1000m
reinschreiben kann.
Danke für den Vorschlag!
Ich hab's mal auf '-Xmx3000m' probiert mit meinem 4GB RAM MacBook Air. Hat aber nicht geholfen. Programm ist and der GLEICHEN Stelle abgestürzt.
Hui, ist das ein 64bit Java? Bei 32bit ist eigentlich bei ca. 1200m Schluss...
Ggf. mal einen Profiler laufen lassen - im JDK/bin Ordner sollte schon eine "jVisualVM.exe" rumliegen, mit der sollte man analysieren können, wo der Speicher flöten geht...
Hui, ist das ein 64bit Java? Bei 32bit ist eigentlich bei ca. 1200m Schluss...
Ggf. mal einen Profiler laufen lassen - im JDK/bin Ordner sollte schon eine "jVisualVM.exe" rumliegen, mit der sollte man analysieren können, wo der Speicher flöten geht...
Im übrigen hängt der maximal verfügbare Speicherplatz sehr stark vom System ab. Bei mir sind es etwa 1600m (bei 4GB RAM und 32bit JAVA). Wenn man aber zuviel an gibt sollte JAVA gar nicht starten (zumindes bei Windoof). Kann sein das der Parameter bei einem Mac einfach ignoriert wird, wenn er zu hoch ist und wie soll man 3GB für den Heap Space haben, wenn auch noch der Stack und das OS RAM braucht?
Das habe ich jetzt auch von einem Arbeitskollegen gehört.
Aber ich verstehe nicht, was ich falsch gemacht habe...
Siehst du ein Problem in einem Code (siehe Anhang - Java-Klasse FullDatabaseParser) ??
ich würde mal versuchen, von dem rekursiven Ansatz wegzukommen.
Probiere testweise mal eine Schleife für die Pages.
So kannst du sicherlich schon mal einigen Overhead einsparen.
Ich weiß nicht genau, wie das der Garbage Collector (bzw. die OSX-Version) macht - aber evtl. werden die Objekte einer Methode erst freigegeben, wenn die Methode komplett ausgeführt wurde. Dies wäre aber ja bei Rekursion nicht der Fall, sodass du die ganzen Parser der vorherigen Seiten noch komplett im Speicher hast.
Bei Rekursionen wird jeder Methodenaufruf (und damit dessen Variablen) auf den Stack gelegt und nach Abschluss von oben herab wieder aufgelöst. Rekursionen sind natürlich eine tolle, elegante und oft auch kürze (in LOC gesehen) Darstellungsweise als die Iterativen Ansätze. Aber soweit ich weiss langsamer und natürlich speicherintensiver - eben wegen diesem Stack-Prozedere.
Der Stack sollte damit eigentlich nichts zu tun haben (enthält nur lokale variablen, hat nichts mit dem GC zu tun, und würde einen StackOverflowError und keinen OOME werfen). Ggf. morgen mal den Code anschauen...
Doch - zwar rufst du nicht rekursiv eine Methoden des gleichen Objektes auf, dafür aber immer die gleiche Methode eines neuen Objektes.
Hier mal die relevanten Teile des Codes:
Java:
publicclassFullDatabaseParser{//...publicvoidgetAllRequiredValues(String url){//...FullDatabaseParser parser =newFullDatabaseParser();//Zeile 168//...
parser.getAllRequiredValues(newPage);//Da haben wir sie, die Rekursion ;-)//...}
Doch - zwar rufst du nicht rekursiv eine Methoden des gleichen Objektes auf, dafür aber immer die gleiche Methode eines neuen Objektes.
Hier mal die relevanten Teile des Codes:
Java:
publicclassFullDatabaseParser{//...publicvoidgetAllRequiredValues(String url){//...FullDatabaseParser parser =newFullDatabaseParser();//Zeile 168//...
parser.getAllRequiredValues(newPage);//Da haben wir sie, die Rekursion ;-)//...}
Du machst ständig neue Parser auf, die alten bleiben bestehen. Whl. bleiben alte Seiten dann auch noch als Objektstrukturen im Speicher und irgendwann ist halt Schicht in Schacht...
