Java中Collections.SynchronizedList为何采用mutex同步而非同步方法？

你的猜测方向完全正确，基类继承体系的统一控制和精细同步粒度的预留是核心原因之一，除此之外还有几个关键的设计考量：

• 继承体系的同步一致性：SynchronizedList继承自SynchronizedCollection，这个基类已经定义了私有的mutex对象作为统一锁。如果子类改用同步方法（本质是锁当前对象this），会导致基类和子类的锁对象不一致，破坏整个继承体系的同步逻辑一致性——比如基类的方法用mutex锁，子类新增方法用this锁，就可能出现并发安全漏洞。用统一的mutex能让整个集合家族的同步控制保持统一。

• 预留精细同步的灵活性：虽然目前所有方法都是整个方法体包裹在同步块里，但这种设计给未来扩展留了余地。比如如果后续需要某个方法先做无锁的参数校验、预处理，再进入同步块操作集合，用mutex的方式可以轻松拆分同步粒度；而同步方法只能给整个方法加锁，没法实现部分逻辑的无锁优化。这是一种前瞻性的架构设计。

• 避免外部锁干扰风险：如果用同步方法，锁的是this（也就是SynchronizedList实例本身），外部代码有可能会把这个实例当作自己的锁对象来使用，这就会导致内部同步逻辑和外部锁操作互相干扰，甚至引发死锁。而mutex是内部私有对象，外部无法访问，完全隔离了内部同步和外部代码，从根源上避免了这种风险。

两种实现的直观对比 #

实现1（基于mutex的同步）：

public boolean doSomething(Collection<?> coll) { 
    synchronized (mutex) {
        return c.doSomething(coll);
    } 
}

实现2（同步方法）：

public synchronized boolean doSomething(Collection<?> coll) { 
    return c.doSomething(coll); 
}

需要补充的是，性能并不是这里的核心考量——两种同步方式的性能差异微乎其微，架构设计的安全性、一致性和灵活性才是这个选择的关键。

内容的提问来源于stack exchange，提问作者Sourabh