I once had a bug in a multi‑threaded file‑upload service that would sometimes leave the server hanging for minutes. The code used a global mutex to protect a shared queue, but a stray `unlock()` inside a `finally` block was sometimes executed before the `lock()`, causing the queue to become unlocked when the worker thread still tried to read from it. The symptom was a random “deadlock” that only happened on a specific machine with a particular CPU core frequency. I spent hours stepping through the logs, watching the thread states on a debugger, and adding a tiny sanity check that logged every acquire and release. Once the check caught the rogue unlock, I could re‑order the critical section, add a try/finally pair that always matched, and the chaos vanished. The lesson? In concurrent code, even a single misplaced lock can turn a predictable system into a nightmare.

Yeah, lock order is a real pain, but the log was my lifesaver—couldn't have found that race without it. Will keep the debug log rolling, even on the quiet nights when the code feels fine.