start()是并发的“开关动作”，调用后jvm立即校验状态、加入线程组并触发start0()申请内核线程资源，使线程进入独立生命周期；直接调用run()则仅在当前线程串行执行，无法实现并发。
start 方法的执行时机直接决定程序是否真正进入并发状态——它不是“什么时候运行 run()”，而是“什么时候让 JVM 为线程分配独立资源并交由调度器管理”。早一秒调用，就早一秒释放主线程；晚一拍调用，就多一分串行风险。
start() 是并发的“开关动作”，不是延迟执行的占位符
调用 start() 的瞬间，JVM 就启动线程创建流程：校验状态（仅 NEW 可启动）、加入线程组、触发 native 的 start0()，向操作系统申请内核线程资源。这个过程不等待 run() 执行完毕，也不阻塞当前线程。
- 主线程调用 t.start() 后立即继续执行下一行代码，哪怕子线程还没开始跑 run()
- 子线程可能稍后才被调度执行，但它的生命周期已独立启动——它有自己的栈、PC 寄存器、TID 和状态迁移路径（NEW → RUNNABLE → RUNNING）
- 即使 run() 方法体为空或只 sleep(1000)，只要 start() 被调用，线程数监控、jstack 输出、ThreadMXBean 统计都会反映一个新增的活跃线程
延迟调用 start() = 主动放弃并发窗口
若在循环中逐个创建 Thread 对象，却把所有 start() 集中在最后批量调用，看似“一起启动”，实则丧失调度弹性：多个线程几乎同时进入 RUNNABLE 状态，易引发调度争抢、上下文切换激增，甚至因锁竞争或资源池饱和导致响应抖动。
- 正确做法是创建即启动：new Thread(task).start()，让线程尽早进入就绪队列，获得更均匀的 CPU 时间片分配机会
- 避免“先攒一批 Thread 实例，再统一 start”——这既不能提升吞吐，反而增加内存驻留和调度延迟
- 对定时任务或事件驱动场景，start() 应紧贴触发条件发生时刻，而非预加载后静默等待
过早或过晚调用 start() 都会破坏预期并发模型
start() 必须在对象构造完成、状态初始化完毕后调用；但也不能拖到关键资源已释放或上下文已失效时才调用。
- 例如：在线程依赖某个数据库连接池时，应在连接获取成功后立即 start()；若等连接 close() 后再 start()，run() 中就会抛出 NullPointerException 或 SQLException
- 又如：GUI 线程中启动后台任务，需确保 SwingUtilities.invokeLater 已确保 UI 线程安全后再调用 start()，否则可能访问未初始化的组件引用
- 常见反模式：把 start() 放在 finally 块里试图“兜底”，结果因异常提前退出，导致线程永远无法启动
测试阶段 timing 差异掩盖真实并发缺陷
本地单核 CPU、无 I/O 延迟、小数据量环境下，start() 与 run() 的执行时间差常小于毫秒级，功能逻辑又完全一致——这正是隐患藏匿最深的地方。
- 压测时观察线程数指标：若并发请求数为 100，但 jstack 显示只有 main 和少量工作线程，说明大量 start() 被误写成 run()
- 监控 CPU 使用率与吞吐量倒挂：CPU 不满载但接口平均延迟飙升，往往是主线程被 run() 长耗时操作持续占用
- 日志中线程名始终为 main 或固定 worker 名，从未出现 Thread-1、pool-1-thread-2 等动态命名，基本可判定未真正并发
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
