Java线程监控重在识别异常模式：如大量BLOCKED预示锁竞争，长期TIMED_WAITING反映I/O阻塞或任务积压；需结合Actuator线程快照、动态阈值告警、JFR虚拟线程追踪及趋势分析精准定位根因。

Java 线程生命周期的监控不是为了“数清楚状态”，而是要快速识别异常模式——比如大量线程卡在 BLOCKED 或长期处于 TIMED_WAITING，这往往预示着锁竞争、I/O 阻塞或任务积压。稳定性的核心在于早发现、准定位、快干预。

用 JMX / Actuator 实时抓取线程快照

Spring Boot 应用启用 actuator 后，/actuator/threaddump 接口可返回完整线程堆栈和状态分布。它比手动调用 Thread.getAllStackTraces() 更安全、开销更低，且支持 HTTP 调用与自动化采集。

• 每 30 秒轮询一次，解析 JSON 中 state 字段统计各状态线程数
• 重点关注 BLOCKED 数量是否持续 >5 个，或 WAITING 中等待 Object.wait() 的线程是否集中在同一锁对象上
• 配合 threadName 和 stackTrace 定位具体代码行（例如某次数据库连接获取超时，堆栈显示卡在 HikariPool.getConnection()）

设置关键阈值并触发告警

单纯看状态数量没意义，必须结合业务水位和线程池配置设动态阈值：

Java注释规范Skills

当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。

下载

• 活跃线程数 持续超过线程池 coreSize × 1.5，说明任务处理不过来，需查下游依赖或慢 SQL
• 阻塞线程数 占总线程数 >25%，大概率存在同步块争抢，检查 synchronized 方法或 ReentrantLock.lock() 调用点
• 死锁检测 一旦 ThreadMXBean.findDeadlockedThreads() 返回非空数组，立即 dump 并人工介入，不可依赖自动恢复

结合虚拟线程做轻量级追踪（Java 21+）

虚拟线程让“每个请求一个线程”成为可能，但也带来新挑战：传统线程监控工具可能忽略其存在。需主动适配：

立即学习“Java免费学习笔记（深入）”；

• 使用 Thread.ofVirtual().name("api-order-", 0) 显式命名，便于日志和监控中归因
• 在虚拟线程启动时绑定上下文（如 traceId），通过 ScopedValue 透传，避免线程切换后丢失链路
• 监控 jdk.VirtualThread.start 和 jdk.VirtualThread.end JVM 事件（通过 JFR），观察平均生命周期是否异常延长（>5s）

定期分析线程堆栈趋势而非单次快照

单次 threaddump 只能反映瞬时状态。真正有效的是连续采样后的趋势分析：

• 用 Prometheus + Grafana 绘制 jvm_threads_current、jvm_threads_states_threads（按 state 分组）曲线图
• 发现 RUNNABLE 曲线陡升但 CPU 使用率未同步上涨？说明线程在自旋或频繁 GC，查 Unsafe.park 或 ReferenceHandler 占用
• 若 TIMED_WAITING 中大量线程停在 SocketInputStream.read，说明网络超时配置不合理或下游响应慢