移除类方法全局锁改用参数锁是否安全？有哪些风险？

我正在维护一个类A，其中两个方法F1和F2的部分代码使用同一个全局锁o，代码如下：

class A
{
    private readonly object o = new object();
    public void F1(B b)
    {
        ...
        lock (o)
        {
            ...
            b.Data.Add(...);
            ...
        }
        ...
    }
    public void F2(B b)
    {
        ...
        lock (o)
        {
            ...
            b.Data.Add(...);
            ...
        }
        ...
    }
}

当前即使操作不同的B实例，锁定代码段也无法并发执行，且锁定段仅修改参数b的状态，不读写任何外部状态。

为保护参数访问，我计划改用如下锁方式：

lock(b)
{
    ...
}

注意每个B实例的Data属性唯一且仅在此处修改，锁定段内还会修改b的其他属性，锁定b可保证操作的原子性。现提出两个问题：

1. 是否可以安全移除全局锁o，改用更细粒度的参数锁？
2. 如果不行，可能存在哪些陷阱？

1. 是否可以安全替换？ #

只要符合下面这些前提，完全可以安全移除全局锁o，改用lock(b)的细粒度锁：

• 所有对B实例状态的修改（包括Data和其他属性），只在A类的F1、F2方法的锁块内进行，没有其他任何代码路径会修改B的状态；
• 外部代码不会对同一个B实例加锁，也不会执行任何可能和F1/F2冲突的操作；
• B的实例不会被用作其他同步逻辑的锁对象。

你的场景里明确说了B的Data仅在此处修改，锁块也只操作b的状态，只要外部没有对B实例的并发修改或额外锁操作，替换后既能保证操作的原子性，还能让不同B实例的操作并发执行，提升性能。

2. 可能存在的陷阱 #

如果不满足上述前提，替换后会踩这些坑：

• 线程安全问题：如果有其他代码（不在A的F1/F2里）也修改同一个B实例的状态，且没使用lock(b)同步，会导致Data集合并发修改异常、属性值错乱等问题；
• 死锁风险：如果外部代码也对B实例加锁，同时还持有其他锁，而你的F1/F2在lock(b)之后又尝试获取其他锁，就会形成循环等待，触发死锁；
• 锁失效：如果B实例的引用被其他代码意外替换（比如某个地方把传入的b指向了新对象），基于原对象的锁就会失效，无法保护新对象的状态；不过如果B实例是不可变引用（传入后不会被重新赋值），这个问题就不存在；
• 重入逻辑混乱：如果F1或F2在lock(b)的代码块里间接调用了自身或另一个方法（比如F1里调用F2），虽然lock是可重入的，但如果外部也有类似嵌套锁逻辑，可能会导致同步行为不符合预期，不过这个风险相对较低。

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