LiteDB中的BsonMapper并发问题分析与修复

问题背景

在LiteDB 5.0.21版本中，当使用DeleteMany方法执行包含Contains条件的查询时，偶尔会出现"Member Id not found on BsonMapper"的异常。这个问题在多线程环境下尤为明显，特别是在并发访问不同集合但使用相同类型的情况下。

问题根源分析

经过深入分析，这个问题源于BsonMapper类中的线程安全问题。具体来说，当多个线程同时尝试获取和构建实体映射器(EntityMapper)时，会出现竞态条件：

1. 线程A进入GetEntityMapper方法，发现映射器不存在
2. 线程A开始构建映射器并添加到字典中
3. 在线程A完成映射器构建前，线程B进入GetEntityMapper方法
4. 线程B获取到未完全初始化的映射器并尝试使用，导致成员查找失败

技术细节

问题的核心在于映射器的构建过程不是原子性的。原始代码在将映射器添加到字典后才完成成员的初始化，这为竞态条件创造了机会。具体表现为：

// 线程A
var mapper = new EntityMapper(type);
_entities[type] = mapper;  // 映射器被添加到字典但尚未初始化
// 线程B此时可以获取到这个未初始化的映射器
mapper.Build(this);        // 实际初始化成员

解决方案

修复方案需要确保映射器的完整构建过程对其它线程不可见，直到完全初始化。有两种可行的实现方式：

1. 完全同步方案：在获取和构建映射器时使用锁机制，确保操作的原子性。这种方法简单可靠，但可能带来一定的性能开销。

2. 双重检查锁定模式：在锁外先检查一次，锁内再检查一次，减少锁竞争。这种方法性能更好但实现稍复杂。

最终采用了第一种方案，因为"稳定性优于性能"的原则。修复后的代码确保映射器完全初始化后才对其他线程可见，从根本上消除了竞态条件。

影响与启示

这个案例展示了在多线程环境下共享数据结构时常见的陷阱。即使看似简单的"检查-构建-存储"模式，如果没有适当的同步机制，也可能导致难以追踪的并发问题。对于数据库访问层这样的基础组件，稳定性应当始终是首要考虑因素。

最佳实践建议

1. 在多线程环境中使用LiteDB时，应考虑使用最新版本
2. 对于高并发场景，可以预先初始化所有需要的映射器
3. 考虑使用连接池或限制并发访问数量来减轻系统负载
4. 在应用启动时执行所有可能用到的查询，触发必要的映射器初始化

这个问题的修复体现了开源社区协作的价值，通过用户反馈和开发者响应的良性互动，共同提升了软件的可靠性。