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()（或复用已启动线程）来执行
