Blog

EJAPP Top 10 Countdown: #10 - Übermäßiges Protokollieren

Vincent Partington

Aktualisiert Oktober 23, 2025

4 Minuten

Auf der J-Fall im Oktober 2006 habe ich einen Vortrag über die 10 größten Leistungsprobleme gehalten, die mir und meinen Kollegen bei Xebia begegnet sind. Die Liste wurde durch ein Brainstorming mit einer Gruppe von Leuten erstellt und basierte auf den Erfahrungen, die wir alle mit der Leistung in unseren eigenen Projekten und in Projekten, bei denen wir zur Beseitigung von Leistungsengpässen hinzugezogen wurden, gemacht hatten. Das ist natürlich eine sehr unwissenschaftliche Art, eine solche Liste zu erstellen. ;-)

In der Wissenschaft muss ich richtige Experimente mit angemessener Kontrolle durchführen. In diesem Fall bedeutet das, Benchmarks zu schreiben. Das ist jedoch in der Praxis aus einer Reihe von Gründen unmöglich:

Diese Probleme wurden im Zusammenhang mit einer Enterprise Java-Anwendung beobachtet. Bei einem einfachen Benchmark wird das Verhalten zweifellos ganz anders sein.
Diese Probleme traten unter allen möglichen JDK-Versionen, Anwendungsserverprodukten und -versionen, Datenbankservern usw. auf. Um ein vollständiges Bild zu erhalten, müsste ich sie alle aufzählen!

Daher habe ich mich entschlossen, statt der wissenschaftlichen Methode den Weg der Statistik zu gehen. Um eine bessere Top 10 zu erhalten, werde ich etwa einmal pro Woche einen Blogeintrag schreiben. Jeder Blogeintrag wird einen anderen Punkt der Top 10 der Leistungsprobleme von Enterprise Java-Anwendungen behandeln. Ich hoffe, dass die Mitglieder der Enterprise Java-Community ihre Erfahrungen mit der Performance mitteilen (noch besser, wenn sie Zahlen haben!), mir bei der Analyse der Probleme helfen und ihre eigenen Performance-Lösungen und Tipps hinzufügen. Das Ziel ist es, eine Top-10-Liste zu erstellen, die anderen Entwicklern und IT-Managern als Hilfsmittel zur Bewusstseinsbildung und als schnelle Checkliste bei Performance-Problemen dienen kann. Fangen wir also ohne Umschweife ganz unten an: Nummer 10. Übermäßige Protokollierung ist ein Leistungsengpass, weil beim Protokollieren zwei Dinge passieren. Zunächst wird eine Reihe von String-Manipulationen durchgeführt (durch den aufrufenden Code, um Informationen zu sammeln, und durch das Protokollierungs-Framework, um eine Protokollzeile zu erzeugen) und dann wird der resultierende String in eine Datei geschrieben. Wenn Ihr Code viele Logging-Informationen schreibt, wird eine Menge davon passieren! Vor allem die String-Manipulationen sind sehr kostspielig, da sie die Allokation von Objekten (und später das Garbage Collecting) verursachen, während die Leistung der E/A von dem Medium abhängt, auf das geschrieben wird, und davon, ob die Log-Ausgabe gepuffert ist. Einige besonders unangenehme Dinge, auf die Sie stoßen, sind:

Aufrufen der Methode log.debug(), wenn die Protokollebene keine Debug-Informationen enthält. Alle String-Manipulationen (die in Debugging-Anweisungen in der Regel recht umfangreich sind) sind umsonst.
Loggen von viel zu viel Zeug wie komplette (verschachtelte) Stacktraces.
Protokollierung in System.out oder, noch schlimmer, in System.err. Es gibt keine Möglichkeit, dies abzuschalten und System.err ist nicht einmal gepuffert!

Zum Glück ist es sehr einfach, dieses Problem zu lösen. Verwenden Sie zuallererst immer ein Logging-Framework wie Log4J oder JDK Logging oder ein Meta-Framework wie Commons Logging oder SLF4J. Und dann sollten Sie die folgenden Praktiken beachten:

Verwenden Sie das folgende Idiom, um unnötige String-Manipulationen zu vermeiden: if(log.isDebugEnabled()) log.debug(...) Im EJAPP Top 10 Wiki wies Barend Garvelink darauf hin, dass Sie dies nicht tun müssen, wenn Sie JBoss Seam mit JDK 1.5 verwenden, da es ein nettes kleines Logging Idiom hat, mit dem Sie Code wie log.debug("Entered myMethod with arguments ${0}, ${1}", arg0, arg1);
Loggen Sie in einen gepufferten Writer oder, noch besser, asynchron.
Verwenden Sie getrennte Protokollierungskonfigurationen für Ihre Entwicklungs- und Produktionsumgebung.

Natürlich macht das bereits jeder. Es sind nur andere Entwickler, die das falsch machen ;-)