ASP.NET Core 缓存组件死锁问题分析与解决方案

在最新发布的 Microsoft.Extensions.Caching.StackExchangeRedis 9.0.3 版本中，开发团队发现了一个严重的依赖注入死锁问题。这个问题主要影响同时使用 HybridCache 和 RedisCache 的 ASP.NET Core 应用程序，会导致服务启动时陷入无限递归调用。

问题背景

HybridCache 是 ASP.NET Core 提供的一种混合缓存机制，它结合了本地内存缓存和分布式缓存的优势。RedisCache 则是基于 StackExchange.Redis 的分布式缓存实现。这两个组件通常会被一起使用，以构建高性能的缓存系统。

在 9.0.3 版本中，RedisCacheImpl 类新增了一个检查 HybridCache 是否存在的逻辑。这个看似无害的改动却引发了严重的运行时问题。

问题根源分析

问题的核心在于依赖注入容器的解析过程中出现了循环依赖：

1. RedisCacheImpl 构造函数会调用 IsHybridCacheDefined 方法
2. 该方法通过服务容器尝试解析 HybridCache 实例
3. HybridCache 的创建又需要 IDistributedCache 服务
4. IDistributedCache 的实现正是 RedisCacheImpl

这种相互依赖的关系导致容器在解析服务时陷入无限递归，最终耗尽调用栈资源。

技术细节

问题的关键代码在于 RedisCacheImpl 的实现：

internal sealed class RedisCacheImpl : RedisCache
{
    public RedisCacheImpl(IOptions<RedisCacheOptions> optionsAccessor, IServiceProvider services)
        : base(optionsAccessor)
    {
        HybridCacheActive = IsHybridCacheDefined(services);
    }

    private static bool IsHybridCacheDefined(IServiceProvider services)
        => services.GetService<HybridCache>() is not null;
}

这段代码在构造函数中直接尝试解析另一个可能依赖自身的服务，违反了依赖注入的最佳实践。

解决方案

开发团队已经采取了以下措施：

1. 紧急下架了 9.0.3 版本
2. 在代码库中修复了这个问题
3. 计划在 9.0.4 版本中包含修复

对于受影响的用户，目前可以采取的临时解决方案是：

1. 回退到 9.0.2 版本
2. 等待修复后的新版本发布

经验教训

这个事件给我们提供了几个重要的经验：

1. 在构造函数中避免直接解析可能产生循环依赖的服务
2. 单元测试需要考虑组件间的交互，不能只测试独立功能
3. 依赖注入容器虽然强大，但需要谨慎使用

最佳实践建议

为了避免类似问题，建议开发者在设计依赖注入时：

1. 将服务解析延迟到实际使用时，而非构造函数中
2. 考虑使用工厂模式或延迟加载机制
3. 编写集成测试覆盖关键组件的交互场景

这个问题虽然已经得到解决，但它提醒我们在使用现代框架的高级功能时需要更加谨慎，特别是在处理组件间依赖关系时。