Log4j类加载致应用打日志时线程BLOCKED，异步Logger能否解决？

问题普遍性 #

该问题是Log4j2生态中被大量开发者反馈过的已知共性问题，从线程转储的调用栈可以完全匹配问题的触发根因：

• Log4j2默认输出增强型异常堆栈时，会在ThrowableProxy的初始化流程中，遍历栈帧对应的类执行类加载操作，获取类来源、代码版本等元信息用于堆栈输出
• 这个类加载操作会触发JDK8下AppClassLoader的全局类加载锁（即转储中标识为0x00007f2f5e3c4d30的锁对象）
• JDK8的AppClassLoader类加载流程为全局单锁设计，无锁分段优化，一旦某一个线程持有该锁，其他所有需要执行类加载操作的线程都会进入BLOCKED状态，也就是转储中观察到的多线程等待锁的场景
• 问题多触发于应用启动初期、类尚未被JVM完全预热加载完成，且业务场景存在高并发输出异常日志的情况

异步Logger的解决效果 #

并非所有异步日志配置都能解决该类阻塞问题，需要根据异步实现的类型区分效果：

• 基于Disruptor实现的全异步AsyncLogger可以完全解决应用线程被类加载阻塞的问题
  这类原生异步日志的流程中，业务线程触发日志时，仅需完成日志级别判断、将包含原始异常引用的日志事件写入Disruptor无锁队列，之后即可直接返回执行业务逻辑，不会参与后续的异常堆栈构建、类加载、日志序列化流程。原本会触发类加载锁竞争的ThrowableProxy构建逻辑，会完全放到后台专属日志处理线程中执行，哪怕后台线程因类加载锁出现阻塞，也不会影响业务应用线程的运行。
• 基于AsyncAppender封装的异步日志无法解决该问题
  这类异步实现的逻辑是在业务线程内完成全部日志序列化、异常堆栈构建（包括触发类加载的操作），仅将序列化完成的日志内容转发给后台线程写盘，类加载锁的竞争依然发生在业务线程侧，无法避免阻塞。

其他可落地的优化方案 #

如果暂时无法切换到全异步日志架构，也可以通过以下方式降低类加载带来的阻塞风险：

• 修改日志PatternLayout配置，将默认的%ex增强异常转换符替换为不触发类加载的普通%throwable输出符，关闭堆栈增强逻辑，从根源上移除类加载的触发点
• 对高频重复的异常日志增加限流逻辑，避免短时间内大量线程同时触发相同的异常堆栈处理流程
• 应用启动阶段提前完成核心类的加载预热，避免运行时业务路径触发类加载操作

内容的提问来源于stack exchange，提问作者Bukhtawar