线程创建方式决定监控可观测性：直接 new Thread() 导致指标丢失与定位困难，而 ThreadPoolExecutor 支持标准化监控、状态埋点与参数可解释性，推荐显式构造有界线程池并配合 JMX/Prometheus 监控。
线程创建方式直接影响监控指标的可观测性、稳定性和数据准确性。直接 new Thread() 会绕过统一管控，导致关键指标如线程数峰值、存活时长、任务堆积量难以采集；而基于线程池的方式则天然支持标准化监控，便于对接 JVM 工具与 APM 系统。
线程创建方式决定监控粒度是否可控
手动 new Thread() 创建的线程生命周期短、命名无规律、无统一上下文，JVM 线程 dump 中表现为大量匿名线程（如 "Thread-127"），无法关联业务逻辑，导致以下监控盲区：
- 无法统计某类业务任务对应的线程创建频次与失败率
- 线程栈信息杂乱，难以定位阻塞点或锁竞争源头
- 无法区分“有效工作线程”与“临时抖动线程”，CPU 使用率归因失真
相比之下，ThreadPoolExecutor 创建的线程具备固定命名前缀（如 “pool-1-thread-3”）、可配置的拒绝策略和队列容量，配合 JMX 暴露的 ActiveCount、PoolSize、LargestPoolSize、TaskCount、CompletedTaskCount 等指标，能清晰反映线程池负载趋势与资源饱和状态。
不同创建方式对 JVM 线程状态采集的影响
Java 线程状态（NEW、RUNNABLE、BLOCKED、WAITING、TIMED_WAITING、TERMINATED）是性能分析的基础依据。但采集效果受创建方式制约：
立即学习“Java免费学习笔记（深入）”；
- 继承 Thread 类或实现 Runnable 的裸线程，一旦 run() 执行结束即进入 TERMINATED，状态转瞬即逝，监控系统容易漏采
- Callable + Future 提交的任务在线程池中执行，其状态变化被 ThreadPoolExecutor 内部封装，可通过 Future.isDone() 或自定义钩子（beforeExecute/afterExecute）增强状态埋点
- 使用 ScheduledThreadPoolExecutor 时，TIMED_WAITING 状态占比高，若未结合任务延迟时间与实际执行耗时对比，易误判为“空转”而非合理调度
线程池参数暴露程度决定监控深度
Executors 工具类封装隐藏了核心参数，导致监控维度缺失；而手动构造 ThreadPoolExecutor 可显式暴露全部七大参数，使以下指标具备可解释性：
- corePoolSize / maximumPoolSize → 对应线程数基线与弹性上限，用于判断是否触发扩容、是否存在长期满负荷
- workQueue.size() → 直接反映任务积压程度，是识别吞吐瓶颈的第一信号
- keepAliveTime → 结合当前活跃线程数，可推算线程复用效率与冷启动延迟
- rejectedExecutionHandler → 拒绝次数上升是系统承压的明确告警，需与 CPU、内存指标联动分析
生产环境推荐的监控组合策略
为保障多线程行为可观、可测、可调，建议按创建方式分层设计监控：
- 所有线程必须设置有意义的 name，避免默认命名（new Thread(runnable, "order-process-worker")）
- 禁止使用 Executors.newCachedThreadPool()，因其无界线程数与无界队列会导致线程数暴增且不可控，监控曲线剧烈抖动
- 线程池统一通过 JMX 注册，配合 Prometheus + Grafana 抓取 ThreadPoolExecutor 各项指标，设置 corePoolSize > 0 且 workQueue 有界
- 对高频短任务（如 RPC 回调），启用 Async-Profiler 采样，关注火焰图中 park()/wait() 调用占比，识别隐式锁竞争
