Apache Log4j2 内部日志注册表死锁问题深度分析

问题背景

Apache Log4j2 作为 Java 生态中广泛使用的日志框架，其内部实现机制对系统稳定性至关重要。近期在 2.24.2 及以上版本中出现的 InternalLoggerRegistry 死锁问题引起了开发者社区的广泛关注。这个问题在多线程环境下尤为突出，特别是在使用虚拟线程(Virtual Threads)或高并发场景中。

问题现象

当应用程序在启动或运行过程中，特别是在以下场景时容易出现线程阻塞：

1. 使用 Spring Kafka 并配置大量虚拟线程进行消息生产
2. 使用 ZooKeeper 进行动态日志级别配置
3. 在 Infinispan 等分布式系统中进行集群操作

线程转储(Thread Dump)显示多个线程在等待获取 ReentrantReadWriteLock 的读锁或写锁，特别是针对 org.apache.logging.log4j.core.util.internal.InternalLoggerRegistry 类的锁争用。

技术原理分析

锁机制变更

在 Log4j2 2.24.1 及之前版本，日志记录器的创建流程是：

1. 获取当前值(可能为 null)
2. 在无锁状态下创建新日志记录器实例
3. 获取写锁并执行 putIfAbsent 操作
4. 释放锁

而在 2.24.2 及以上版本中，流程变更为：

1. 直接获取写锁
2. 在持有锁的状态下创建日志记录器实例
3. 释放锁

这种变更导致了潜在的死锁风险，特别是在日志记录器初始化过程中如果触发其他需要获取日志记录器的操作时。

弱引用问题

另一个关键发现是 loggerRefByNameByMessageFactory 使用 WeakHashMap 实现弱引用语义。在某些情况下，这会导致：

1. 即使日志记录器已存在，弱引用可能已被回收
2. 系统不断进入慢路径(获取写锁创建新实例)
3. 高并发下造成大量线程在写锁上排队

解决方案演进

临时解决方案

1. 降级到 Log4j2 2.24.1 版本
2. 对于使用虚拟线程的场景，切换回平台线程
3. 升级到 JDK 24-EA(包含 JEP 491 改进)

根本修复方案

开发团队提出的修复方案(#3418)主要改进点：

1. 将日志记录器创建过程移出锁保护范围
2. 采用"读-创建-写"的三阶段模式：
   • 先获取读锁检查存在性
   • 无锁状态下创建实例
   • 获取写锁执行最终存储
3. 保留弱引用语义但优化锁竞争

最佳实践建议

1. 生产环境谨慎使用虚拟线程：特别是在日志密集型应用中，考虑虚拟线程与 Log4j2 的兼容性

2. 监控锁竞争：对于关键应用，建议监控 InternalLoggerRegistry 的锁获取情况

3. 合理配置日志级别：避免在运行时频繁修改日志级别，减少动态配置带来的锁竞争

4. 依赖管理：密切关注 Log4j2 官方修复版本发布，及时升级

总结

Log4j2 内部日志注册表的死锁问题展示了高并发环境下锁设计的重要性。从技术角度看，这提醒我们：

1. 锁粒度设计需要平衡性能与安全性
2. 弱引用缓存实现需要考虑并发访问模式
3. 虚拟线程等新特性可能暴露出传统锁实现的瓶颈

开发团队已经针对此问题提出了修复方案，预计将在后续正式版本中发布。对于受此问题影响的用户，建议根据自身业务场景选择合适的临时解决方案，并规划好最终修复版本的升级路径。