Sparen beim String bauen

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.

Java Concurrency – A Tutorial

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 Concurrency – A Tutorial

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.

LinkedIn-Architektur

Wer gern mal wissen möchte, wie moderne grosse Webseiten laufen, der kann sich hier die LinkedIn-Architecture anschauen und durchlesen. Und wieder ist Lucene die Search-Engine der Wahl. Interessant ist der LinkedIn-Network-Graph, der in Memory gehalten wird… 12 GB RAM.

Einzig die Behauptung

Garbage Collection pauses were killing them. [LinkedIn said they were using advanced GC’s, but GC’s have improved since 2003; is this still a problem today?]

kann ich nicht glauben. Deswegen wurde die Graph-Engine in C geschrieben. Ich denke mal, da war komplett etwas falsch, wenn der GC austickt.

Warum nicht jeder IT-Meldungen schreiben kann

Heute berichtet Golem über “Daten von 4,5 Millionen Bankkunden in den USA verloren“. In einem weiteren Satz heisst es dann:

Der US-amerikanischen “Bank of New York Mellon” sind rund 4,5 Millionen Kundendatensätze verloren gegangen.

Wenn man die Meldung liest, dann merkt man, dass hier nicht von Datenverlust im Sinne von “Alles futsch, auch Backups helfen nicht mehr” die Rede ist, sondern von Daten, die sich durch schlichte Unachtsamkeit an anderen, als den vorgesehenen Plätzen befinden.

Der Unterschied liegt darin, dass die 4,5 Millionen immer noch ein Konto mit einem Betrag haben, aber jemand ausserhalb der Bank weiss nun eventuell davon. Im Falle eines Datenverlustes hätten die 4,5 Millionen Kunden kein Konto mehr.

Merke: Überschriften von IT-Artikeln sind oft mehr als irreführend.

Lufthansa Zentralrechner hat gestreikt

Manchmal ist es doch gar wunderlich, dass sich die alten Zentralrechner Architekturen immer noch halten. So hat es letzte Nacht die Lufthansa erwischt, die nach Backuparbeiten ihr IT-Rückrat verloren hatte.

Die Informatiker der Fluggesellschaft hatten eine Routine-Sicherung der Daten gemacht, alles wieder aufgespielt und waren gerade dabei, die Rechner hochzufahren. Da gerieten die Daten im Computersystem kräftig durcheinander.

Mehr dazu bei N-TV.

P.S. Der wirklich Grund würde mich interessieren, denn eigentlich spielt man Backups nicht auf Livesysteme zurück… schliesslich heisst das Ding Backup und nicht Datenrefresh.

Wir jetzt auch

Ja, jetzt sind wir auch Blogger. Wir sind die Firma Xceptance aus Jena.

Wir möchten mit diesem Blog Ideen, Wissen, Links und vieles Interessante aus der Welt der Qualitätssicherung und des Softwaretests teilen. Etwas Eigenwerbung wird auch dabei sein, aber wir wollen natürlich kein Marketingblog betreiben. Wir freuen uns auf Ihre Kommentare und Anregungen.