初学者写并发代码易死锁，核心在于缺乏对锁获取顺序、持有范围和资源依赖的结构化认知，导致满足死锁四条件；具体表现为锁嵌套顺序不统一、锁内调用外部不可控逻辑、忽视复合资源竞争。

初学者写并发代码时容易写出死锁，核心原因不是“忘了判断锁边界”这个说法本身准确——锁没有传统意义上的“边界”可判；而是**对锁的获取顺序、持有范围和资源依赖关系缺乏结构化认知**，导致无意中满足了死锁四条件。 下面从三个实际开发中最常踩坑的角度讲清楚：

锁的嵌套顺序不统一

两个线程分别按不同顺序获取同一组锁，是死锁最直接的导火索。比如线程A先lock1再lock2，线程B却先lock2再lock1。只要二者执行时机交错，就立刻卡死。

• 初学者常把加锁逻辑散落在不同方法里，比如DAO层各自加自己的锁，没约定全局顺序
• 看到“synchronized(obj)”就加，不关心obj之间是否存在隐含依赖链
• 用String或Integer作锁对象时，因字符串常量池或自动装箱导致实际锁对象意外复用或错位

锁内调用外部不可控逻辑

在持有锁期间调用可能阻塞或反向请求锁的方法（如远程调用、数据库查询、回调函数），等于把锁的生命周期交给了不可预测的外部路径。

Facetune

Facetune是一款集自拍修图、AI 头像和创意照片编辑于一体的移动影像工具。

下载

• 常见写法：synchronized(this) { service.doSomething(); } ——而doSomething()内部又去拿另一个锁
• 日志打印、异常处理、甚至toString()都可能触发间接锁竞争（尤其在ORM或代理对象中）
• 没意识到synchronized方法体 = 整个方法持锁，哪怕只有一行真正需要同步

误信“单个锁不会死锁”，忽视复合资源竞争

初学者觉得“我只用一个锁，肯定不会死锁”，但现实中的资源不止是Java对象锁：数据库行锁、文件句柄、信号量、第三方API配额，甚至线程池任务队列本身，都可能成为循环等待链条的一环。

• 例如：线程1持数据库锁更新用户余额，再试图发MQ消息；线程2持MQ发送线程池锁，再查数据库校验状态——两者形成跨系统等待闭环
• Redis分布式锁 + MySQL本地事务混合使用时，未对锁粒度和超时做对齐，极易出现一方已释放、另一方还在等的“伪死锁”
• 用CountDownLatch或CyclicBarrier做协调，却在await()前没释放已有锁，造成阻塞+持有并等待

本质上，死锁不是“漏写了某行判断”，而是**并发设计缺乏资源视图**：没提前画出“谁要什么、谁持有什么、谁等谁”的依赖图。一旦多个协作单元上线，局部正确叠加起来，就自然涌现出全局僵局。