平滑迁移thread继承类的关键是分步解耦：第一步提取run()中业务逻辑并封装调度参数；第二步将子类改为runnable实现；第三步用thread包装器过渡；第四步接入executorservice完成解耦。
直接继承 thread 的代码在业务重构中往往成为技术债的源头：它耦合了任务逻辑与线程生命周期管理，难以复用、测试和集成线程池。平滑迁移不是重写，而是分步解耦——把“做什么”（业务逻辑）从“谁来做”（线程对象）中剥离出来。
第一步：识别并提取 run() 中的核心任务逻辑
原 Thread 子类的 run() 方法里，通常混杂着业务处理、异常捕获、休眠控制、日志打印等。迁移前先做一次“逻辑切片”：
- 把纯业务计算、IO调用、数据转换等抽成独立方法或服务类（如
OrderProcessor.process()） - 将循环控制、
Thread.sleep()、中断响应等线程调度相关代码暂时保留，但封装为可配置参数（如intervalMs、maxRetries） - 移除对
Thread.currentThread().getName()等线程专属 API 的硬编码依赖，改用上下文传参或日志 MDC
第二步：将子类改造成 Runnable 实现类
不删除原有类，而是让它“转型”——不再继承 Thread，改为实现 Runnable，同时保留原有字段和构造逻辑：
- 原
class OrderPoller extends Thread→ 改为class OrderPoller implements Runnable - 把原
run()方法体整体搬入新run()，仅调整内部调用方式（例如：原this.poll()不变，但确保poll()不再依赖this.isInterrupted()等线程状态） - 若原类有启动/停止控制逻辑（如
shutdown()），保留为普通方法，由外部统一管理生命周期
第三步：用 Thread 包装器过渡，保持调用点零改动
为避免上下游代码大规模修改，可在初期用 new Thread(new OrderPoller(...)) 替换原来的 new OrderPoller(...).start()：
- 所有原来调用
myPoller.start()的地方，改为new Thread(myPoller).start() - 原来调用
myPoller.interrupt()的，改为threadReference.interrupt()（需持有Thread实例引用） - 这个阶段仍使用裸线程，但已解除继承绑定，为后续接入线程池铺平道路
第四步：接入线程池，完成真正解耦
当 Runnable 实现稳定后，替换为 ExecutorService 调度：
- 将
new Thread(runnable).start()替换为executor.submit(runnable) - 如有定时需求，改用
ScheduledExecutorService.scheduleAtFixedRate()，原Thread.sleep()可完全删除 - 若需返回结果或异常传播，可将
Runnable升级为Callable，但非必须——多数后台任务只需 fire-and-forget
整个过程不破坏原有行为，每一步都可验证、可回滚。重点不在“换接口”，而在把线程当作执行环境，而非业务载体。
