JetCache本地缓存LinkedHashMap写锁未释放问题分析与解决方案

问题背景

在使用阿里巴巴开源的JetCache框架时，部分用户遇到了一个较为隐蔽的问题：当配置本地缓存使用LinkedHashMap实现时，在某些特定场景下会出现写锁未被释放的情况，导致后续读操作线程阻塞，最终引发服务异常。

问题现象

从实际生产环境的线程堆栈分析可以看到：

1. 清除本地缓存的线程持有了写锁（ReentrantReadWriteLock.WriteLock）但未释放
2. 大量读取线程处于WAITING状态，等待获取读锁
3. 服务线程资源被占满，健康检查失败，服务不可用

问题分析

缓存配置分析

典型的JetCache配置如下：

jetcache:
  local:
    default:
      type: linkedhashmap
      limit: 100
      expireAfterWriteInMillis: 600000
      expireAfterAccessInMillis: 300000

配置中明确指定了本地缓存使用LinkedHashMap实现，并设置了缓存项数量上限为100，以及写入后和访问后的过期时间。

锁机制实现

JetCache中LinkedHashMapCache的内部实现使用了一个LRUMap类，它通过ReentrantReadWriteLock来保证线程安全：

1. 读操作获取读锁
2. 写操作获取写锁
3. 清理过期条目操作也获取写锁

所有锁操作都遵循了try-finally模式，理论上不存在锁泄漏的可能性。

问题根源推测

尽管代码实现看起来没有问题，但实际运行中仍出现了锁未被释放的情况。可能的原因包括：

1. GC停顿：在执行cleanExpiredEntries方法时发生长时间的GC停顿，导致锁持有时间异常延长
2. JVM Bug：极少数情况下JVM对锁的实现可能出现问题
3. 锁竞争异常：虽然配置了limit=100，但实际缓存项可能远超过此限制
4. 特殊环境因素：测试环境中某些未知干扰因素

解决方案

临时解决方案

对于遇到此问题的用户，可以采用以下临时解决方案：

1. 将本地缓存实现从linkedhashmap切换为caffeine：

jetcache:
  local:
    default:
      type: caffeine

Caffeine作为高性能缓存库，其锁实现更加健壮，且经过了大规模生产验证。

长期建议

1. 监控缓存使用情况：增加对本地缓存大小、命中率等指标的监控
2. 合理设置缓存参数：
   • 根据业务特点设置合适的localLimit
   • 设置合理的过期时间，避免缓存永久有效
3. 压力测试：在测试环境模拟高并发场景，验证缓存实现的稳定性
4. 版本升级：关注JetCache新版本，及时修复已知问题

技术思考

这个问题引发了对缓存实现选择的深入思考：

1. 简单vs复杂实现：LinkedHashMapCache设计简单，不引入额外依赖，适合简单场景
2. 生产级需求：对于高并发生产环境，成熟的缓存库如Caffeine更为可靠
3. 锁粒度优化：可以考虑更细粒度的锁策略来减少竞争

总结

JetCache作为优秀的缓存抽象框架，为开发者提供了多种缓存实现选择。在实际使用中，需要根据业务场景和性能要求选择合适的实现方式。对于高并发、高可用的生产环境，推荐使用经过充分验证的Caffeine实现，以获得更好的性能和稳定性。同时，合理的缓存配置和监控也是保证系统稳定运行的关键因素。