死锁原理与实战：从数据库到多线程的解决方案

1. 死锁现象的本质剖析

死锁就像两个固执的人在狭窄的走廊里迎面相遇，谁也不肯让路。在计算机系统中，当两个或多个进程（或线程）互相持有对方需要的资源，同时又等待对方释放自己所需的资源时，就会陷入这种"你不放，我不走"的僵局。这种状态一旦形成，所有相关进程都会被永久阻塞，除非外力介入。

死锁的四个必要条件（Coffman条件）必须同时满足：

1. 互斥条件：资源一次只能被一个进程独占使用
2. 占有并等待：进程持有至少一个资源，同时等待获取其他被占用的资源
3. 非抢占条件：已分配给进程的资源不能被强制剥夺
4. 循环等待条件：存在一个进程等待的环形链

实际案例：在电商系统中，用户A的订单要扣减库存X和Y，用户B的订单也要扣减相同的库存，但获取顺序相反（A先锁X再锁Y，B先锁Y再锁X）。当两者同时执行时，就可能形成死锁。

2. 数据库死锁的实战诊断

2.1 SQL Server死锁检测

SQL Server提供了完善的死锁监测工具链：

sql复制-- 启用死锁跟踪标志
DBCC TRACEON (1222, -1)  -- 将死锁信息写入错误日志
DBCC TRACEON (1204, -1)  -- 在SQL Server日志中记录死锁详情

-- 查询当前死锁信息
SELECT * FROM sys.dm_tran_locks 
WHERE request_status = 'CONVERT'

更直观的方式是使用SQL Server Profiler捕获死锁图：

1. 新建跟踪 → 事件选择 → 勾选"Deadlock graph"
2. 运行跟踪，死锁发生时自动生成XML格式的死锁信息
3. 将死锁图保存为.xdl文件后用SSMS打开可视化分析

2.2 MySQL死锁排查方案

MySQL通过以下命令暴露死锁信息：

sql复制-- 查看最近发生的死锁信息
SHOW ENGINE INNODB STATUS\G
-- 重点观察"LATEST DETECTED DEADLOCK"部分

-- 开启innodb_print_all_deadlocks记录所有死锁
SET GLOBAL innodb_print_all_deadlocks=1;

对于高频死锁，建议使