FastEndpoints项目中的NullabilityInfoContext线程安全问题分析与修复

问题背景

在FastEndpoints项目的Swagger文档生成功能中，开发团队发现了一个与.NET运行时组件NullabilityInfoContext相关的线程安全问题。这个问题会导致在并发环境下生成Swagger文档时出现两种异常情况：

1. 键重复异常：当尝试向集合中添加已存在的键时抛出ArgumentException
2. 集合状态损坏异常：在非并发集合上执行并发操作时抛出InvalidOperationException

问题根源分析

经过深入调查，发现问题根源在于项目中使用了静态的NullabilityInfoContext实例来检查属性的可空性。NullabilityInfoContext是.NET运行时提供的一个API，用于分析类型和成员的可空性注释信息。

关键问题点在于：

• NullabilityInfoContext类本身不是线程安全的
• 项目中将其作为静态字段共享使用
• 在多线程环境下同时访问时会导致内部状态损坏

技术细节

在.NET生态中，NullabilityInfoContext的设计初衷是为编译时提供的可空性信息提供运行时访问能力。然而，微软官方文档明确指出这个类不是线程安全的，因为它内部维护了一些缓存状态。

FastEndpoints项目原本的实现方式是将NullabilityInfoContext实例作为静态字段共享使用，这在单线程环境下没有问题，但在多线程环境下（如并发生成Swagger文档时）就会导致问题。

解决方案

正确的解决方法是避免共享NullabilityInfoContext实例。开发团队采纳了以下修复方案：

internal static bool IsNullable(this PropertyInfo p)
{
    return new NullabilityInfoContext().Create(p).WriteState == NullabilityState.Nullable;
}

这种修改虽然会在每次调用时创建新的NullabilityInfoContext实例，看似有性能开销，但实际上：

1. 解决了线程安全问题
2. 对性能影响微乎其微，因为属性可空性检查不是高频操作
3. 符合.NET官方建议的使用模式

最佳实践建议

在处理类似的可空性分析场景时，开发者应当注意：

1. 避免共享非线程安全的分析器实例
2. 对于轻量级对象，优先考虑每次使用时创建新实例
3. 在性能敏感场景，可以考虑使用线程本地存储(TLS)来缓存实例
4. 仔细阅读.NET运行时API的线程安全保证文档

总结

FastEndpoints项目通过这次修复，解决了Swagger文档生成过程中的稳定性问题。这个案例也提醒我们，在使用.NET运行时提供的分析类API时，需要特别注意其线程安全特性，特别是在Web应用这种多线程环境下。正确的做法是遵循API设计者的意图，而不是盲目优化共享实例。