Marten项目中的文档类型重复生成问题解析

背景介绍

Marten是一个.NET平台上的PostgreSQL文档数据库和事件存储库。在使用过程中，开发者发现了一个与文档类型代码生成相关的内存问题，特别是在并行处理事件时表现尤为明显。

问题现象

当系统以并行方式批量处理事件时，每个批处理中的相同文档类型会被重复生成代码并加载到AppDomain中。例如，当批量大小为n时，同一文档类型的代码可能会被生成n次，导致应用程序内存消耗急剧增加，在某些情况下甚至达到数GB级别。

根本原因分析

问题的核心在于ProviderGraph类中的代码生成逻辑缺乏线程安全保护。具体表现为：

1. 多个线程可能同时检查_storage字典中是否已存在某类型的文档提供程序
2. 在发现不存在时，多个线程会同时进入代码生成流程
3. 代码生成完成后才会更新_storage字典
4. 这种竞态条件导致相同类型的代码被重复生成多次

解决方案探讨

临时解决方案

开发者发现可以通过以下方式暂时解决问题：

1. 预先注册所有需要的类型
2. 将代码生成模式设置为Auto

永久解决方案

经过讨论，项目维护者确认需要在ProviderGraph类中实现线程安全机制。具体实现方案考虑了几种选择：

1. 全局锁方案：使用单一锁对象保护整个代码生成过程

   • 实现简单直接
   • 可能成为性能瓶颈
   • 最终被采纳的方案

2. 类型级锁方案：为每种文档类型创建单独的锁对象

   • 理论上并发度更高
   • 实现复杂度增加
   • 维护成本较高
   • 未被采纳，因为项目维护者认为实际并发场景下性能差异不大

技术实现细节

在最终实现中，开发者在ProviderGraph类的StorageFor<T>方法中添加了锁机制：

private readonly object _locker = new();

public DocumentProvider<T> StorageFor<T>() where T : notnull
{
    var documentType = typeof(T);

    lock(_locker)
    {
        if (_storage.TryFind(documentType, out var stored))
        {
            return stored.As<DocumentProvider<T>>();
        }
        
        // 生成代码并更新_storage
        // ...
    }
}

这种实现确保了同一时间只有一个线程能够为特定类型生成代码，从根本上解决了重复生成的问题。

性能考量

虽然全局锁方案在理论上可能成为性能瓶颈，但实际应用中：

1. 代码生成通常只发生在应用启动阶段
2. 大多数情况下，文档类型会被缓存，不会频繁进入锁区
3. 锁的粒度足够细，不会影响其他不相关的操作

最佳实践建议

对于Marten使用者，建议：

1. 对于已知的文档类型，尽量预先注册
2. 合理设置代码生成模式
3. 监控应用内存使用情况，特别是处理大量并行事件时
4. 及时更新到包含此修复的Marten版本

总结

Marten项目通过引入简单的锁机制，有效解决了文档类型代码重复生成导致的内存问题。这个案例展示了在高并发环境下，即使是看似简单的资源访问也需要仔细考虑线程安全问题。同时，它也体现了开源项目中开发者与维护者之间的有效协作过程。