Blog

EJAPP Top 10 Countdown: #6 - Unsachgemäßes Caching

Vincent Partington

Aktualisiert Oktober 23, 2025

3 Minuten

Lassen Sie uns den EJAPP Top 10 Countdown mit Nummer 6 fortsetzen. Caching ist eine lustige Sache. Richtig gemacht, kann es die Leistung Ihrer Enterprise Java-Anwendung enorm verbessern und kann sogar unerlässlich sein, um ein akzeptables Leistungsniveau zu erreichen, aber manchmal kann das Caching selbst die Ursache für Ihre Leistungsprobleme sein. Unsachgemäßes Caching deckt beide Fälle ab.

Es gibt eine ganze Reihe von Dingen, die sich für das Caching eignen:

Lokale Ressourcen, die viel Initialisierung erfordern, wie z.B. JNDI-Ressourcen (EJBs), Spring BeanFactories, AxisEngines, usw.
Netzwerkressourcen, die schwer einzurichten sind, wie z.B. Datenbankverbindungen, HTTP(S) Verbindungen, usw.
Daten, die schwer abzurufen/zu berechnen sind, wie z.B. aus einer Datenbank abgerufene Objekte, gerenderte HTML-Seiten usw.

Für jede dieser Optionen müssen Sie bei Fragen wie der nach dem Preis unterschiedliche Kompromisse eingehen:

Wie überprüft der Cache, ob die Ressource noch funktioniert? Wenn zum Beispiel eine Datenbankverbindung eine Zeit lang nicht benutzt wird, kann die Datenbank beschließen, sie zu schließen, oder eine Firewall kann die Verbindung trennen. Die Überprüfung der Gültigkeit einer Ressource kann ein kostspieliger Vorgang sein, der jeglichen Leistungsgewinn, der durch den Cache erzielt werden könnte, zunichte macht.
Wie prüft der Cache, ob sich die Ressource geändert hat? Eine nicht ordnungsgemäße Implementierung kann dazu führen, dass die Anwendung nach einer Änderung der Konfiguration (oder des Inhalts) neu gestartet werden muss.
Wie viel Speicherplatz benötigt der Cache?
Ist der Cache-Thread sicher? Bei unsachgemäßer Implementierung kann es im Cache zu Sperrkonflikten kommen.
Wie hoch ist die Cache-Trefferrate? Wenn die Cache-Trefferrate zu niedrig ist, macht der Aufwand für die Cache-Verwaltung jeden positiven Effekt zunichte.
Wie wird die Leistung der Anwendung in Bezug auf den Cache getestet? Kann der Cache mit korrekten Daten vorgeladen oder während des Tests deaktiviert werden?
Kann der Cache während der Laufzeit überwacht werden? Zu den Dingen, die überwacht werden können, gehören die Anzahl der Objekte im Cache, die Menge des verwendeten Speichers und die Cache-Trefferquote.
Kann der Cache während der Laufzeit verwaltet werden? Denken Sie darüber nach, den Cache zu aktivieren/deaktivieren, seinen Inhalt zu leeren oder seinen Inhalt zu speichern/wiederherzustellen (zu Testzwecken).

Ein Kollege von mir hat ein schönes Beispiel dafür gefunden, wie die Kriterien #1, #4 und #5 zusammen zu einer schlechten Leistung führen. Der Check-and-Get-Teil des Cache wurde in einem kritischen Abschnitt wie diesem platziert: [java] public Object getFromCache(String key) { synchronized(map) { if(!map.containsKey(key)) { ... Daten aus dem Backend abrufen ... } return map.get(key); [/java] } } Das Abrufen der Daten aus dem Backend dauerte jedoch 100 ms und die Cache-Trefferquote betrug weniger als 10%. Der Nettoeffekt war, dass die Cache-Sperre stark beansprucht wurde. Das Problem verschwand, nachdem dieser Cache vollständig entfernt worden war! Wie ich eingangs sagte, ist Caching eine lustige Sache :-) Denken Sie zumindest an Folgendes, wenn Sie über Caching nachdenken:

Cache , wenn und nur wenn Caching erforderlich ist.
Überprüfen Sie das Funktions- und Leistungsverhalten Ihres Cache mit Leistungstests.
Stellen Sie sicher, dass Ihr Cache während der Laufzeit verwaltet und überwacht werden kann.