Si dos hilos esperan cada uno el lock que tiene el otro, se quedan detenidos para siempre.
Por qué El hilo A tiene el lock 1 y espera el lock 2; B tiene el lock 2 y espera el lock 1 → Efecto Los dos se quedan detenidos para siempre, y los hilos relacionados también se detienen uno tras otro → En pantalla Todo el servidor se detiene y, cuando el watchdog lo reinicia, se desconecta a todos los jugadores
De vez en cuando, al azar, Cuando se junta mucha gente
Responsable
Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Definir un orden fijo para adquirir los locks, usar locks con timeout, tener un watchdog y guardar un volcado de hilos en el momento de la detención.
En el gráfico
Desconexión masiva · Número de conexiones, volumen enviado por el servidor
Dónde mirar
Pilas de llamadas de todos los hilos durante la detención. En la JVM, jstack (detecta y marca los deadlocks automáticamente); en .NET, dotnet-stack; en servidores nativos, thread apply all bt de gdb, o generar un archivo core con gcore, reiniciar y analizarlo después
Se confirma si
Dos o más hilos están detenidos con pilas que esperan el lock que tiene el otro, y mientras tanto el uso de CPU del proceso está cerca de 0
Se descarta si
Si durante la detención un hilo gira al 100% de CPU, es un bucle infinito. Si los hilos esperan respuestas de la BD o de servicios externos, apunta a llamadas síncronas o a “Agotamiento del pool de hilos”
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Fuentes
Runtime locking correctness validatorLinux kernel Adquirir dos locks en orden inverso provoca una espera circular y un deadlock (lock inversion deadlock); el kernel de Linux comprueba el orden de los locks y avisa de antemano
Liveness, Readiness, and Startup ProbesKubernetes Detectar con una sonda de liveness un deadlock (el proceso se ejecuta pero no avanza) y reiniciar el contenedor