LiteDB多线程并发访问数据库时的NullReferenceException问题分析

问题背景

在使用LiteDB数据库时，当多个线程同时调用GetCollection方法访问数据库时，可能会抛出NullReferenceException异常。这个问题源于LiteDB内部对字典数据结构的不安全并发访问。

问题根源

在LiteDB 5.0.21版本中，BsonMapper类使用了一个普通的Dictionary来缓存实体映射器(_entities)。当多个线程同时尝试获取或创建实体映射器时，会出现读取和写入字典的竞争条件。由于Dictionary不是线程安全的数据结构，这种并发访问会导致不可预测的行为，包括NullReferenceException。

问题复现

通过以下方式可以稳定复现该问题：

1. 创建多个线程(20个或更多)
2. 让这些线程同时调用GetCollection方法
3. 使用不同类型的实体类(20种或更多)
4. 在Release模式下运行

复现代码的关键在于确保所有线程几乎同时开始执行，并且访问足够多的不同类型以增加竞争条件的概率。

技术分析

问题的核心在于BsonMapper.GetEntityMapper方法中的这段代码：

if (_entities.TryGetValue(type, out mapper)) return mapper;

lock (_cache)
{
    if (_entities.TryGetValue(type, out mapper)) return mapper;

    // 创建mapper的逻辑...

    _entities[type] = mapper;
    return mapper;
}

虽然使用了锁来保护创建mapper的过程，但在锁外部有一个无保护的TryGetValue调用。这种双重检查锁定模式在Dictionary不是线程安全的情况下存在问题。

解决方案

最直接的解决方案是将_entities的类型从Dictionary改为ConcurrentDictionary。ConcurrentDictionary是专门设计用于多线程场景的线程安全集合，可以安全地处理并发读写操作。

修改后的代码可以完全消除这个竞争条件，因为ConcurrentDictionary内部已经处理了所有必要的同步。

影响范围

这个问题主要影响以下场景：

• 高并发应用程序
• 使用多线程访问LiteDB的程序
• 需要频繁创建新集合或访问不同类型实体的应用

最佳实践

为了避免类似问题，开发人员在使用LiteDB时应注意：

1. 对于高并发应用，考虑使用最新版本的LiteDB
2. 如果必须使用旧版本，可以考虑实现自己的线程安全包装器
3. 尽量减少在运行时动态创建新类型集合的需求
4. 考虑在应用启动时预先注册所有需要的实体类型

结论

多线程环境下的资源同步是数据库访问层设计中的重要考虑因素。LiteDB通过使用ConcurrentDictionary替代普通Dictionary解决了这个特定的并发问题，为开发者提供了更稳定可靠的数据库访问体验。理解这类问题的根源有助于开发者在设计自己的系统时避免类似的并发陷阱。