newCachedThreadPool适合大量轻量短时异步任务，按需创建线程、60秒空闲回收，但线程复用易致ThreadLocal脏数据；需在任务内显式清理上下文，配合CompletableFuture实现动态伸缩，生产环境建议定制ThreadPoolExecutor。
Executors.newCachedThreadPool 适合执行大量、轻量、短时的异步任务，它会按需创建新线程，空闲60秒后自动回收，避免线程资源浪费。关键不在“创建”，而在“按需”与“短生存期变量”的协同设计——线程复用时若持有上下文（如ThreadLocal、数据库连接、用户身份），极易引发脏数据或内存泄漏。
理解 newCachedThreadPool 的真实行为
它背后是一个无界队列 + SynchronousQueue 的线程池，核心线程数为0，最大线程数为 Integer.MAX_VALUE。这意味着：
- 任务提交时若无空闲线程，立刻新建线程（不排队）；
- 线程空闲满60秒后被终止（可调，但默认不可配置，需自定义 ThreadPoolExecutor）；
- 线程复用时，ThreadLocal 变量不会自动清理，上一个任务存的数据可能污染下一个任务；
- 它不保证任务执行顺序，也不适合长期运行或阻塞型任务（如 Socket 等待、sleep(10s)）。
短生存期变量必须“即用即清”
所谓“短生存期变量”，指仅服务于单次任务的临时状态，比如请求ID、鉴权Token、MDC日志上下文、临时缓存Map等。它们常通过 ThreadLocal 传递，但 newCachedThreadPool 的线程复用机制会让这些变量跨任务残留。
正确做法是：在任务开始前显式初始化，在任务结束后显式清理——尤其不能依赖 try-finally 写在 Runnable 外层（因为线程可能被复用，而 Runnable 是每次新建的）。
- ✅ 推荐：在 Runnable 或 Callable 内部统一处理
- ❌ 避免：在外部包装器中 set + 执行 + remove（线程复用时 remove 时机不可控）
- ✅ 示例（MDC 日志上下文）：
Map
MDC.setContextMap(context);
try {
// 执行业务逻辑
} finally {
MDC.clear(); // 每次必清，不依赖线程生命周期
}
};
配合 CompletableFuture 实现真正“按需”调度
newCachedThreadPool 本身不感知业务负载，但结合 CompletableFuture 可实现动态伸缩语义：
- 用
CompletableFuture.supplyAsync(() -> doWork(), executor)提交任务； - 当并发突增时，线程数自动扩容；流量回落时，空闲线程自然回收；
- 注意：不要在 supplyAsync 中再嵌套 blocking IO（如 JDBC 查询），应改用
supplyAsync(..., dbExecutor)切换专用线程池； - 可搭配
thenApply/thenAccept做后续轻量处理，保持主线程池只跑 CPU-bound 小任务。
必要时替换为可控的定制线程池
newCachedThreadPool 的60秒超时和 Integer.MAX_VALUE 上限在生产环境风险较高。更稳妥的做法是手动构造 ThreadPoolExecutor：
- 用
new ThreadPoolExecutor(0, 200, 30L, TimeUnit.SECONDS, new SynchronousQueue())； - 设置合理的 maxPoolSize（防 OOM）和 keepAliveTime（如30秒）；
- 添加 RejectedExecutionHandler（如 CallerRunsPolicy 或日志告警）；
- 重写 beforeExecute/afterExecute 方法，统一做 ThreadLocal 清理或监控打点。
