runnable 不适合作为 synchronized 锁对象,因其仅为任务逻辑载体,缺乏唯一性、长期存活性和显式共享性;真正应锁定的是共享资源本身(如 account 实例)、其容器或显式定义的锁对象。

不能把 Runnable 实例当作锁对象来用。
为什么 Runnable 不适合作为 synchronized 锁对象
Runnable 是一个函数式接口,只定义了 run() 方法,本身不承载任何同步语义。它的实例通常用于描述任务逻辑,生命周期短、复用性低、创建随意——这些特性与“稳定、可预测、共享”的锁对象要求完全相悖。
常见错误写法:
- 多个线程各自 new 一个
MyTask implements Runnable,然后对this加锁 → 实际是不同对象,锁无效 - 将
Runnable对象传给线程池执行,再在别处用它做synchronized(obj)→ 对象可能已被 GC 或状态混乱 - 误以为“任务对象 = 资源对象”,用
Runnable封装的字段(如账户余额)做同步依据,却未对其所属的真正共享实体加锁
真正该锁定的对象是什么
锁的本质是“对同一份共享状态的互斥访问控制”。所以锁对象必须满足:唯一性、长期存活、显式共享。
Java项目代码review工具。分析Git变更+完整调用链路上下文,推断业务需求,进行多维度评分和分类汇总,生成完整PRD文档。包含细粒度Java代码审查清单(Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 共享资源本身:比如
Account account = new Account("A001"),多个线程操作同一个account实例,就用它加锁 - 资源的容器或管理者:如
ConcurrentHashMap<string account> accounts</string>,可用accounts或accounts.get(id)(需确保不为 null)作为锁 - 显式定义的锁对象:private final Object lock = new Object(); —— 简洁、意图明确、无业务耦合
Runnable 中如何安全访问共享资源
Runnable 只负责定义执行逻辑,加锁动作应在 run() 内部完成,且锁定目标必须是外部传入或全局可见的共享对象。
正确示例:
class TransferTask implements Runnable {
private final Account from;
private final Account to;
private final BigDecimal amount;
TransferTask(Account from, Account to, BigDecimal amount) {
this.from = from;
this.to = to;
this.amount = amount;
}
@Override
public void run() {
// 锁定两个账户,避免死锁:按地址/ID顺序加锁
Object lock1 = from;
Object lock2 = to;
if (System.identityHashCode(from) > System.identityHashCode(to)) {
lock1 = to;
lock2 = from;
}
synchronized (lock1) {
synchronized (lock2) {
from.debit(amount);
to.credit(amount);
}
}
}
}
关键点:
- 锁对象是
from和to这两个真实账户实例,不是TransferTask自身 - 通过
System.identityHashCode统一加锁顺序,防止死锁 - Runnable 仅承载行为,不承担锁职责
使用 ReentrantLock 时同样不能依赖 Runnable 实例
和 synchronized 一样,ReentrantLock 必须作用于稳定的、跨线程可访问的锁对象上。
- 错误:在
Runnable构造时 new 一个ReentrantLock,每个任务独享一把锁 → 完全无互斥效果 - 正确:锁对象应由资源持有者管理,例如
Account类内部持有一个final ReentrantLock lock = new ReentrantLock();,所有操作都通过它同步 - 务必在
try { lock.lock(); ... } finally { lock.unlock(); }中使用,且lock()必须在 try 块内调用
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南










