Requests auf einen Endpoint hängen ewig, während der Rest des Service in Ordnung ist. Wie diagnostizierst du das?

Zieh einen Thread Dump mit jstack oder jcmd, idealerweise zwei im Abstand von ein paar Sekunden, und schau dir die hängenden Threads an. Die JVM erkennt Lock-Zyklen und druckt direkt einen Abschnitt zu Java Level Deadlock. Gibt es keinen Zyklus, hängen die Threads wahrscheinlich an einer Ressource wie einem Connection Pool oder einem Socket-Read ohne Timeout. Behebe es, indem du Locks konsistent ordnest, den kritischen Abschnitt verkleinerst oder Timeouts ergänzt.

Das Erste ist ein Thread Dump, und ich ziehe zwei oder drei im Abstand von ein paar Sekunden, damit ich unterscheiden kann, was wirklich hängt und was nur beschäftigt ist. Die JVM nimmt mir hier viel ab: halten zwei Threads gegenseitig ihre Monitore, druckt sie einen Abschnitt zu Java Level Deadlock, der beide Threads und beide Locks benennt, und die Stacktraces sagen mir dann genau, welche Methoden ich anschauen muss. Gibt es keinen Zyklus, sieht das Muster meist anders aus: Dutzende Threads warten auf denselben Connection Pool, was bedeutet, dass irgendetwas Verbindungen festhält statt eines klassischen Deadlocks, oder Threads hängen in einem Socket-Read ohne konfiguriertes Timeout, was unendlich blockiert, wenn die Gegenstelle nicht mehr antwortet. Zur Prävention habe ich ein paar Regeln. Locks werden in konsistenter Reihenfolge geholt, und ich dokumentiere diese Reihenfolge, wenn es zwei gibt. Ich halte den kritischen Abschnitt so klein wie möglich und mache nie einen Netzwerkaufruf und veröffentliche nie eine Nachricht, während ich ein Lock halte. Und wo das Design es erlaubt, nutze ich tryLock mit Timeout, damit Contention zu einem behandelten Fehler degradiert statt zu einem Hänger.