Sua latência no percentil 99 tem picos que o código da aplicação não explica. Como você checa se o garbage collection é o responsável?

Ligue o logging de garbage collection e alinhe os timestamps das pausas com as requisições lentas. Se os picos coincidem com as pausas, olhe taxa de alocação, promoção e folga de heap antes de mexer em qualquer flag, já que a maioria das pausas vem de alocar demais ou de um heap pequeno demais. Se não coincidem, cheque o time to safepoint, já que um safepoint longo trava todas as threads e parece exatamente uma pausa de garbage collection.

Eu quero duas linhas do tempo. O unified logging me dá cada pausa com sua causa e duração, e meus traces me dão as requisições lentas, então a primeira pergunta é simplesmente se elas se alinham. Se sim, eu resisto a mudar flags e olho o porquê. Normalmente o serviço aloca enormemente por requisição, algo como construir listas intermediárias num laço ou logar um payload serializado em toda chamada, então a correção é alocar menos. Às vezes o heap está apenas apertado demais e as coletas rodam o tempo todo, ou no G1 o código aloca arrays grandes que viram objetos humongous e se comportam mal. Só depois disso eu consideraria migrar para um coletor de baixa pausa, e trataria isso como um tradeoff em vez de um ganho de graça. Se as pausas não correlacionam, eu olho em outro lugar: o time to safepoint pode ser longo mesmo quando a coleta em si é curta, então uma thread num laço contado trava todo mundo. Eu também já persegui um caso que acabou sendo throttling de CPU do container, onde o processo era tirado do escalonador inteiro e nenhum tuning de JVM teria ajudado.