Java中继承Thread类虽技术上允许资源共享，但因实例状态独立、同步逻辑耦合、无法适配线程池与现代并发模型、违反单一职责且难以测试监控，实际开发中应优先使用Runnable接口。
Java 中继承 Thread 类本身并不禁止资源共享，但它的默认使用方式天然导致资源难以共享——不是技术上做不到，而是结构上不友好、容易出错、且违背设计直觉。
每个实例自带独立状态，共享需额外绕路
当你写 new MyThread().start() 两次，就创建了两个独立对象，各自拥有自己的成员变量副本（比如 private int count = 10;）。它们互不干扰，看似“线程安全”，实则根本没在竞争同一份资源。
- 想让多个线程操作同一个变量，必须把该变量声明为
static——但这会污染类级别状态，影响所有实例，还可能引发跨任务干扰 - 或者把同一个 Thread 实例 传给多个
new Thread(...)构造器（如new Thread(myThread).start()），但这违反 Thread 实例不可复用原则，启动第二次会抛IllegalThreadStateException - 真正可行的做法是把共享数据抽离到外部对象中，再通过构造参数传入，但这样已偏离“继承 Thread”的初衷，代码变得生硬
同步逻辑与线程生命周期耦合过紧
在 run() 方法里加 synchronized(this)，锁的是当前 Thread 实例。如果每个线程都是独立实例，那锁毫无意义——各锁各的，根本挡不住并发修改。
- 要真正保护共享资源，得锁一个所有线程都能访问的“共同对象”，比如
synchronized(sharedCounter) - 但这时你已经不得不引入外部协调对象，而 Thread 子类本身却仍带着一堆无关的线程控制字段（如优先级、组、状态等），职责混乱
- 一旦涉及复杂同步（如读写锁、条件等待），Thread 子类很快变成难以测试和维护的“大杂烩”
无法自然融入现代并发模型
线程池、CompletableFuture、ForkJoinPool 等主流工具都以 Runnable 或 Callable 为输入单位。继承 Thread 的类无法直接提交给 ExecutorService。
立即学习“Java免费学习笔记（深入）”；
- 你不能写
executor.submit(new MyThread())，因为submit()只接受Runnable/Callable - 强行包装（如
executor.submit(() -> new MyThread().run())）会丢失线程名、中断响应、异常传播等关键能力 - 虚拟线程（Virtual Threads）更是彻底基于
Runnable构建，Thread 子类完全被排除在外
业务类被迫承担线程管理职责
当一个业务类（如订单处理器）继承了 Thread，它就既负责业务逻辑，又负责线程启停、异常捕获、生命周期管理——这违反单一职责原则。
- 无法被 Spring 管理为 Bean：Thread 子类通常无参构造，无法注入依赖；也无法用
@Async或@Scheduled声明式控制 - 单元测试困难：难以隔离线程行为，mock 启动/中断逻辑成本高
- 调试和监控不便：JVM 工具链（如 JFR、VisualVM）对 Runnable 任务有更细粒度支持，而 Thread 子类常被当作黑盒处理
