javaw Speicherauslastung

Status
Nicht offen für weitere Antworten.

schlaubie

Bekanntes Mitglied
Hallo Leute ich habe ein kleines Problem mit der virtuellen Maschine!
Ich habe ein kleines Programm was aus ca. 50 Datei die konfikurationen einliest! Dafuer brauch es sehr viel speicher!
Das ist auch richtig nur nach beendigung der Methode werden die Threads anscheinend nicht geschlossen! sie laufen ium Hintergrund weiter so das die Speicherauslastung weiter bei 100 MB ist wenn ich nun versuche auf meine initialisierten Objekten zu arbeiten ! Bricht alles zusammen ! Die Auslagerungsdatei hat groeßen von mehr als 700 MB!
Wie kann ich erreichen das er nicht soviel Speicher braucht bzw. die Threads beendet!
!!! Die Threads habe ich nicht hereinprogrammiert die kommen durch eingebunden jars!!

Besten Dank im vorraus!
 

AlArenal

Top Contributor
Lass mal nen Profiler drüberlaufen um festzustellen wo genau der Speicher verbraten wird. Irgendwo musst du ja ohne Ende Objekte erzeugen, die du nicht brauchst und die der Grabage Collector nicht einsammeln kann, weil du noch irgendwo Referenzen drauf hast.
 

Natorion

Bekanntes Mitglied
versuch mal nach dem ganzem einlesen und arbeiten der jars den garbage collector manuell aufzurufen. vielleicht hilft es ja. weiters wären noch ein paar infos nicht so schlecht wie:

-welche jar wird importiert
-wie parsed du die dateien durch (code dafür)
-wie groß sind die dateien
 

AlArenal

Top Contributor
Das mauelle AUfrufen des GC bringt in der Regel nichts, wurde hier aber schon mehrfach durchgekaut. Die VM entscheidet alleine ob und wann der GC aufgerufen wird, ganz egal wie oft ich den manuell aufrufe und wenn ein Programm im Laufe der Zeit mehrere hundert MB RAM beansprucht, kann ich davon ausgehen, dass es lange genug lief und schonmehrfach die VM den GC angeworfen und dieser nichzts gefunden hat, was er hätte rauswerfen können.

Die Ursache liegt nicht im faulen GC, jede Wette.
 

AlArenal

Top Contributor
Ich benutze ein Profiler Plugin für Eclipse. Wie das Angebot für andere IDEs aussieht, weiß ich nicht. Wenn man die JVM von BEA benutzt kann man glaube ich deren Profiler kostenlos nutzen, habe ich aber noch net getestet.
 

schlaubie

Bekanntes Mitglied
Wie heißt dein Plugin ?
Woran liegt es das die Threads nach beendigung der Methode nicht geschlossen werden im Debug Modus stehen nach der beendigung der HauptparseMethode 3000 laufen Threads da !
Gibt es eine Möglichkeit ihm zu sagen das er sie schließen soll?
 

AlArenal

Top Contributor
schlaubie hat gesagt.:
Wie heißt dein Plugin ?
http://sourceforge.net/projects/eclipsecolorer
Woran liegt es das die Threads nach beendigung der Methode nicht geschlossen werden im Debug Modus stehen nach der beendigung der HauptparseMethode 3000 laufen Threads da !
Gibt es eine Möglichkeit ihm zu sagen das er sie schließen soll?

Was für ne Methode?
Wenn ich ner Methode nen neuen Thread starte, läuft der natürlich weiter, auch wenn die Methode beendet ist. Das ist ja schließlich Sinn der Sache... Was machen denn deine Threads so dolles? Warten die bis St. Nimmerlein darauf mal was zu tun zu bekommen?
 

schlaubie

Bekanntes Mitglied
Wie schon gesagt ich habe die Threads nicht eröffnet! Sie kommen durch die eingebunden jars! Muss sie ersteinmal analysieren! Habe im javamagazin 6.05 einen Artikel übers Profiling gefunden! Dort entfehlen sie mehr oder weniger Borland Optizeit! Hat jemand erfahrung damit?
 

schlaubie

Bekanntes Mitglied
kann es vielleicht auch an System.out.println() befehlen liegen die ich neben loggern immernoch im Code habe?
 

AlArenal

Top Contributor
schlaubie hat gesagt.:
Habe im javamagazin 6.05 einen Artikel übers Profiling gefunden! Dort entfehlen sie mehr oder weniger Borland Optizeit! Hat jemand erfahrung damit?

"empfehlen" und "OptimizeIt!". Das Tool kenne ich, aber der Preis schreckt ab, nur um "mal eben" was zu profilen.

kann es vielleicht auch an System.out.println() befehlen liegen die ich neben loggern immernoch im Code habe?

Wenn du im Profiler siehst, dass dein ganzer Heap in Strings verschwindet, könnte es sein. Aber wie sollen wir mehr wissen als dein Profiler?
 

schlaubie

Bekanntes Mitglied
Nachtrag für alle die vielleicht das selbe Problem haben es lag an log4j! Da bei jeder initialisierung eines Log4j Loggers ein thread geöffnet wird! Ich dachte ich muss explizit jeder Klasse seinen Logger mitgeben! Aber das ist Falsch! Also nur ein mal als Singelton die Logger initialiseren! Dann klappt es auch mit der performanz!
 
Status
Nicht offen für weitere Antworten.

Ähnliche Java Themen

Neue Themen


Oben