Thread.start()单次调用耗时约1–3 μs，仅含用户态栈分配、TLS准备及系统调用发起；不触发页表切换，真实开销来自内核中task_struct创建、就绪队列插入及后续首次调度时的寄存器保存/恢复与栈切换。
Java 中 start() 方法调用的执行开销不能只看“启动快不快”，而要分层拆解：它本身不耗时，但触发的连锁反应会带来可观的系统级成本。关键在于识别哪些开销可测、哪些需归因，避免误把延迟抖动当成 CPU 占用高。
直接测量 start() 调用本身的耗时
单次 start() 调用在 Java 层面非常轻量，通常在纳秒级（1–3 μs），但这个数字仅代表 JVM 发起系统调用前的准备动作。实际测量可用：
-
System.nanoTime()包裹调用前后，例如：long t0 = System.nanoTime(); new Thread(() -> {}).start(); long dt = System.nanoTime() - t0; - 注意：该值包含线程对象构造、栈内存预分配、TLS 初始化等用户态操作，但不含内核 clone() 的实际执行时间——这部分已脱离 Java 计时精度范围。
- 若测得单次 > 10 μs，需检查是否触发了 JIT 编译、GC 暂停或类加载阻塞，而非
start()本身变慢。
定位高开销的真实来源：非自愿上下文切换
频繁 start() 的危害不在单次，而在累积效应——大量线程争抢 CPU 时间片，导致调度器频繁强制切换。此时真正耗时的是寄存器保存/恢复、就绪队列插入、CFS 调度器计算等内核行为。
Java Development Manual
下载
Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...
- 用
pidstat -w 1观察目标 JVM 进程的nvcswch/s（非自愿切换次数）。若持续 > 50 次/秒且 %CPU 不高，说明线程数远超核数，调度开销已成瓶颈。 - 配合
vmstat 1看cs（总切换）和r（就绪队列长度）。若r > CPU 核心数且cs同步飙升，基本确认是线程创建过载。 - 不要依赖
top的 %CPU：线程太多时，CPU 时间大量消耗在调度上，业务代码反而跑得少，%CPU 可能偏低却响应严重延迟。
验证线程数量是否失控
线程爆炸是 start() 开销失控的最直观证据。需交叉验证进程内真实线程数：
立即学习“Java免费学习笔记（深入）”；
-
cat /proc/[PID]/status | grep Threads查总线程数； -
ls /proc/[PID]/task/ | wc -l统计 task 目录项，二者应一致； - 对比业务流量与线程增长趋势：请求量不变但 Threads 从 20 涨到 200，极大概率存在
new Thread().start()循环调用，未使用线程池复用。 - 慎用
strace -p [PID] -e trace=clone抓实时创建调用，仅限诊断，生产环境可能影响性能。
区分页表切换与真实开销
有人误以为 start() 会触发 TLB 刷新或 CR3 切换，其实不会。同进程内所有线程共享 mm_struct 和页表，CR3 寄存器不变。
- 真正开销来自栈指针（RSP）切换、callee-saved 寄存器压栈（约 10–20 条 MOV）、cache 行失效带来的局部性损失；
- 页表相关操作只发生在首次调度该线程执行时，且仅当发生跨进程或 mprotect/mmap 修改页表才需 TLB shootdown；
- 所以优化方向不是“减少页表操作”，而是控制线程总数、复用已有线程、避免短命线程泛滥。
