delayedExecutor仅支持延迟执行，不支持重试；需手动结合CompletableFuture的exceptionally/thenCompose实现带退避策略的延迟重试，并注意线程泄漏与分布式失效问题。
delayedExecutor 本身不支持重试逻辑，必须手动组合
CompletableFuture.delayedExecutor 只负责“延迟执行一个 Runnable 或 Supplier”，它不感知任务失败、不管理重试次数、也不处理异常传播。想实现“延迟重试”，得用它作为调度器，配合手动的异常捕获 + 递归或循环调用 supplyAsync / runAsync 实现。
常见错误是直接写：CompletableFuture.supplyAsync(task, delayedExecutor(5, SECONDS)) —— 这只会延迟首次执行，失败后不会重试。
- 正确做法：在
handle或exceptionally中判断是否要重试，若需重试，则用delayedExecutor提交下一次尝试 - 必须显式控制重试次数上限，否则可能无限递归导致栈溢出或线程耗尽
- 注意：
delayedExecutor返回的是Executor，不是ScheduledExecutorService，无法取消已提交但未触发的任务
用 supplyAsync + exceptionally 实现带退避的延迟重试
适合需要返回值、且重试策略较简单（如固定延迟、指数退避）的场景。核心是把“当前任务执行”和“失败后调度下一次”拆成两个异步步骤。
public <T> CompletableFuture<T> retryWithDelay(
Supplier<T> task,
long baseDelayMs,
int maxRetries,
int attempt) {
return CompletableFuture.supplyAsync(task)
.exceptionally(ex -> {
if (attempt >= maxRetries) {
throw new CompletionException(ex);
}
long delay = (long) Math.pow(2, attempt) * baseDelayMs; // 指数退避
return null; // 占位，实际靠 schedule 下次调用
})
.thenCompose(result -> {
if (result != null) return CompletableFuture.completedFuture(result);
// 触发延迟重试
return CompletableFuture.supplyAsync(
() -> retryWithDelay(task, baseDelayMs, maxRetries, attempt + 1).join(),
CompletableFuture.delayedExecutor(delay, TimeUnit.MILLISECONDS)
).thenCompose(x -> x); // 展开嵌套的 CompletableFuture
});
}⚠️ 注意：join() 在异步线程中调用是安全的，但会阻塞该线程一小会儿；如果任务本身很重，建议改用 thenCompose 链式递归，避免 join。
避免线程泄漏：delayedExecutor 的 daemon 线程问题
CompletableFuture.delayedExecutor 默认创建的是非守护线程（non-daemon），在 JVM 退出时不会自动终止。如果大量使用延迟重试且应用频繁启停，这些线程可能堆积，表现为 java.lang.OutOfMemoryError: unable to create new native thread。
- 解决方案：传入自定义
ThreadFactory，显式设为 daemon 线程 - 示例：
delayedExecutor(1, SECONDS, Executors.defaultThreadFactory())不行；应写成：delayedExecutor(1, SECONDS, r -> { Thread t = new Thread(r); t.setDaemon(true); return t; }) - 更稳妥的做法：复用一个全局的
ScheduledThreadPoolExecutor（设为 allowCoreThreadTimeOut），并用CompletableFuture.supplyAsync(task, scheduledExecutor)替代delayedExecutor—— 虽然多一步初始化，但可控性强得多
分布式环境下 delayedExecutor 失效，必须换方案
delayedExecutor 是纯内存级的延迟调度，节点重启、服务扩缩容、机器宕机都会导致延迟任务丢失。它**完全不适用于分布式场景**。
真正可行的分布式延迟重试，得依赖外部系统：
- 消息队列：如 RabbitMQ 的
x-delay插件、RocketMQ 的定时消息、Kafka 配合延时主题（需额外组件） - 数据库轮询 + 状态机：将任务持久化，用定时 Job 扫描
next_retry_at 的记录 - 专用调度服务：如 XXL-JOB、ElasticJob、Temporal.io
如果你正在写一个“看似分布式的微服务”，但所有实例共用同一套 delayedExecutor，那只是伪分布式——故障隔离和弹性都不存在。
