1. …
12. JRE-Kompatibilität
Kommen beim Kompilieren Warnings? Ist dies der Fall, ist zu überprüfen, ob als “deprecated” gesetzte Klassen oder Methoden verwendet wurden. Es gibt einen ganzen Haufen Anwendungen, die mit JDK 1.5 einfach nicht mehr funktionieren, da verwendete Klassen oder Methoden nicht mehr von java.lang (oder anderen APIs) unterstützt werden. Fallen in einer Version Elemente weg, so sind diese in älteren Versionen schon als deprecated gekennzeichnet.
1.6 Projektplanung
In jedem Projektplan ist Zeit zum Refactoren und zur Verbesserung der Performance einzuplanen. Nichts ist schlimmer, als in einem – natürlich auch wieder enorm zeitkritischen – Projekt in den erodierten Sourcen rumwühlen zu müssen und nach und nach immer unwartbareren Code zu pflegen.
14. Testing
14.56 Zufallsgeneratoren überprüfen
Zu testen:
verschiedene Seeds in hintereinander generierten Random-Objekten? Initialisiert man mehrere Random-Objekte hintereinander, z.B in einer Schleife, tut es ein einfaches new Randon(System.currentTimeMillis()) nicht mehr. Auf schnellen Rechnern führt das zu einem gleichen Verhalten der Randoms. Eine Lösung ist die Verwendung eines zusätzlichen Randoms zur Initialisierung.
23. Systemintegration
…
23.5 Speicherbedarf untersuchen
..
23.6 Garbage-Collection untersuchen
Bei der Systemintegration im Produktiv-, wie auch im Testsystem ist das Verhalten des Garbage-Collectors zu untersuchen.
Die JVM kann dazu mit den Parametern -gc:verbose und -XX:+PrintGCDetails gestartet werden.
Eine weitere interessante Perspektive gibt die Auswertung von jstat:
jps zeigt alle vm-Ids der laufenden Virtual Machines. Befehl ist Teil vom SDK. vm-Id ist typischerweise die pid.
jstat - [-t] [-h <lines>] <vmid> [<interval> [<count>]]
Beispiel: jstat -gcutil -h3 99999 250 200
Ein Tool, dass die Informationen zum Verhalten des Garbage Collector visualisiert, ist visualgc. Hier läßt sich auch der Grund für die Garbage Collection sehen: War es ein System.gc() oder gab es bessere Gründe? Das Tool ist nicht in der JDK 1.5 enthalten, kann aber bei Sun heruntergeladen werden.
Es sollte auch ein Auge auf die Auslastung des Perm-Spaces geworfen werden. Dieser ist unabhängig vom Gesamtheap. Die Größe läßt sich mit -XX:PermSize=..MB und -XX:MaxPermSize=..MB steuern. Im Default sollte die JVM 64MB reservieren, der aber unter mysteriösen Umständen auch schrumpfen kann. Ich bin mir nicht ganz sicher, ob es sich dabei um ein normales Vergrößern des Virtual Spaces ( nicht allozierter, aber reservierter Speicher) handelt. Setzt man die Größe mit -XX:PermSize scheint die Größe sich aber nicht zu verändern.
Bei Serveranwendungen ist es wichtig, das Verhältnis von Young zu Tenured Space zu untersuchen. Finden zuviele Young collections statt? In einer größeren Serveranwendung kann man u.U. eine Ratio von 1:2 festlegen ( -XX:NewRatio=2) (Young 1 : 2 Tenured) .
Im Client-Teil einer Anwendung reichen die default-Einstellungen meist aus.
koenig! ich google gerade nach “java tenured space hibernate”, weil mein tentured space dick voll ist mit hibernate objekten, die nicht garbage-collected werden und dann stoss ich auf deinen blog, der mir zwar null weiterhilft, aber platz 3 im google ranking einnimmt. d.h. ich brauch vermutlich nicht weitersuchen, und bau einfach ein paar gigs mehr speicher in den server ein, und dazu muss ich nicht mal ins rechenzentrum laufen, sondern schieb den slider hier einfach ein stück weiter nach rechts. ESX rocks!
grüße
maddin
yes! ein session.close() war die lösung 🙂