最近看到文章的回复，让我想起一个真实发生的案例，下面就简单说说这个关于lock引用类型的一个不容易发现的隐藏缺陷。

某类库中的代码，封装了很简单的一个通用类，用于线程安全地执行某一种类型的特定方法，几行代码搞定：

public class ConcurrentObjectExecutor
     
       where T : IDisposable, new()    {        public void Start()        {            T obj = new T();            lock (obj)            {                Console.WriteLine(obj.ToString());                //do sth            }        }    }
     

 

设计这个类，估计本来主要是针对继承自特定接口的类型能够线程安全地执行某一个方法。如果泛型类型T为类（class），则程序运行没有任何问题，也能保证线程安全。

但是我们知道泛型约束只有继承自接口和new还远远不能保证T就是一个class，结构（struct）也可以继承接口，也可以new。比如自定义一个结构：

struct OrderMessger : IDisposable    {        public void Dispose()        {        }    }

 

下面的代码可以编译通过，运行时也不会抛出异常（如果不看上下文，多数调用者估计就这么让它过去，很可能成为今后一个潜在的隐藏很深的bug）：

var executor = new ConcurrentObjectExecutor
     
      ();     executor.Start();
     

 

很显然，上面的泛型程序看上去是lock了一个结构，也就是锁定了一个值类型。但是我们知道，lock关键字指定的锁定对象必须是引用类型。上面的示例中，实际情况是将结构实例obj隐式转换成了一个引用对象实例(也就是装箱，每次装箱都生成了一个新的实例)，这样的lock是毫无意义的，因为在多线程的条件下，线程争用的obj已经不是指定的同一个实例(的引用)。

比较搞笑的是，直接写下面的代码，编译时直接在lock语句上报告有错误（编译时检测真是帮了大忙，ms为什么不把泛型检测搞的更智能些？）：

var obj = new OrderMessger();            lock (obj)            {            }

 

错误    1    “OrderMessger”不是 lock 语句要求的引用类型 

解决的方法也很简单，泛型约束在原来的基础上再限定必须是class即可。

最后总结下：类库设计中，越是通用的东西考虑的应用场景越要周到，其中线程安全是非常重要必不可少的一个环节，线程安全实现过程中，如果对多线程同步原语理解不够深刻，很可能设计出有潜在缺陷的实现，MSDN关于Thread Safe的调用和说明值得类库开发者深刻学习和借鉴。