Comment profilez-vous un service Java en production sans le mettre hors ligne ?

Utilisez Flight Recorder, intégré à la JVM et conçu pour de l'enregistrement continu à faible surcoût. Démarrez-le avec jcmd sur un processus en cours, capturez une fenêtre, et ouvrez l'enregistrement dans Mission Control pour voir les méthodes chaudes, l'allocation par site, la contention de verrous, le ramasse-miettes et les taux d'exceptions. Pour des flame graphs mêlant frames natives et Java, un profileur asynchrone est le compagnon habituel, et les dumps de tas restent l'outil des fuites.

Flight Recorder d'abord, parce qu'il est livré avec la JVM et que le profil par défaut a un surcoût assez faible pour rester actif. Je m'attache avec jcmd sur le processus en cours, j'enregistre quelques minutes qui incluent le comportement lent, je fais un dump et je l'ouvre dans Mission Control. L'ordre dans lequel je regarde dépend du symptôme. Pour le CPU je vais aux méthodes chaudes, mais pour la latence j'apprends en général plus de l'allocation par site d'appel, parce qu'une allocation excessive pilote les pauses de collecte, et de la contention de verrous, où un bloc synchronized sur un chemin chaud saute aux yeux tout de suite. Le ramasse-miettes et les taux d'exceptions sont sur le même enregistrement, donc je peux corréler au lieu de deviner. Si je veux un flame graph qui montre les frames natives à côté de Java, j'utilise un profileur asynchrone, qui évite aussi le biais de safepoint des anciens profileurs par échantillonnage. Pour les fuites mémoire l'outil, c'est un dump de tas et un arbre de dominateurs, puisqu'un profil me montre l'allocation, pas la rétention. Et je compare toujours à un enregistrement de référence pris sur une période saine, parce qu'un profil seul n'a aucune notion de normal.