应统一异步任务调度入口，禁用 Thread 与 FutureTask 混用；FutureTask 必须交由 ExecutorService 提交，避免裸线程启动；推荐使用 CompletableFuture 替代手动组合，提升安全性与可维护性。
避免在同一个类内部既直接启动 thread 又挂载 futuretask 导致执行冲突，核心是**统一异步任务的调度入口，杜绝混用底层线程控制与高层异步抽象**。两者语义和生命周期管理机制不同：直接 new thread 是裸线程操作，而 futuretask 本质是 runnable + future 的适配器，需配合 executor 才能发挥取消、结果获取、状态跟踪等能力；混用容易造成线程重复创建、状态不可控、资源泄漏或“任务被多次提交却只执行一次/执行两次”的竞态。
明确任务归属层级，不交叉启动
一个任务实例只能由一种方式驱动：
- 如果选择
FutureTask，就不要调用其run()或start()——它不是 Thread 子类，不能直接 start；正确做法是交给ExecutorService.submit(futureTask)或new Thread(futureTask).start()（仅限单次，且不推荐裸线程） - 如果选择手动 new Thread，就不要把该 Thread 和 FutureTask 绑定在一起去“双重托管”；例如不要写
new Thread(futureTask).start(); futureTask.get();——此时 get() 会阻塞，而线程已独立运行，逻辑割裂 - 同一段业务逻辑，要么封装为
Callable交由 FutureTask + Executor 管理，要么封装为Runnable直接丢给 Thread，二者不共存于同一执行路径
禁用 FutureTask 的裸线程启动模式
FutureTask 虽实现了 Runnable，但设计初衷是配合线程池使用。裸调 new Thread(futureTask).start() 会绕过线程池的复用、拒绝策略、生命周期管理，也失去 Future 的 cancel / isDone / get(timeout) 等关键能力。更危险的是：若多个地方都这么干，又共享同一个 FutureTask 实例，就会触发你提到的“打架”——比如两个线程同时调用 futureTask.run()，而 FutureTask 内部用 CAS 控制状态，第二次 run 将被忽略（返回 false），但调用者可能误以为执行了两次。
✅ 正确姿势：
永远通过 ExecutorService 提交 FutureTask，例如：
ExecutorService exec = Executors.newCachedThreadPool(); FutureTask<String> task = new FutureTask<>(new MyCallable()); exec.submit(task); // ✅ 安全、可管理、可取消
用 CompletableFuture 替代手揉 FutureTask + Thread 组合
Java 8+ 场景下，CompletableFuture 是更现代、更安全的替代方案。它天然支持链式异步、异常处理、组合依赖，且不依赖裸线程：
- 无需自己 new Thread，也无需手动构造 FutureTask
- 所有异步行为由 supplyAsync / runAsync 统一发起，默认走 ForkJoinPool.commonPool()，也可指定自定义线程池
- 嵌套异步（如异步中再触发异步）可用
thenCompose或thenApplyAsync显式衔接，状态清晰、无隐式竞争 - 避免了 FutureTask 状态机与 Thread 生命周期错位的问题
例如替换易出错的手动组合：
// ❌ 危险：混用 Thread 和 FutureTask
FutureTask<Integer> ft = new FutureTask<>(() -> { ... });
new Thread(ft).start();
ft.get(); // 阻塞，但线程早已跑飞
// ✅ 清晰：用 CompletableFuture 统一表达
CompletableFuture<Integer> cf = CompletableFuture.supplyAsync(() -> {
return doHeavyWork();
});
cf.thenAccept(result -> System.out.println("got: " + result))
.exceptionally(e -> { log.error("fail", e); return null; });
检查并收敛类内线程创建点
在一个类里发现既有 new Thread(...).start()，又有 new FutureTask(...)，大概率说明职责混乱。应做重构：
- 提取耗时逻辑为独立 Callable/Supplier，作为纯数据处理器
- 将线程调度逻辑（new Thread / submit / supplyAsync）上提到服务层或配置层，类本身只暴露“可异步执行的接口”
- 加静态代码检查（如 SonarQube 规则）禁止在 service 类中出现 new Thread，强制走异步抽象层
