¿Cómo perfilas un servicio Java en producción sin sacarlo de servicio?

Usa Flight Recorder, que viene incorporado en la JVM y está diseñado para grabación continua de bajo impacto. Arráncalo con jcmd sobre un proceso en ejecución, captura una ventana, y abre la grabación en Mission Control para ver métodos calientes, asignación por punto de origen, contención de locks, recolección de basura y tasas de excepciones. Para flame graphs con frames nativos y de Java juntos, un async profiler es el compañero habitual, y los volcados de heap siguen siendo la herramienta para las fugas.

Flight Recorder primero, porque viene con la JVM y el perfil por defecto tiene un impacto lo bastante bajo como para dejarlo corriendo. Me engancho con jcmd al proceso en ejecución, grabo unos minutos que incluyan el comportamiento lento, hago el volcado y lo abro en Mission Control. El orden en que miro las cosas depende del síntoma. Para CPU voy a los métodos calientes, pero para latencia normalmente aprendo más de la asignación por punto de llamada, porque asignar en exceso provoca pausas de recolección, y de la contención de locks, donde un bloque synchronized en una ruta caliente aparece de inmediato. La recolección de basura y las tasas de excepciones están en la misma grabación, así que puedo correlacionar en vez de adivinar. Si quiero un flame graph que muestre frames nativos junto a los de Java, uso un async profiler, que además evita el sesgo de safepoint que tenían los perfiladores de muestreo antiguos. Para fugas de memoria la herramienta es un volcado de heap y un árbol de dominadores, ya que un perfil me muestra asignación, no retención. Y siempre comparo contra una grabación de referencia de un periodo sano, porque un perfil por sí solo no tiene ninguna noción de lo normal.