JVM Performance, Speicher & Diagnose

Performance beginnt vor dem Tuning

Viele Performanceprobleme entstehen durch fachliche oder architektonische Entscheidungen: zu große Aggregate, N+1 Queries, zu lange Transaktionen, fehlende Pagination, ungünstige Batchgrößen oder Remote Calls in kritischen Pfaden. JVM-Flags sind selten die erste Lösung.

Diagnosewerkzeuge

GC-Logs zeigen Speicher- und Pausenverhalten. JFR zeigt Locks, Methoden, Allocation, I/O und Threads. Thread Dumps helfen bei Deadlocks und blockierenden Aufrufen. Metriken zeigen Trends, Traces zeigen verteilte Latenz.

Virtual Threads im Betrieb

Virtual Threads können blockierende I/O-Szenarien vereinfachen, aber Datenbank- und HTTP-Pools bleiben Ressourcen. Wenn 10.000 virtuelle Threads auf 30 DB-Verbindungen warten, ist die Datenbank weiterhin die Grenze.

Entscheidungen

Ausführliche Beispiele

java \
  -XX:StartFlightRecording=filename=/var/log/order/startup.jfr,dumponexit=true \
  -Xlog:gc*:file=/var/log/order/gc.log:time,uptime,level,tags \
  -XX:MaxRAMPercentage=75 \
  -jar order-service.jar

// Anti-Pattern: alle Datensätze laden und im Speicher filtern.
List<Order> all = orderRepository.findAll();
return all.stream().filter(Order::isOpen).toList();

// Besser: fachliche Query mit Limit und Sortierung.
return orderRepository.findOpenOrders(PageRequest.of(0, 100));

Typische Stolperfallen