Apache Log4j2 内部日志管理器死锁问题分析与解决方案

问题背景

在SpringBoot 3.x应用中使用ActiveMQ Artemis 2.38和Log4j 2.24.2时，应用启动过程中出现了严重的死锁问题。这个问题在启用SpringBoot的backend-preinit功能（默认启用）时表现为死锁，而在禁用该功能时则表现为栈溢出错误。

问题现象

当问题发生时，应用启动线程会卡在Log4j2的InternalLoggerManager.getLogger()方法中，等待获取一个ReentrantReadWriteLock锁。线程转储显示主线程在尝试获取读锁时被阻塞，而另一个线程可能持有写锁，导致典型的读写锁死锁情况。

在禁用backend-preinit的情况下，问题表现为栈溢出错误，这是由于递归调用导致的调用栈过深。

根本原因分析

经过深入分析，这个问题实际上是由Log4j2的PropertiesUtil.getStringProperty()和Spring的JndiPropertySource.getProperty()之间的递归调用引起的。具体调用链如下：

1. Spring框架的JndiPropertySource.getProperty()方法尝试初始化ActiveMQ Artemis
2. Artemis在初始化过程中锁定了BeanUtilsBean对象
3. Log4j2在锁定InternalLoggerManager后尝试创建新的Logger实例
4. Log4j2在创建Logger过程中查找log4j2.flowMessageFactory属性，需要访问所有可用的属性源
5. 这又回到了第一步的JndiPropertySource.getProperty()调用

这种循环调用导致了死锁和栈溢出两种不同表现形式的问题。

解决方案

Log4j2开发团队已经提交了修复代码，主要解决了以下问题：

1. 移除了可能导致递归调用的属性查找逻辑
2. 优化了内部日志管理器的锁机制
3. 改进了对弱引用的处理方式

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

1. 强制禁用JndiPropertySource，通过设置spring.jndi.ignore为true
2. 如果不是在Servlet环境中运行，可以移除java.naming.*系统属性，因为Spring不使用这些属性来启动Artemis

修复版本

该问题已在Log4j2的2.24.3版本中得到修复。用户可以通过升级到该版本或更高版本来彻底解决此问题。

技术启示

这个问题给我们几个重要的技术启示：

1. 递归调用风险：在框架设计中，需要特别注意避免可能形成递归调用的逻辑，特别是在属性解析和日志记录等基础功能中。

2. 锁粒度控制：日志系统的锁设计需要特别谨慎，因为日志可能在任何地方被调用，包括其他组件的初始化过程中。

3. 初始化顺序：框架间的初始化顺序可能导致意想不到的交互问题，在设计时需要充分考虑这种可能性。

4. 弱引用处理：使用弱引用时需要考虑垃圾回收可能带来的影响，特别是在并发环境下。

总结

Log4j2作为Java生态中广泛使用的日志框架，其稳定性和性能对整个应用至关重要。这次死锁问题的分析和解决过程展示了开源社区如何快速响应和解决复杂的技术问题。对于开发者而言，及时关注和使用框架的最新稳定版本是避免类似问题的最佳实践。