Wie profilst du einen Java-Service in Produktion, ohne ihn offline zu nehmen?

Nimm Flight Recorder, der in der JVM eingebaut und für dauerhafte Aufzeichnung mit geringem Overhead ausgelegt ist. Starte ihn mit jcmd auf einem laufenden Prozess, nimm ein Fenster auf und öffne die Aufzeichnung in Mission Control, um heiße Methoden, Allokation nach Ort, Lock Contention, Garbage Collection und Exception-Raten zu sehen. Für Flame Graphs, die native und Java-Frames zusammen zeigen, ist ein Async Profiler der übliche Begleiter, und für Leaks bleiben Heap Dumps das Werkzeug.

Zuerst Flight Recorder, weil er mit der JVM kommt und das Standardprofil geringen genug Overhead hat, um dauerhaft zu laufen. Ich hänge mich mit jcmd an den laufenden Prozess, zeichne ein paar Minuten auf, in denen das langsame Verhalten vorkommt, dumpe das und öffne es in Mission Control. Die Reihenfolge, in der ich schaue, hängt vom Symptom ab. Bei CPU gehe ich auf heiße Methoden, bei Latenz lerne ich aber meist mehr aus der Allokation nach Aufrufort, denn übermäßige Allokation treibt die Sammelpausen, und aus der Lock Contention, wo ein synchronized-Block in einem heißen Pfad sofort auffällt. Garbage Collection und Exception-Raten liegen in derselben Aufzeichnung, ich kann also korrelieren statt zu raten. Will ich einen Flame Graph, der native Frames neben Java zeigt, nehme ich einen Async Profiler, der außerdem den Safepoint-Bias vermeidet, den ältere Sampling-Profiler hatten. Für Memory Leaks ist das Werkzeug ein Heap Dump und ein Dominator Tree, denn ein Profil zeigt mir Allokation, nicht Retention. Und ich vergleiche immer gegen eine Baseline-Aufzeichnung aus einer gesunden Phase, denn ein Profil allein hat kein Gefühl dafür, was normal ist.