Java线程监控重在识别异常状态、预防资源耗尽和故障拦截，需将WAITING、BLOCKED等抽象状态转化为可观测指标并建立响应机制，涵盖危险状态识别、标准工具链监控、异常退出兜底及线程池业务维度监控四方面。
Java 线程生命周期的监控不是为了“数线程个数”，而是识别状态异常、预防资源耗尽、提前拦截故障。关键在于把抽象状态（如 WAITING、BLOCKED、TIMED_WAITING）转化为可观测指标，并建立响应机制。
一、重点关注的 4 类危险状态及其监控方式
线程处于以下状态本身不危险，但持续时间过长或比例异常，就是系统失稳信号：
-
BLOCKED：线程在等待获取 synchronized 锁或 ReentrantLock。监控建议：用
jstack或 JMX 的ThreadMXBean.findDeadlockedThreads()定期扫描；若 BLOCKED 线程数 > 5 且平均阻塞时长 > 100ms，需检查锁粒度和竞争热点 -
WAITING / TIMED_WAITING：线程调用了
Object.wait()、Thread.join()、LockSupport.park()等。风险点是“假等待”——比如数据库连接未超时、消息队列消费者卡在空轮询。监控建议：结合线程名（如"db-pool-worker-*）+ 堆栈中是否含SocketInputStream或PollingLoop判断是否异常挂起 -
RUNNABLE（但 CPU 零占用）：线程状态为 RUNNABLE，但实际未执行（例如陷入死循环前的最后一次计算、JNI 调用卡住）。监控建议：用
async-profiler或Arthas thread -n 5抓取高 CPU 占用线程堆栈；若某 RUNNABLE 线程长时间无堆栈变化，且top -H显示其线程 ID CPU 使用率为 0，大概率已卡死 -
NEW / TERMINATED 频繁创建销毁：反映线程未复用，常见于错误地 new Thread() 而非走线程池。监控建议：通过 JVM 参数
-XX:+PrintGCDetails观察 GC 日志中是否伴随大量线程对象分配；或用 JFR（Java Flight Recorder）开启jdk.ThreadAllocation事件跟踪
二、用标准工具链做低成本实时监控
无需引入复杂 APM，JDK 自带能力已足够覆盖核心场景：
-
JMX + ThreadMXBean：程序内嵌轻量监控逻辑，每 30 秒采集一次：
int blockedCount = bean.getThreadCount() - bean.getRunnableThreadCount();
若blockedCount > 10持续 2 分钟，触发告警 -
jcmd + jstack 自动快照：写一个 shell 脚本定时执行：
jcmd $PID VM.native_memory summary && jstack $PID > /tmp/jstack_$(date +%s).log
配合 grep 统计 “java.lang.Thread.State: BLOCKED” 出现次数，超阈值发钉钉 -
JFR（Java Flight Recorder）：启用低开销事件：
jcmd $PID VM.start_flightrecording name=monitor duration=60s settings=profile
录制后用 JDK Mission Control 分析线程状态分布、锁持有时间、GC 对线程暂停的影响
三、线程异常退出必须兜底
线程因未捕获异常静默终止，是稳定性最大隐患之一。仅靠 try-catch 不够，必须双保险：
立即学习“Java免费学习笔记（深入）”；
- 为所有自建线程显式设置异常处理器：
t.setUncaughtExceptionHandler((thread, ex) -> { logger.error("Thread {} crashed", thread.getName(), ex); }); - 全局兜底（对线程池尤其重要）：
Thread.setDefaultUncaughtExceptionHandler(...)
注意：该设置对Executors.newCachedThreadPool()创建的线程有效，但对ForkJoinPool无效，后者需单独配置ForkJoinPool#setUncaughtExceptionHandler - 对 Runnable/Callable 任务做统一包装：
在提交前 wrap 成SafeTask，确保每个 run() 方法外层都有try { ... } catch (Throwable t) { ... }，避免 Throwable（如 OutOfMemoryError）绕过 Exception 捕获
四、线程池场景要叠加业务维度监控
单纯看线程状态不够，必须关联业务语义：
- 监控
ThreadPoolExecutor.getActiveCount()和getQueue().size()比值：若活跃线程长期满负荷、队列持续增长，说明任务处理不过来，不是线程不够，而是单任务耗时过高 - 给线程池命名并打标：
new ThreadPoolExecutor(..., new CustomThreadFactory("order-processor"))
日志中自动携带线程名，出问题时可快速定位是哪个业务模块的线程异常 - 对关键任务加超时控制：
用CompletableFuture.orTimeout(3, TimeUnit.SECONDS)或Future.get(3, TimeUnit.SECONDS)，避免一个慢任务拖垮整个池
