绝大多数实际项目应优先用 Runnable，因其是接口可与任意继承共存，支持线程池、任务复用和职责分离；Thread 虽实现 Runnable 但仅适合极简场景或深度定制。
什么时候该用 Runnable，而不是继承 Thread
绝大多数实际项目里，你应该优先选 Runnable。不是因为它“高级”，而是因为 Java 不支持多继承——如果你的业务类已经继承了 Service、Controller 或某个框架基类，再想继承 Thread 就直接编译报错：java: 无法从类 X 继承；X 已经继承自 Y。
Runnable 是接口，可以和任意继承关系共存。比如：
class OrderProcessor extends AbstractService implements Runnable { ... }
这种写法毫无压力；而换成 extends Thread 就只能砍掉原有继承链，代价太大。
- 需要复用同一段任务逻辑（比如多个线程处理同一个队列）→ 必须用
Runnable，否则每个Thread子类都是独立实例，没法共享状态 - 要用线程池（
ExecutorService）→ 它只接受Runnable或Callable，不认Thread子类 - 只想改
run()，其他线程控制方法（join、interrupt等）全用父类的 →Runnable更轻量，也更符合“职责分离”原则
为什么 Thread 类其实也实现了 Runnable
看 Thread 源码就知道：它声明为 class Thread implements Runnable。也就是说，Thread 自己就是个 Runnable 实例。你调用 t.start()，JVM 最终还是走到它的 run() 方法里去执行。
立即学习“Java免费学习笔记（深入）”；
这解释了两个常见现象：
- 直接调用
thread.run()不会启新线程，只是普通方法调用（在当前线程同步执行） - 重写
Thread子类的run()，本质仍是填充那个Runnable合约；没重写时，默认行为是尝试调用传入的target（即构造时指定的Runnable），否则什么也不做
所以别被“继承 Thread”迷惑——底层统一走 Runnable 协议，只是封装层级不同。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
常见误用：把 Runnable 当成线程本身
新手常写：new MyRunnable().run()，以为这就开了线程。结果发现代码是串行执行、没并发、CPU 占用没变化——因为 run() 只是普通方法。
真正启动线程必须走 Thread 的 start()：
Thread t = new Thread(new MyRunnable());<br>t.start(); // ✅ 启动新线程<br>// new MyRunnable().run(); ❌ 仍在主线程里跑
另一个坑是重复 start()：t.start(); t.start(); 会抛 IllegalThreadStateException，且不可恢复。线程生命周期不可逆，启动后就不能再 start。
如果真要继承 Thread，只在这些情况考虑
不是不能用，而是得有明确理由。适合场景极少：
- 极简脚本或单元测试，就临时起一个线程打印点日志，不想多写一行
new Thread(...) - 需要深度定制线程创建过程（比如重写
init()、修改默认栈大小、绑定特定ThreadGroup），且确定不会和其他继承冲突 - 教学演示，强调“线程即对象”的直观性（但生产环境仍不推荐）
哪怕在这种情况下，也建议把任务逻辑抽到独立类里，让 Thread 子类只负责调度，别混业务。
真正容易被忽略的点是：线程安全和资源竞争跟选 Thread 还是 Runnable 无关——它们都只是启动方式。锁、volatile、AtomicInteger 这些才是解决并发问题的关键。别指望换种写法就能自动线程安全。
