System.Linq.Dynamic.Core 中的常量表达式缓存竞争条件问题解析

问题背景

在 System.Linq.Dynamic.Core 这个强大的动态 LINQ 查询库中，开发团队发现了一个潜在的竞争条件问题，主要出现在常量表达式处理模块中。这个问题可能导致在特定并发场景下表达式解析失败，特别是当涉及到数值类型转换时。

问题本质

该问题的核心在于 ConstantExpressionHelper 类中的双重缓存机制：

1. _expressions 缓存：存储值到表达式对象的映射
2. _literals 缓存：存储表达式对象到其文本表示的映射

这两个缓存都使用了 SlidingCache 实现，具有自动清理过期项的功能。当缓存清理线程在特定时间点介入时，可能导致 _literals 缓存被清理而 _expressions 缓存仍然存在，从而破坏了数据一致性。

问题表现

在实际应用中，这个问题最常表现为类型转换失败。例如：

// 当解析这样的表达式时
"Variable < 0.40"

系统会抛出异常：

Operator '<' incompatible with operand types 'Decimal?' and 'Double'

这是因为在类型提升(Promote)过程中，系统无法获取原始文本表示，导致无法正确执行类型转换。

技术细节分析

问题的具体发生流程如下：

1. 线程A调用 CreateLiteral(value, text) 方法，同时更新两个缓存
2. 缓存清理线程运行，根据配置的 CleanupFrequency 和 TimeToLive 清理过期项
3. 线程B调用 Promote() 方法尝试获取文本表示时失败
4. 类型转换无法完成，导致表达式解析失败

解决方案

针对这个问题，开发团队提出了几种可行的解决方案：

1. 缓存一致性保障：确保 _expressions 和 _literals 缓存的清理保持同步
2. 回退机制：当 _literals 缓存缺失时，从 _expressions 重建文本表示
3. 缓存配置优化：调整默认的缓存生存时间和清理频率

在实际修复中，团队采用了组合策略，既增强了缓存一致性，又添加了可靠的文本重建机制。

临时解决方案

对于急需解决问题的开发者，可以临时调整缓存配置：

var parsingConfig = new ParsingConfig()
{
    ConstantExpressionCacheConfig = new CacheConfig
    {
        CleanupFrequency = TimeSpan.FromDays(3650), // 10年
        TimeToLive = TimeSpan.FromDays(3650)       // 10年
    }
};

但需要注意，这种配置可能导致内存持续增长，不适合长期使用。

最佳实践建议

1. 及时更新到包含修复的版本
2. 在并发量大的场景中，合理评估缓存配置
3. 对于关键业务逻辑，考虑实现自定义的常量表达式处理器

总结

这个问题展示了在并发环境下缓存一致性的重要性。System.Linq.Dynamic.Core 团队通过细致的分析和多角度的解决方案，不仅修复了当前问题，也为类似场景提供了设计参考。理解这类问题的本质有助于开发者在自己的项目中更好地处理并发和缓存相关的挑战。