Java中synchronized在内外类互锁时存在死锁隐患，根源在于this与outer.this混用导致循环等待；应统一用私有final锁对象，避免跨层调用同步方法，并用jstack按锁地址排查。

Java 中 synchronized 在内部类与外部类互相加锁时，确实存在隐蔽但高发的死锁隐患——核心问题不是“能不能锁”，而是**锁对象混用 + 隐式持有顺序不一致**导致的循环等待。

隐患根源：this 与 outer.this 容易被当成两把独立锁

内部类天然持有对外部类实例的引用（OuterClass.this），而开发者常不自觉地在两处用不同锁对象：

• 外部类方法用 synchronized(this) 或 synchronized 实例方法 → 锁的是外部类实例
• 内部类方法也用 synchronized(this) → 锁的是内部类实例（和外部类实例不是同一个对象）
• 更危险的是：内部类里又调用了外部类的同步方法，或显式 synchronized(outerInstance)

一旦线程 A 先锁住外部实例、再进内部类尝试锁内部实例；线程 B 反过来先锁内部实例、再调用外部同步方法，就构成标准的 A→B、B→A 循环等待链。

典型触发场景：匿名内部类+回调+同步方法

比如事件监听器中常见写法：

• 外部类有个 public synchronized void updateState()
• 内部类（如 Listener）里有 synchronized(this) { ... updateState(); }
• 同时外部类某个地方又在 synchronized(this) 块里调用了内部类的某个同步方法

这时看似“一个类一个锁”，实则锁了两个不同对象，且调用路径形成闭环。JVM 不会识别这种逻辑依赖，只按对象地址判别锁，结果就是静默卡死。

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

安全实践：统一锁粒度，避免跨层隐式锁

关键不是禁用内部类，而是切断锁对象的随意性：

• 对外部类状态保护，统一使用一个私有 final 锁对象：private final Object stateLock = new Object();，所有内外部临界区都用它，不碰 this
• 内部类如需同步，直接复用该锁对象（传入或通过 outer 引用访问），而不是用自己的 this
• 绝对避免在 synchronized 块内调用外部类的 synchronized 方法——这等于嵌套持锁，极易引入未知等待链
• 若必须分层控制，改用 ReentrantLock 配合 tryLock(timeout)，失败立即释放已持锁并退避，不硬等

排查建议：jstack 看锁对象地址，别只盯类名

发生卡顿时，用 jstack 搜索 Found 1 deadlock 后，重点看：

• 每个线程持有的锁对象地址（如 0x0000000800a1b2c0）是否不同
• 等待的锁地址是否恰好是另一个线程持有的地址
• 堆栈中是否出现 OuterClass$InnerClass.method → OuterClass.synchronizedMethod 这类跨层调用

只要发现两个线程分别持有一个内部类实例和一个外部类实例的锁，并互相等待，基本可断定是 this 混用引发的死锁。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南