java 中 `timer` 不可复用，调用 `cancel()` 后无法再次调度；应改用 `scheduledexecutorservice` 实现线程安全、可取消且可重用的防抖逻辑。
在高频率客户端请求场景中（如搜索框实时查询、按钮重复点击），为避免服务端被冗余请求压垮，常需实现防抖（Debouncing）：即忽略中间请求，仅在最后一次触发后延迟执行最终操作。但直接使用 java.util.Timer 容易踩坑——Timer.cancel() 会彻底终止其内部线程与任务队列，此后任何 schedule() 调用都将抛出 IllegalStateException("Timer already cancelled")，因此 Timer 实例不可复用，每次都需要新建（如注释中 new Timer()），但这会引发资源泄漏与线程管理失控风险。
更优解是采用 ScheduledExecutorService，它提供更健壮的调度能力、线程池复用机制及细粒度任务控制：
private final ScheduledExecutorService debouncer =
Executors.newSingleThreadScheduledExecutor(r -> {
Thread t = new Thread(r, "debounce-scheduler");
t.setDaemon(true); // 避免JVM因线程未结束而无法退出
return t;
});
private volatile ScheduledFuture scheduledRequest;
synchronized void debounceRequest() {
// 取消前序待执行任务（若存在）
if (scheduledRequest != null && !scheduledRequest.isDone() && !scheduledRequest.isCancelled()) {
scheduledRequest.cancel(false); // false: 不中断正在运行的任务
}
// 重新调度：150ms 后执行 doSendRequest（仅一次，非周期）
scheduledRequest = debouncer.schedule(this::doSendRequest, 150, TimeUnit.MILLISECONDS);
}
private void doSendRequest() {
// 执行实际网络请求或业务逻辑
System.out.println("Sending latest request at " + System.currentTimeMillis());
}⚠️ 注意事项：
- 必须使用 synchronized 或 ReentrantLock：防止并发调用 debounceRequest() 导致多个 ScheduledFuture 竞争取消与覆盖；
- 显式检查 isDone()/isCancelled()：避免对已完成/已取消任务重复调用 cancel()（虽无害，但属冗余）；
- 推荐设为守护线程：通过自定义 ThreadFactory 设置 setDaemon(true)，确保 JVM 正常退出；
- 资源清理：应用关闭时应调用 debouncer.shutdown() 并等待终止，例如在 Spring 的 @PreDestroy 或 Runtime.addShutdownHook() 中处理；
- 替代方案考虑：若项目已引入 Reactor（Project Reactor）或 RxJava，可使用 Flux.debounce(Duration) 实现响应式防抖，语义更清晰、背压更可控。
综上，ScheduledExecutorService 不仅解决了 Timer 不可复用的根本缺陷，还提供了更好的可观测性、错误隔离和生命周期管理能力，是 Java 服务端防抖实现的工业级标准选择。
立即学习“Java免费学习笔记（深入）”；
