Java虚拟线程导致应用因Logback的ReentrantLock挂起问题排查

是否为死锁？ #

从你描述的线程dump来看，这大概率不是传统意义上的循环等待死锁。标准死锁是多个线程互相持有对方所需的锁，形成循环依赖；而你的情况是多个虚拟/平台线程都卡在Logback的同一个ReentrantLock上，属于锁长时间被持有导致的全局阻塞——一旦持有锁的线程因某种原因无法释放锁，所有需要打日志的线程都会被卡住，最终导致整个应用无法处理请求（包括Actuator健康检查，因为健康检查也可能触发日志输出）。

具体排查步骤 #

1. 定位锁的持有方 #

从线程dump中找到持有Logback那个ReentrantLock的线程（线程dump中会明确标注哪个线程持有锁）：

• 如果是虚拟线程，查看它的栈帧，确认是否在执行日志输出时遇到了阻塞IO（比如写入日志文件时磁盘IO挂起、发送日志到远程服务时网络卡顿）。虚拟线程遇到阻塞会被挂载，但不会主动释放持有的锁，导致所有等待锁的线程一直阻塞。
• 如果是平台线程，检查它是否在执行耗时极长的日志处理操作（比如自定义Appender中的慢逻辑）。

2. 检查Logback配置的合理性 #

• 同步Appender的竞争问题：默认的FileAppender等是同步的，虚拟线程数量远多于平台线程，高并发下会放大锁竞争。大量虚拟线程同时抢日志锁，一旦锁被持有超过一定时间，阻塞的线程会迅速累积。
• 自定义日志组件风险：排查是否有自定义的Appender、日志拦截器，是否在日志输出流程中加入了阻塞操作（比如数据库查询、远程调用）——这些操作会让持有锁的线程长时间无法释放锁。

3. 分析Tomcat虚拟线程空栈帧与ForkJoinPool闲置问题 #

空栈帧的虚拟线程通常处于挂载状态（等待锁或IO），而ForkJoinPool未被充分利用，说明绝大多数虚拟线程都卡在了阻塞点（日志锁），没有真正执行业务逻辑，导致承载它们的平台线程处于空闲状态，这进一步印证了锁阻塞是核心问题。

4. 验证锁竞争的影响 #

• 临时切换为Logback的AsyncAppender，将日志输出异步化，减少业务线程（包括虚拟线程）在日志锁上的等待时间，观察问题是否缓解。
• 对比禁用虚拟线程前后的线程dump，看日志锁的竞争压力是否明显降低——虚拟线程的大量创建会放大原本不明显的锁竞争问题。

5. 排查Kafka消费者与调度任务的日志行为 #

检查卡住的Kafka消费者、Spring调度任务线程，是否在执行过程中触发了大量日志输出（比如批量处理消息时每条都打详细日志），且日志输出的IO路径存在瓶颈（比如磁盘性能不足、远程日志服务不稳定），导致锁长时间被持有。

6. 彻底排除死锁可能 #

使用jcmd <pid> Thread.print -l生成带锁详细信息的线程dump，检查是否存在循环等待场景：比如线程A持有锁1等待锁2，线程B持有锁2等待锁1。如果仅存在多个线程等待同一个锁的情况，即可确认不是死锁。

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