futuretask 无法应对硬件断电或断网等底层故障，关键在于防止线程因阻塞等待、资源未释放或链式依赖被长期占用导致饥饿；需切断隐式同步依赖、强制超时边界、隔离故障域并注入物理层存活信号。
硬件级断电和突发断网属于不可恢复的系统级故障，futuretask 本身无法感知或响应这类底层中断——它运行在线程中，而线程依赖于 jvm 和 os 的调度与存活。真正需要防护的，不是 futuretask 的“内部挂起”，而是**物理线程因阻塞等待、资源未释放或任务链式依赖而被长期占用，导致其他关键任务无法获得线程资源**。这种现象在极限切换下会被放大，表现为线程饥饿。
切断隐式同步依赖
FutureTask 常被误用于嵌套等待（如在 submit 的任务里调用另一个 Future.get()），这在断网/断电后极易卡死：网络超时未生效、连接未关闭、底层 socket 处于 FIN_WAIT 状态，线程就被钉住。必须打破这种同步等待链：
- 禁用任何在任务体内直接调用 future.get() 或 future.get(timeout, unit) 的写法
- 改用异步回调组合：用 CompletableFuture.supplyAsync().thenCompose() 替代嵌套 submit + get；Java 8+ 中它天然支持超时传播与异常短路
- 若必须用 FutureTask，确保其 run() 方法内不包含任何阻塞 I/O、锁等待或无界队列 take() 操作
强制设置可中断的超时边界
FutureTask 自身不提供中断传播保障，但它的执行载体（Thread）可以被中断。关键在于让所有潜在阻塞点响应中断：
- 所有网络调用必须显式配置 connectTimeout / readTimeout（如 OkHttp 的 call.timeout(5, TimeUnit.SECONDS)）
- 文件读写使用 FileChannel.transferTo() + Thread.interrupted() 检查，避免 mmap 卡死
- 数据库连接层启用 socketTimeout 和 queryTimeout，禁用 autoReconnect（它会掩盖断连真实状态）
- FutureTask 提交后，外部绝不无 timeout 调用 get()；一律使用 future.get(8, TimeUnit.SECONDS)，并捕获 TimeoutException 后主动 cancel(true)
隔离故障域，避免单池雪崩
一个线程池承担所有任务（I/O、解析、计算、日志上报），断电后某类任务集体 hang 住，会拖垮整个池。必须按故障半径拆分：
- 为网络请求单独配池（maxWorkers = CPU×4，队列 size ≤ 10，拒绝策略为 CallerRunsPolicy）
- 为本地磁盘/临时缓存操作配独立小池（maxWorkers = 2–4，避免影响主流程）
- 监控上报、心跳保活等高优先级任务走专用守护池（即使主线程池已满，也能发出“我快死了”的信号）
- 所有池均禁用无界队列；使用 new ArrayBlockingQueue(N) 并配合 AbortPolicy 或 DiscardOldestPolicy
注入物理层存活信号
当硬件断电发生时，JVM 很可能来不及执行 shutdown hook。但操作系统会在电源异常时触发特定信号（如 SIGPWR、ACPI 事件）。可在启动时注册轻量级看门狗：
- 用 JNI 或 JNA 监听 /sys/class/power_supply/ 或 /proc/sys/kernel/sysrq（Linux）
- 一旦检测到 AC loss 或电压骤降，在 200ms 内遍历所有活跃 FutureTask 所属线程池，对未完成任务调用 future.cancel(true)
- 同时将当前线程池状态 dump 到内存映射文件（MappedByteBuffer），供下次启动时快速恢复关键上下文
本质上，这不是 FutureTask 的问题，而是任务模型与物理世界脱节的问题。把超时当成契约，把线程池当作有边界的资源单元，把中断当作第一公民——才能在断电断网的混沌中守住线程不饿死的底线。
