Como você faz profiling de um serviço Java em produção sem tirá lo do ar?

Use o Flight Recorder, que é embutido na JVM e desenhado para gravação contínua de baixo overhead. Inicie com jcmd num processo em execução, capture uma janela e abra a gravação no Mission Control para ver métodos quentes, alocação por site, contenção de lock, garbage collection e taxas de exceção. Para flame graphs com frames nativos e Java juntos, um async profiler é o companheiro de sempre, e heap dumps seguem sendo a ferramenta para vazamentos.

Flight Recorder primeiro, porque ele vem com a JVM e o perfil padrão tem overhead baixo o bastante para deixar rodando. Eu me conecto com jcmd no processo em execução, gravo alguns minutos que incluam o comportamento lento, faço o dump e abro no Mission Control. A ordem em que eu olho as coisas depende do sintoma. Para CPU eu vou para métodos quentes, mas para latência eu normalmente aprendo mais com alocação por call site, porque alocação excessiva guia as pausas de coleta, e com contenção de lock, que é onde um bloco synchronized num caminho quente aparece na hora. Garbage collection e taxas de exceção estão na mesma gravação, então eu consigo correlacionar em vez de chutar. Se eu quero um flame graph que mostre frames nativos ao lado dos de Java, eu uso um async profiler, que também evita o viés de safepoint que profilers de amostragem mais antigos tinham. Para vazamentos de memória a ferramenta é um heap dump e uma dominator tree, já que um profile me mostra alocação, não retenção. E eu sempre comparo com uma gravação de referência de um período saudável, porque um profile sozinho não tem noção do que é normal.