start()是启动新线程的唯一合法入口，触发JVM创建OS线程并调度执行run()；直接调用run()仅为普通方法调用，仍在当前线程同步执行，不产生并发。
Java 中 start() 方法不是直接执行线程逻辑，而是触发 JVM 为该线程分配资源、进入就绪状态，并最终由调度器调用其 run() 方法——这是理解线程启动机制的核心。
start() 与 run() 的本质区别
start() 是线程生命周期的入口方法，它让线程从“新建”状态跃迁到“就绪”，后续由 JVM 调度执行；而直接调用 run() 只是普通方法调用，仍在当前线程中同步执行，不会开启新线程。
- 调用
thread.start()→ JVM 创建底层 OS 线程，注册调度，最终自动调用thread.run() - 调用
thread.run()→ 无新线程，代码在当前线程栈中运行，等价于普通方法调用 - 重复调用
start()会抛出IllegalThreadStateException，线程不可重复启动
start() 的底层协作机制
当 start() 被调用，JVM 会执行一系列协同动作：检查线程状态是否为 NEW；通过 JNI 调用本地方法创建操作系统级线程；将线程加入调度队列；待 CPU 时间片分配后，自动回调 Java 层的 run() 方法。
- 整个过程由 JVM 封装，开发者无需关心 pthread 或 Windows Thread API
- 线程真正开始执行的起点始终是
run()方法体，但执行上下文已是新线程 - 若
run()抛出未捕获异常，该线程终止，不影响其他线程
常见误用与规避方式
很多初学者混淆 start() 和 run()，或试图重写 start() 方法——这不仅破坏封装性，还可能导致线程状态错乱。
立即学习“Java免费学习笔记（深入）”；
- 不要重写
start()：它是final方法，编译期即禁止覆写 - 不要在
run()中手动调用start()：逻辑错误且必然失败 - 避免在
run()中执行阻塞且无超时的操作，防止线程“假死”影响调度 - 若需控制启动时机，可用
CountDownLatch或wait/notify协作，而非干预start()行为
扩展思考：为什么设计成两阶段启动？
分离 start()（准备）和 run()（执行），既保障线程安全初始化，又支持灵活扩展。比如 ThreadPoolExecutor 中的 Worker 类，也是通过 start() 启动内部线程，但实际任务由外部提交并由 run() 循环获取执行。
- 构造线程对象时可完成参数设置、资源预分配等初始化工作
-
start()调用前，线程完全可控；调用后交由 JVM 管理，符合“开闭原则” - 便于实现线程复用、监控、中断等高级能力，例如
Thread.interrupt()仅对已 start 的线程有效
