CompletableFuture.delayedExecutor 返回延迟执行的 Executor，用于 supplyAsync 等方法提交任务，延迟从 execute() 调用开始计时，不提供重试或内部挂起能力，非阻塞重试需递归构造新 CompletableFuture 并配合 exceptionally 与 thenCompose 实现。
CompletableFuture.delayedExecutor 本身不提供重试逻辑，它只负责“延迟提交任务”，重试必须由你手动编排；直接把它塞进 retryWhen 或 onFailureResume 这类响应式风格 API 是行不通的——Java 原生 CompletableFuture 没有内置重试操作符。
delayedExecutor 的真实作用：延迟触发执行，不是延迟等待
很多人误以为 delayedExecutor 能让一个 CompletableFuture “自己等几秒再继续”，其实它只是返回一个 IExecutor，用于后续调用 execute() 或作为 supplyAsync() 的第二个参数。它的延迟发生在“任务被提交到线程池”这个动作上，而不是在某个 already-running future 内部挂起。
- ✅ 正确用法：
supplyAsync(task, delayedExecutor(2, SECONDS))—— 2 秒后才把 task 提交到线程池执行 - ❌ 错误理解：
future.delayedBy(2, SECONDS)—— 这个方法根本不存在 - ⚠️ 注意：延迟从
execute()被调用那一刻开始计时，不是从delayedExecutor创建时开始
非阻塞延迟重试的最小可行结构
要实现“失败后隔 1 秒重试，最多 3 次”，不能靠单个 CompletableFuture 自循环，得靠递归式构造新 future，并用 delayedExecutor 控制每次重试的发起时机。
- 每次失败都生成一个新的
CompletableFuture，而不是复用旧的 - 用
exceptionally()捕获异常，内部判断重试次数，满足条件则用supplyAsync(task, delayedExecutor(delay, unit))发起下一次 - 必须显式传递 retry count（通过闭包捕获或封装成对象），因为
CompletableFuture不保存上下文状态 - 避免无限递归：用计数器或指数退避上限（如最大 delay 不超过 30 秒）
示例片段（简化版）：
static <T> CompletableFuture<T> retryAsync(
Supplier<CompletableFuture<T>> task,
int maxRetries,
long baseDelayMs) {
return task.get()
.exceptionally(ex -> {
if (maxRetries <= 0) throw new RuntimeException(ex);
return null; // 占位，实际靠 supplyAsync 触发重试
})
.thenCompose(result -> {
if (result != null) return CompletableFuture.completedFuture(result);
return CompletableFuture.supplyAsync(
() -> {
try {
Thread.sleep(baseDelayMs); // ⚠️ 这里是阻塞！见下条
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
return null;
},
delayedExecutor(baseDelayMs, MILLISECONDS)
).thenCompose(ignore -> retryAsync(task, maxRetries - 1, baseDelayMs * 2));
});
}为什么上面示例里还用了 Thread.sleep？以及怎么去掉它
上面代码中那个 Thread.sleep 是典型错误——它违背了“非阻塞”前提，且和 delayedExecutor 的延迟语义重复。真正非阻塞的做法是：把整个重试逻辑（包括延迟）全部交给 delayedExecutor 提交的新任务去承载，不在线程内做任何 sleep。
- ✅ 正确姿势：所有耗时操作（含延迟）都外包给
supplyAsync(..., delayedExecutor(...))，主线程绝不 sleep - ⚠️ 关键点：
delayedExecutor返回的 executor 是“一次性”的——每次重试都要新建一个，不能复用同一个实例来多次 submit - ⛔ 避免陷阱：不要在
delayedExecutor的 base executor（比如ForkJoinPool.commonPool()）里执行长时间阻塞操作，否则会拖垮整个池 - ? 推荐 base executor：用专用的、可配置的
ThreadPoolExecutor，例如new ScheduledThreadPoolExecutor(1)，避免污染公共池
容易被忽略的线程上下文与取消传播问题
异步重试链中，上游的 cancel(true) 默认不会中断正在等待延迟的 delayedExecutor 任务——它只影响已提交到 base executor 并正在运行的任务。也就是说，延迟未到期前调用 cancel()，那个延迟任务仍会在到期后执行。
- 若需支持及时取消，必须自行维护 cancel token（如
AtomicBoolean），并在supplyAsync内部检查该 token -
delayedExecutor不继承父 future 的线程上下文（如MDC、SecurityContext），日志追踪或权限信息容易丢失 - Android 上注意 API 级别：该方法自 Android API 31 引入，低于此版本会
NoSuchMethodError
