怎样用一个项目场景说明 Java 并发、锁和 Binder 死锁？

标准回答

可以用“持锁发起同步跨进程调用，对端又回调并等待同一把锁”解释等待环。设计上缩小锁范围，不在锁内执行不可控的远程调用；异步结果回来后再检查当前状态。具体项目是否发生过该问题，要如实区分。

线程 A 持锁 L 并等待服务 B；B 回调线程 C，C 也需要 L，B 又要等 C 完成才能回复 A。这时仅增加线程数无法消除等待环。

**先画谁在等谁：**记录线程 A 持有哪些锁、等待哪个对端，对端又依赖什么资源。发现闭环比只说“主线程卡住”更接近根因。

**理解可见性与原子性：**volatile 可用于特定可见性需求，但不能自动让“读取状态、判断、修改”成为不可分割的操作。多个字段的一致更新需要相应同步设计。

**把取消也当状态变化：**任务取消后，后台和 Binder 回调可能仍到达；用会话或版本校验避免旧结果覆盖当前状态，不能只加一个任意布尔值。

单个操作线程安全不代表跨多个操作或多个字段的业务不变量自动成立。

要找到稳定的相互等待关系和持锁对象，而非仅凭一次长耗时判断。

不要把 volatile 当作互斥锁，也不要把所有 Binder 阻塞都叫死锁。