一个并发环境下的BUG分析

今天接手一个并发压力下的一个BUG，程序报：“字典中已经添加了重复的键”，出错的代码如下：

lock (connectionList)
{
    // Next we'll see if there is already a connection. If not, we'll create a new connection and add it
    // to the transaction's list of connections.
    // This collection should only be modified by the thread where the transaction scope was created
    // while the transaction scope is active.
    // However there's no documentation to confirm this, so we err on the safe side and lock.
    if (!connectionList.TryGetValue(db.ConnectionString, out connection))
    {
        // we're betting the cost of acquiring a new finer-grained lock is less than 
        // that of opening a new connection, and besides this allows threads to work in parallel
        var dbConnection = db.GetNewOpenConnection();
        connection = new DatabaseConnectionWrapper(dbConnection);
        connectionList.Add(db.ConnectionString, connection);
    }
    connection.AddRef();
}

这段代码是企业库的一段代码（参见：http://entlib.codeplex.com/SourceControl/changeset/view/90009#526470）

那个Add方法出错的，我得承认，我花了很长时间想这段代码在哪种情况下会造成锁定失败呢？怎么可能有两个线程进来。你看出来了吗？

好吧，答案是，问题并不是在lock上，而是在两次调用db.ConnectionString上。

在并行环境下，外界错误的使用了静态变量共享了IDatabase实例（这个db对象），这是主因。但是在这段代码中，判断字典是否存在某个key时使用了db.ConnectionString获取，但很不幸，在并行环境下，这个静态共享的db对象被其他线程替换成了另外一个连接字符串，于是在Add时，使用了另外一个字符串作为key,又不幸的是，字典中已经存在了此键。

修改的方法当然是先取消外部静态共享IDatabase对象。但这个地方也不妥，严密的代码应该是：

string key = db.ConnectionString;
lock (connectionList)
{
    // 使用同一个Key值，而不是两次访问属性，可能不一致。
    if (!connectionList.TryGetValue(key, out connection))
    {
        var dbConnection = db.GetNewOpenConnection();
        connection = new DatabaseConnectionWrapper(dbConnection);
        connectionList.Add(key, connection);
    }
    connection.AddRef();
}

总结：

1、慎用静态变量，他经常是内存泄露、并发冲突的元凶；