Java Speichermanagement fragwürdig

[Alexander Hofmann]

Das Speichermanagement von Java empfinde ich als sehr fragwürdig. Wann oder ob Speicher irgendwann freigegeben wird ist mir ein Rätsel. Prinzipiell scheint nach dem Motto vorgegangen zu werden "lieber noch drinlassen". <br>
Der JBuilder3 von Borland ist meines Wissens zu einem Großteil selbst in Java geschrieben. Auch diese Entwicklungsumgebung geht in die Knie, wenn sie mehrere Stunden am Stück verwendet wird: Der Speicher schrumpft und schrumpft und bei "nur" 128 MB RAM ist spätestens nach 2 Stunden Arbeit ein Neustart erforderlich, weil der Speicher nicht ausreichend aufgeräumt wird, mit 256 MB dauerts etwas länger.<br>
Getestet hab ich das mit Java 1.2 und Java 1.2.2, (1.3beta habe ich nicht getestet, aber die Bezeichnung "beta" deutet auf eine Baustelle hin, die für professionelle Software derzeit ungeeignet ist).<br>
Auch das offenbar komplett in Java implementierte Oracle-Datenbank-Setup (8.1.5) stößt schnell an Speichergrenzen, wenn man verschiedene Insatllationsteile nacheinander ausführt. Auch bei 256 MB RAM ist relativ schnell Feierabend. "es steht nicht genügend speicher zur verfügung".<br>
Warum soll's einem dann besser ergehen, wenn man selbst was entwickelt?<br>
Traurig, aber wahr. <br>
Falls jemand Tricks kennt, wie man auf das Wirken des Garbage-Collector Einfluß nehmen kann, oder falls jemand eine JVM kennt, deren Speichermanagement funktioniert, wär ich für jeden Hinweis dankbar.<br>
Gruß an alle
Alex

[Alexander Hofmann]

Ich hoffe auf begründeten Widerspruch

Hallo Alexander,

Das Problem mit JBuilder habe ich auch. Einen Trick habe ich

auch nicht parat, aber ein nicht mehr benötigtes Objekt auf null

setzen und anschliessend den Garbage Collector mit der statischen

Methode System.gc() solltestdu vielleicht mal ausprobieren.

Gruß

Thomas Tasio

[Alexander Hofmann]

Das nutzt auch nichts, weil durch dem Aufruf vob System.gc() nichts weiter gemacht wird, als daß nicht mehr benötigte Speicher FESTGESTELLT wird.<br>
Darauf, WANN der Markierte nun wirklich freigegeben wird, hat man meines Wissens keinen Einfluß.<br>
Wenn das ginge, hätten die Macher des JBuider das bestimmt auch ausgenutzt, und es würde nicht permanent überflüssigerweise Speicher verbraten.

Ale

[Andreas Tengicki]

Das Problem von Java ist bekannt :-)

Der am haüfigste angewandte Trick ist, daß man seine Anwendung mit einem Objektpool ausstattet, in dem man nicht mehr benötigte Objekte ablegt (also so eine Art Free) und dann statt eines new erstmal guckt ob da was geeignetet drin ist.

Geht auch schneller, das der recht langsame Konstruktor entfällt. Problem man braucht eine Initialisierung unabhängig vom Konstruktor, die as Objekt wiederverwendungsfähig macht. Und das Free ist halt zu implementieren.

Am leichtesten geht das ganze mit einem eigenen Interfacem daß man dann in seinen Klassen implementiert

[Alexander Hofmann]

Das bedeutet aber lediglich, daß das Neuaufkommen von Objekten minimiert werden würde...schön und gut, aber ein effekt davon ist doch, daß NIE elemente gelöscht werden, da sie im Pool auf Wiederverwendung warten.<br>
Das ist nur ok, wenn dauernd Objekte verworfen, und dann wieder neu erzeugt werden.<br>
Der Garbage Collector findet dann außerdem überhaupt nichts. Bis zum Programmende wird NICHTS was je erstellt wurde, freigegeben.<br>
Ist prima, wenn man unbegrenzt Speicher hat.<br>
Und schon wird bei langem Arbeiten der Speicher wieder vollgemüllt.
Das schaffen Java mit dem GC auch alleine :-( <br>
Gibt es denn nirgendwo einen funktionierenden GC ?<br>

Gruß
Ale

[Andreas Tengicki]

Natürlich macht so ein Pool nur da Sinn wo die Objekte dieses Typs in Kürze wieder gebraucht werden. Das hast Du schon richtig erkannt. In diesem zumindestens bei unseren Anwendungen garnicht so unrealistischen Fall ist es eine Lösung die sowohl Speed bei der Neuanlage als auch weniger Ärger mit der gc verspricht

Hallo Leute,

also ich hab auch schon oft gelesen, das der Aufruf von System.gc() überhaupt nicht garantiert, dass der Garbage Collector aufräumen anfängt. Kann deshalb nur zustimmen.
Wäre mal interessant zu wissen, wann der das macht (wieviele Objekte müssen im Java-Heap sitzen???)
Ich erinnnere mich das ich vor kurzem eine äußert interessanten JDC-TechTip (Java Development Connectivity) gelesen habe.
Leider hab ich die jetzt in der Arbeit. Ich poste morgen mal den Vorschlag. Ist aber englisch.
Was ist mit <b>weak references</b>? Die ab Platform 2 zur Verfügung und sollen angeblich besonders anfällig über den GC sein.
In dem Buch vom Middendorf werden sie sogar für die Realisierung von Histroy/Undo-Funktionen empfohlen.
Hat jemand damit schon Erfahrungen gemacht?

Gruß
Tobia

[Michael Steyer]

Hallo Thomas,
das leidige Thema mit den JBuilder habe ich auch. Es läßt sich allerdings einigermaßen reduzieren, wenn Du Hotspot (1.01) verwendest. Du mußt es Dir nur von Sun runterladen und installieren. Anschließend movest Du den Ordner "Hotspot" nach Jbuilder3\Java\Jre\Bin\ und deinstallierst Hotspot wieder über Start/Sastemsteuerung/Software usw. Letzeres deshalb, weil die Hotspotinstallation von Sun nur das JDK 1.2.2 und nicht das vom JBuilder (1.2) erkennt. Hotspot 1.01 funktioniert "eigentlich" (laut Sun) richtig nur mit 1.2.2. Ich habe allerdings keine Probleme mit 1.2 unter dem JBuilder 3.02 gehabt.
Versuch´s mal; der Jbuilder hält wesentlich länger durch, obwohl sich die Anwendungen selber nicht (habe keine Millisekunden-Stoppuhr) beschleunigen.
Grüße Michael (E-Mail: [email protected]