Java 中 start 方法在设计线程模式中的关键地位

start() 方法，可以说是线程生命周期的真正起跑线。一旦调用，JVM 就会为它分配独立的栈空间、把状态设为 RUNNABLE，然后将其纳入调度队列。如果不调用 start()，线程永远停留在 NEW 状态——哪怕你重写了 run() 也无济于事，因为直接调用 run() 只是普通的串行方法调用。说到底，start() 是并发启动的保障、一次性启动的强制约束，也是所有线程模式的统一入口。

start() 在 Java 线程模式中扮演着不可替代的角色，它并非简单地调用 run()，而是唯一能够触发线程生命周期正式开始的合法机制。

start 是线程生命周期的正式起点

一个 Thread 对象刚被 new 出来时，处于 NEW 状态——好比一个人刚出生还没学会走路。只有调用了 start() 之后，JVM 才会为它分配独立的栈空间、设置状态为 RUNNABLE，并把它纳入调度队列。这个动作意味着线程真正“活”了起来：至于后续是否立即执行、何时执行、执行多久，那全由 JVM 和操作系统根据调度策略协同决定。

• 不调用 start()，线程永远停留在 NEW 状态，run() 方法哪怕重写得再漂亮也毫无意义
• 调用 start() 后，线程状态不可逆地进入就绪或运行，再也回不到 NEW
• 线程状态机中，NEW → RUNNABLE 的跃迁只由 start() 触发，其他任何方式都无法模拟

start 保障了真正的并发执行

为什么要用 start()？因为多线程的核心价值就在于多个逻辑流可以并行推进。start() 正是实现这一目标的技术支点：它在底层创建操作系统级线程（比如 pthread 或 Windows thread），让 run() 中的代码脱离当前调用线程，在独立上下文中异步执行。

• 直接调用 run() 只是普通的方法调用，所有代码仍在主线程里串行执行，毫无并发可言
• 调用 start() 后，主线程和子线程各自推进，输出顺序完全不确定，这才是真实的并发
• 即便 run() 内部是死循环，也不会阻塞主线程继续执行后续语句

start 强制约束线程对象的一次性语义

每个 Thread 实例对应一个且仅一个系统线程资源。start() 方法内部有状态校验，确保同一个对象不会重复启动——这是线程安全模型的重要基础。如果你试图第二次调用 start()，它会立刻抛出 IllegalThreadStateException。

• 这种设计避免了资源泄漏、状态混乱和难以调试的竞争问题
• 它也倒逼开发者明确区分“线程定义”（构造 Thread）和“线程启用”（调用 start）两个阶段

start 是所有线程模式的统一接入点

无论是继承 Thread 类、实现 Runnable 接口，还是用 Callable + Future、ExecutorService 等高级封装，底层最终都依赖 start() 或其等效机制来激活线程实体。比如 Runnable 实例必须包装进 Thread 对象才能调用 start()；lambda 表达式创建的 Thread 本质也是通过 start() 启动；即使使用线程池，submit() 提交的任务最终也是在线程池管理的 Worker 线程上调用 start()（或者复用已启动线程）来执行。

• Runnable 实例必须包装进 Thread 对象才能调用 start()
• lambda 表达式创建的 Thread，本质仍是通过 start() 启动
• 即使使用线程池，submit() 提交的任务也是在线程池管理的 Worker 线程上调用 start()（或复用已启动线程）来执行