Wartet jeder von zwei Threads auf den Lock, den der andere hält, stehen beide für immer still.
Warum Thread A hält Lock 1 und wartet auf Lock 2, B hält Lock 2 und wartet auf Lock 1 → Folge Beide stehen für immer still, abhängige Threads bleiben nacheinander ebenfalls hängen → Auf dem Bildschirm Ganzer Server steht still, Watchdog startet neu, Verbindungsabbruch für alle
Regeln für die Lock-Reihenfolge, Locks mit Timeout, Watchdog einsetzen und im Moment des Stillstands einen Thread-Dump schreiben.
Im Graphen
Verbindungen brechen gleichzeitig ab · Verbindungen, Sendevolumen des Servers
Wo nachsehen
Während des Stillstands die Call-Stacks aller Threads sichern. JVM: jstack (findet und markiert Deadlocks automatisch), .NET: dotnet-stack, native Server: thread apply all bt in gdb oder mit gcore eine Core-Datei schreiben und nach dem Neustart analysieren
Spricht dafür
Zwei oder mehr Threads hängen mit Stacks, in denen jeder auf den Lock des anderen wartet, und die CPU-Auslastung des Prozesses liegt währenddessen nahe 0
Spricht dagegen
Ein Thread läuft während des Stillstands mit 100 % CPU: Endlosschleife. Threads warten auf DB oder externe Antworten: eher synchrone Aufrufe oder ein erschöpfter Thread-Pool
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen
Runtime locking correctness validatorLinux kernel Werden zwei Locks in entgegengesetzter Reihenfolge genommen, entsteht durch zirkuläres Warten ein Deadlock (lock inversion deadlock), der Linux-Kernel prüft die Lock-Reihenfolge und warnt vorab
Liveness, Readiness, and Startup ProbesKubernetes Ein Deadlock, bei dem die Anwendung läuft, aber nicht vorankommt, wird per Liveness-Probe erkannt und der Container neu gestartet