Les requêtes vers un endpoint restent bloquées indéfiniment alors que le reste du service va bien. Comment diagnostiquez-vous cela ?

Prenez un thread dump avec jstack ou jcmd, idéalement deux à quelques secondes d'intervalle, et regardez les threads bloqués. La JVM détecte les cycles de verrous et affiche directement une section de deadlock au niveau Java. S'il n'y a pas de cycle, les threads sont probablement bloqués sur une ressource comme un pool de connexions ou une lecture de socket sans délai d'expiration. Corrigez en ordonnant les verrous de façon cohérente, en réduisant la section critique, ou en ajoutant des délais d'expiration.

La première chose, c'est un thread dump, et j'en prends deux ou trois à quelques secondes d'intervalle pour distinguer ce qui est vraiment bloqué de ce qui est simplement occupé. La JVM fait beaucoup du travail ici : si deux threads détiennent mutuellement leurs moniteurs, elle affiche une section de deadlock au niveau Java qui nomme les deux threads et les deux verrous, et les traces de pile me disent exactement quelles méthodes regarder. S'il n'y a pas de cycle, le motif est en général différent : des dizaines de threads tous en attente sur le même pool de connexions, ce qui veut dire que quelque chose retient des connexions plutôt qu'un deadlock classique, ou des threads bloqués dans une lecture de socket sans délai d'expiration configuré, ce qui pend indéfiniment quand un pair cesse de répondre. Pour la prévention j'ai quelques règles. Les verrous sont pris dans un ordre cohérent, et je documente cet ordre quand il y en a deux. Je garde la section critique aussi petite que possible et je ne fais jamais d'appel réseau ni de publication de message en tenant un verrou. Et quand la conception le permet, j'utilise tryLock avec un délai d'expiration, pour que la contention dégénère en erreur traitée plutôt qu'en blocage.