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

问题背景

在SpringBoot 3.x应用程序与ActiveMQ Artemis和Log4j2集成的场景中，开发人员发现了一个严重的启动问题。当应用程序启用SpringBoot的backend-preinit功能（默认开启）时，系统会出现死锁；而禁用该功能时，则会导致栈溢出错误。这个问题直接影响了应用程序的正常启动和运行。

问题现象

从线程堆栈分析可以看出，死锁发生在Log4j2的InternalLoggerManager.getLogger()方法中。具体表现为：

1. 死锁情况：主线程在等待获取ReentrantReadWriteLock锁时被阻塞，而该锁被其他线程持有
2. 栈溢出情况：当禁用backend-preinit时，系统陷入无限递归调用，最终导致栈空间耗尽

根本原因分析

经过深入分析，这个问题源于Log4j2内部日志管理器与Spring框架属性解析之间的复杂交互：

1. 循环依赖：形成了一个闭合的调用链：

   • Spring的JndiPropertySource.getProperty()初始化Artemis
   • Artemis锁定BeanUtilsBean
   • Log4j2在锁定InternalLoggerManager后创建新Logger
   • Log4j2查找log4j2.flowMessageFactory属性时又回到Spring属性源

2. 并发控制问题：InternalLoggerManager使用ReentrantReadWriteLock和ConcurrentHashMap.computeIfAbsent()的组合，在特定时序下可能导致死锁

3. 弱引用处理：日志管理器使用弱引用机制，在初始化过程中如果日志器被回收，可能导致重复初始化的并发问题

解决方案

Log4j2开发团队提供了两种解决方案：

1. 临时解决方案

对于急需解决问题的用户，可以采取以下临时措施：

• 强制禁用JndiPropertySource：通过设置spring.jndi.ignore为true
• 非Servlet环境下：移除java.naming.*系统属性，因为Spring不使用这些属性启动Artemis

2. 永久解决方案

Log4j2 2.24.3版本中已经修复了这个问题，主要改进包括：

• 重构了内部日志管理机制，避免了与属性解析的循环依赖
• 优化了并发控制策略，消除了死锁可能性
• 改进了弱引用处理逻辑，防止重复初始化

验证结果

经过实际验证，使用Log4j2 2.24.3-SNAPSHOT版本后：

• 应用程序启动正常，不再出现死锁或栈溢出
• 所有基本功能测试和回归测试均通过
• 系统稳定性得到显著提升

最佳实践建议

为避免类似问题，建议开发人员：

1. 及时升级到Log4j2 2.24.3或更高版本
2. 在复杂集成场景中，仔细检查各组件间的初始化顺序
3. 对于关键业务系统，进行全面测试后再部署
4. 关注日志框架与其他组件的兼容性声明

这个问题展示了在复杂Java应用中，框架间交互可能带来的微妙问题。通过Log4j2团队的快速响应和解决方案，为社区提供了一个典型的框架集成问题处理范例。