非静态内部类隐式持有外部类实例导致锁竞争，应改用静态内部类、私有final锁对象及ReentrantLock.tryLock()规避死锁。
内部类本身不会直接导致死锁，真正的问题在于非静态内部类隐式持有外部类实例（this$0），当这个外部实例又被用于同步控制（比如用 synchronized(this) 或同步方法），就可能让多个线程因争夺同一把锁而串行阻塞，甚至在嵌套调用中触发循环等待——这才是死锁隐患的根源。
统一使用私有 final 锁对象，不依赖 this
外部类不要用 this 作为锁，否则非静态内部类一旦访问同步方法或块，就会间接参与同一把锁的竞争。应声明独立锁对象：
private final Object stateLock = new Object();- 所有临界区都用
synchronized(stateLock)，包括内部类中需要同步的逻辑 - 避免在 synchronized 块内调用外部类的 synchronized 方法，防止隐式嵌套持锁
优先用静态内部类切断引用链
静态内部类不生成 this<p>静态内部类不生成 <code>this$0 字段，天然不持有外部实例，也就不会把外部对象拖入锁竞争范围：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 把
class Worker implements Runnable改为static class Worker implements Runnable - 如需访问外部状态，通过构造参数显式传入必要数据（如配置、回调接口），而非依赖隐式
this - 传入的对象尽量用不可变类型（
final字段 + 无修改方法），或包装成WeakReference防止内存滞留
避免构造期启动线程或注册监听器
在外部类构造函数里创建并启动非静态内部类线程，会导致 this 在未初始化完成时就被子线程看到，既危险又易引发锁序混乱：
立即学习“Java免费学习笔记（深入）”；
- 禁止写
new Thread(new Runnable() { ... }).start();这类代码在构造器中 - 改用两阶段初始化：先完成对象构建，再调用
init()或startAsync()方法启动任务 - 注册回调或监听器时，确保外部实例已完全就绪且线程安全
用 ReentrantLock.tryLock() 主动规避等待
当无法完全避免多层锁依赖时，放弃内置锁的“硬等”机制，改用可超时的显式锁：
- 用
ReentrantLock替代synchronized，配合tryLock(100, TimeUnit.MILLISECONDS) - 获取失败时释放已持锁并退避重试，不陷入无限 BLOCKED
- 注意每次成功加锁后，必须在
finally中调用unlock()
