Runnable 不适合作为 synchronized 锁对象，因其仅为任务逻辑载体，缺乏唯一性、长期存活性和显式共享性；真正应锁定的是共享资源本身（如 Account 实例）、其容器或显式定义的锁对象。
不能把 Runnable 实例当作锁对象来用。
为什么 Runnable 不适合作为 synchronized 锁对象
Runnable 是一个函数式接口，只定义了 run() 方法，本身不承载任何同步语义。它的实例通常用于描述任务逻辑，生命周期短、复用性低、创建随意——这些特性与“稳定、可预测、共享”的锁对象要求完全相悖。
常见错误写法：
- 多个线程各自 new 一个
MyTask implements Runnable，然后对this加锁 → 实际是不同对象，锁无效 - 将
Runnable对象传给线程池执行，再在别处用它做synchronized(obj)→ 对象可能已被 GC 或状态混乱 - 误以为“任务对象 = 资源对象”，用
Runnable封装的字段（如账户余额）做同步依据，却未对其所属的真正共享实体加锁
真正该锁定的对象是什么
锁的本质是“对同一份共享状态的互斥访问控制”。所以锁对象必须满足：唯一性、长期存活、显式共享。
立即学习“Java免费学习笔记（深入）”；
- 共享资源本身：比如
Account account = new Account("A001")，多个线程操作同一个account实例，就用它加锁 - 资源的容器或管理者：如
ConcurrentHashMap<String, Account> accounts，可用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 块内调用
