Heute ist mir beim Testen dieser Javascript-Code über den Weg gelaufen. Ich liege jetzt noch auf dem Boden. Eigentlich ist es ja eher zum Heulen, aber naja:
|
1 2 3 4 |
if(8 > 3) { display.setIndex(1, 8); } |
Aber wer weiss, manchmal werden Sachen einfach true.
Wer sich einen virtuellen Server gemietet hat und sich quält, Java vernünftig zum Laufen zu bringen, dem sei dieser Artikel ans Herz gelegt: Java Web Hosting HowTo – vServer memory and Java heap size trouble.
Java Virtual Machines and Linux virtual Servers do not play well with each other all the time. Some tweaking and configuration will be necessary to get it working and optimize the use of the (memory) resources.
Die VPS / Virtuellen Server haben leider die Angewohnheit, den Speicher als zu gross zu melden. Sie melden den Gesamtspeicher des Hosts und nicht den Speicher des Virtuellen Servers. Deswegen schlägt Java gnadenlos zu, und versucht sich reinzuoptimieren. Die einzige Lösung ist die Limitierung des Speichers schon beim Start von Java mit -Xms und -Xmx, um die Selbstoptimierung von Java zu umgehen.
Softreferenzen (soft references) in Java sind eine tolle Sache, denn es lassen sich tolle Caches und Notfallszenarien damit bauen. Was kaum jemand weiß, dass Softreferenzen nicht nur im Falle von akuter Speicherknappheit freigegeben werden, sondern durchaus auch früher. Letzteres kann zu unerwarteten Nebenwirkungen führen, speziell mit Blick auf Caching.
Soft references are kept alive longer in the server virtual machine than in the client. The rate of clearing can be controlled with the command line option
-XX:SoftRefLRUPolicyMSPerMB=, which specifies the number of milliseconds a soft reference will be kept alive (once it is no longer strongly reachable) for each megabyte of free space in the heap.The default value is 1000 ms per megabyte, which means that a soft reference will survive (after the last strong reference to the object has been collected) for 1 second for each megabyte of free space in the heap. Note that this is an approximate figure since soft references are cleared only during garbage collection, which may occur sporadically.
Quelle: JDK 6 Garbage Collection Tuning Guide
Nachtrag: Erwähnenswert ist auch dieser Blogeintrag von Jeremy Manson.
Heute habe ich einen interessanten Ansatz für eine Verbesserung von JUnit gefunden – TestedBy.
In a nutshell TestedBy aims to change the point of view regarding test classes and classes under test. What we would obtain is to put class under test (the most important classes of your projects) on the centre and link from there your test class and test method.
Ist einen Blick wert, da es scheinbar erstmal das Management der Tests verbessert.
Vom Eclipse-Projekt gibt es jetzt auch einen Memory-Analyzer. Ich probiere das Ding gleich mal aus. Es soll grosse Hprof-Dumps effizient analysieren können. Das wäre genau richtig, schliesslich quälen wir uns oft mit 1-2 GB Files rum.
Viele Java-Programmiere denken oft beim Schreiben Ihres Codes wenig über Müll nach. Natürlich nimmt man zum Bauen eines Strings aus vielen kleinen Puzzleteilen einen StringBuilder. Den StringBuffer nimmt man nicht mehr, weil der im Regelfall unnötig synchronisiert ist. Schliesslich löst das im Java Memory Model ab JDK 5 eine Synchronisation mit dem Hauptspeicher aus (JSR-133), die wir überhaupt nicht wollen.
Einen kleinen Trick für unnötige Objekt-Erzeugung und damit für weniger Müll im System, gerade wenn immer wieder Strings gebaut werden müssen, ist die korrekte initiale Größe des StringBuilders. Ein new StringBuilder() reserviert zunächst nur ein Array mit 16 Characters. Wenn wir also recht viel zusammenbauen, muss mehrmals eine neues grösseres Array (2 * ggw. Grösse + 1) erzeugt und der Inhalt umkopiert werden.
Wer also weiss, dass er ca. 100 Zeichen aneinanderhängt, der lässt sich gleich einen StringBuilder mit Grösse 120 geben – new StringBuilder(120) – und spart damit das Anlegen von drei Arrays und drei Copy-Operation ein. Gerade bei intensiven Operationen mit Strings macht das eine Menge aus.
Wer würde schon bei einem Umzug zuerst mit dem kleinsten Karton anfangen und dann wegwerfen, weil nicht alles reinpasst? Man schätzt doch am Anfang schon vernünftig ab, wie groß der Karton sein sollte.
Heute habe ich eine wunderbare Webseite zum Thema Java Concurrency gefunden. Jakob Jenkov hat hier viele interessante Themen zur parallelen Programmierung mit Java zusammengefasst. Ein Bookmark wert und in einer ruhigen Minute unbedingt mal lesen.
Java was one of the first languages to make multithreading easily available to developers. Java had multithreading capabilities from the very beginning. Therefore, Java developers often face the problems described above. That is the reason I am writing this trail on Java concurrency. As notes to myself, and any fellow Java developer whom may benefit from it.