用线程池执行后台清理任务关键在于可预期、可控制、不干扰主流程，并保障缓存状态等核心变量不泄漏；需区分周期性、事件驱动和被动兜底三类任务，配置有界队列、小核心数、守护线程工厂及健壮可观测的任务逻辑，配合优雅关闭。
用线程池执行后台清理任务，关键不是“扔进去就完事”，而是让清理行为可预期、可控制、不干扰主流程，同时保障核心变量（如缓存状态、连接引用、计数器、临时文件句柄等）在长时间运行中不泄漏、不腐化。
明确清理任务的类型和触发时机
后台清理通常分三类，需区别对待：
-
周期性清理：比如每5分钟扫描一次过期缓存项、每小时归档一次日志缓冲区。适合用
ScheduledThreadPoolExecutor，避免手动启线程或 Timer 带来的资源泄漏风险。 - 事件驱动清理：比如某个业务操作完成后，异步释放关联的本地资源（ByteBuffer、MappedByteBuffer）、关闭临时流。这类任务应提交到普通线程池，但需确保任务本身是幂等且轻量的。
-
被动兜底清理：当检测到内存使用率持续偏高、或核心变量（如 ConcurrentHashMap.size() 异常增长）超出阈值时，触发紧急清理。这类任务建议走独立的小型线程池（如 1–2 核心线程），并配
CallerRunsPolicy防止拒绝导致清理失效。
线程池配置必须贴合清理任务特征
清理任务往往 I/O 等待多、CPU 占用低、生命周期长，不能套用 CPU 密集型配置：
- corePoolSize = 1～3：多数清理逻辑串行更安全（如避免并发修改同一缓存 Map），除非明确要并行扫多个模块。
-
workQueue 推荐有界队列：例如
new ArrayBlockingQueue<runnable>(100)</runnable>。无界队列（如 LinkedBlockingQueue 默认无界）一旦清理逻辑阻塞（如网络超时、锁竞争），会导致任务持续堆积，最终 OOM。 - keepAliveTime 设为 60 秒以上：清理任务不频繁，非核心线程不必快速回收，减少反复创建开销。
-
threadFactory 必须自定义：命名含 “cleanup” 关键字（如
cleanup-pool-%d），便于 JStack 或监控平台识别；设为守护线程（setDaemon(true)），避免阻塞 JVM 正常退出。
清理任务本身要具备健壮性和可观测性
任务代码决定线程池是否真能“保整洁”：
- 每个清理任务 try-catch 兜底：绝不让未捕获异常终止工作线程。记录 ERROR 日志并带上当前清理目标（如 “清理 userCache 失败，size=24812”）。
-
对共享核心变量加读写保护：比如清理缓存前先
cache.asMap().keySet().stream()...是危险的，应改用cache.cleanUp()（Guava）或ConcurrentHashMap的迭代器+removeIf，避免 ConcurrentModificationException。 -
主动暴露清理指标：通过 Micrometer 注册 gauge（如
cleanup.lastRunMs）、counter（如cleanup.itemsRemoved），接入 Prometheus，一目了然判断清理是否失活或滞后。
配合 JVM 生命周期做优雅收尾
系统重启或滚动更新时，未完成的清理任务可能中断，导致中间状态残留：
- 应用关闭前调用
executor.shutdown()，再awaitTermination(30, SECONDS)，给正在执行的清理留出时间。 - 若超时仍有任务运行，调用
shutdownNow()并检查返回的List<runnable></runnable>—— 对其中属于“可中断清理”的任务（如文件删除、连接关闭），显式调用其 cancel 逻辑；对“不可中断但幂等”的（如清空本地 List），可跳过。 - 避免在 shutdown hook 中启动新线程池，那会绕过所有管控。
