Deadlock Deadlock

ID penyebab sp-deadlock · Penanggung jawab utama Pengembangan server (Tim Pengembang Game)

Buka kartu interaktif dengan gambar dan simulasi →

Jika dua thread saling menunggu lock yang dipegang thread lainnya, keduanya berhenti selamanya.

Mengapa Thread A memegang lock 1 dan menunggu lock 2, sedangkan thread B memegang lock 2 dan menunggu lock 1 → Akibatnya Keduanya berhenti selamanya, dan thread lain yang terkait ikut berhenti satu per satu → Di layar Seluruh server berhenti, lalu watchdog memulai ulang server sehingga semua pemain disconnect

Gejala: Freeze, Disconnect
Faktor: Stall
Siapa yang mengalami: Seluruh server, Fitur tertentu saja
Kapan: Sesekali secara acak, Saat banyak pemain berkumpul
Penanggung jawab: Penanggung jawab utama Pengembangan server (Tim Pengembang Game)
Tugas Tim Pengembang Game: Tetapkan aturan urutan pengambilan lock, pakai lock dengan timeout, pasang watchdog dan simpan thread dump pada saat server berhenti.
Di grafik: Koneksi putus serentak · Jumlah koneksi, volume kirim server
Yang diperiksa: Ambil call stack semua thread selama server berhenti. Gunakan jstack untuk JVM (otomatis menemukan dan menandai deadlock), dotnet-stack untuk .NET, dan thread apply all bt di gdb untuk server native, atau ambil core file dengan gcore, mulai ulang server, lalu analisis
Cocok jika: Dua thread atau lebih berhenti dengan stack yang saling menunggu lock yang dipegang thread lainnya, dan selama itu utilisasi CPU proses mendekati 0
Tidak cocok jika: Selama server berhenti, satu thread terus berputar dengan CPU 100%: infinite loop. Thread-thread menunggu respons DB atau layanan eksternal: lebih mungkin pemanggilan sinkron atau thread pool habis
Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game)

Sumber

Runtime locking correctness validator Linux kernel
Jika dua lock diambil dengan urutan yang berlawanan, terjadi penantian melingkar sehingga muncul deadlock (lock inversion deadlock); kernel Linux memeriksa urutan lock dan memberi peringatan lebih awal
Liveness, Readiness, and Startup Probes Kubernetes
Kondisi deadlock, yaitu proses masih berjalan tetapi tidak bisa maju, dideteksi oleh liveness probe lalu container dimulai ulang
Diagnostic Tools (Java SE 21 Troubleshooting Guide) Oracle
jstack mencetak stack semua thread di JVM yang sedang berjalan, sekaligus menemukan dan menandai deadlock (Found one Java-level deadlock)
dotnet-stack diagnostic tool - .NET CLI Microsoft
Menangkap dan mencetak managed stack semua thread di proses .NET
Threads (Debugging with GDB) GNU Project
thread apply all menjalankan perintah yang sama (bt: mencetak call stack) di semua thread
gcore(1) — Linux manual page gdb
Membuat core file dari program yang sedang berjalan; setelah itu program tetap berjalan seperti biasa

Lihat juga

Lapisan yang sama: L9 Proses game di server

Penyebab di lapisan lain dengan gejala yang sama (Freeze)

Lonjakan frame time L1 Proses game di klien
Garbage collection di klien L1 Proses game di klien
Pemuatan sinkron dan kompilasi shader di main thread L1 Proses game di klien
Streaming aset tertinggal akibat storage lambat L1 Proses game di klien
Pemindaian oleh modul keamanan game (anti-cheat) L1 Proses game di klien
Perpindahan Wi-Fi ↔ LTE/5G L2 OS dan perangkat klien
Kekurangan memori dan swap di klien L2 OS dan perangkat klien
Kekurangan memori grafis (VRAM) L2 OS dan perangkat klien

Lihat kartu interaktif dengan gambar dan simulasi