继承Thread类不适合实现任务队列，因其将线程与任务绑定导致无法复用、资源浪费、无法接入ExecutorService、状态难共享、扩展性差；应采用Runnable+线程池解耦方案。
继承 Thread 类不适合实现任务队列，本质原因是它把“线程”和“任务”绑死在一起，导致无法复用、资源浪费严重，且与任务队列的设计目标直接冲突。
线程无法复用，每次任务都新建线程
任务队列的核心是“排队—分发—执行”，需要稳定、可复用的执行单元。而继承 Thread 的每个子类实例本身就是线程实体：
- 每 new 一个 MyThread()，JVM 就向操作系统申请约 1MB 栈空间（默认 -Xss1m）；
- 触发一次内核线程创建：分配寄存器上下文、调度队列注册、TLB 刷新等；
- 任务结束时还需销毁线程、释放栈内存、回收句柄——频繁创建销毁带来显著 GC 压力和上下文切换开销（单次约 0.5–2μs，百次即百微秒级损耗）。
无法接入标准线程池机制
Java 的 ExecutorService（如 ThreadPoolExecutor）只接受 Runnable 或 Callable 作为提交单位：
- Thread 子类对象不是 Runnable，不能直接 submit()；
- 强行包装（如 new Thread(task).start()）等于绕过线程池，失去复用、拒绝策略、生命周期管理等关键能力；
- 结果就是：你以为在用队列，实际是“伪队列”——任务来了就 new Thread，队列形同虚设。
任务状态与共享数据难以统一管理
任务队列通常要求多个任务共享状态（如计数器、缓存、连接池），而继承 Thread 方式天然隔离：
立即学习“Java免费学习笔记（深入）”；
- 每个 Thread 子类实例拥有独立字段副本（如 private int count），彼此不互通；
- 若强行共享，只能依赖 static 变量，易引发竞态、初始化顺序问题，且破坏面向对象封装；
- 相比之下，Runnable 实例是普通堆对象，天然支持多线程访问同一实例字段，配合 volatile/synchronized/原子类即可安全协作。
扩展性与维护成本高
面向任务队列的系统往往需支持优先级、延迟执行、取消、回调等能力：
- 继承 Thread 的类一旦写死，就难以注入额外行为（如监控、超时、重试）；
- 无法与 Future、CompletableFuture 等异步模型自然衔接；
- 违反单一职责：一个类既管线程生命周期，又管业务逻辑，测试和复用困难。
真正适合任务队列的是 Runnable + 线程池组合。任务是轻量对象，线程是长期资源，两者解耦才能高效、可控、可演进。
