手动创建 threadpoolexecutor 最可控，因 executors 预设池隐藏关键参数；调度任务应优先用 scheduledthreadpoolexecutor 并配合适当参数与拒绝策略。
用 ThreadPoolExecutor 手动创建线程池最可控
Java 标准库没提供“开箱即用”的任务调度线程池，Executors 工具类返回的几种预设池（如 newFixedThreadPool）底层都封装了 ThreadPoolExecutor，但隐藏了关键参数控制权。真要调度任务、控制并发节奏，必须自己实例化 ThreadPoolExecutor。
常见错误是直接用 Executors.newScheduledThreadPool(5) 做周期性任务——它只适合简单延时/周期执行，不支持任务排队、拒绝策略定制、活跃线程数动态调整等调度需求。
-
corePoolSize和maximumPoolSize要按实际吞吐压测定，别盲目设成 CPU 核心数 × 2 - 拒绝策略选
ThreadPoolExecutor.CallerRunsPolicy最稳妥：当队列满且线程达上限时，让调用线程自己执行任务，避免丢任务或 OOM - 用
LinkedBlockingQueue时注意默认无界——任务堆积会吃光堆内存；建议显式传容量，比如new LinkedBlockingQueue(1000)
调度任务得靠 ScheduledThreadPoolExecutor，但别直接 new
如果需要「延迟执行」或「固定频率重复执行」，ScheduledThreadPoolExecutor 是唯一正解。但它继承自 ThreadPoolExecutor，所以仍需关注核心参数。直接 new 它容易踩两个坑：
- 构造时传的
corePoolSize是“最小常驻线程数”，不是最大值；它不支持maximumPoolSize动态扩容，所有调度任务都在这组线程里串行或并发跑 - 它的
scheduleAtFixedRate和scheduleWithFixedDelay行为差异极大：AtFixedRate是从上一次**开始时间**算间隔，可能任务重叠；WithFixedDelay是从上一次**结束时间**算，更安全 - 别把耗时长的任务丢进
ScheduledThreadPoolExecutor：一个任务卡住，后续所有调度都会延迟
示例：每 5 秒执行一次，但确保前一次结束才启动下一次
立即学习“Java免费学习笔记（深入）”；
ScheduledExecutorService scheduler = new ScheduledThreadPoolExecutor(1);
scheduler.scheduleWithFixedDelay(() -> {
// 你的业务逻辑
}, 0, 5, TimeUnit.SECONDS);
任务提交后怎么知道它是否真的跑了？
很多人以为调用 submit() 或 execute() 就等于任务已执行，其实只是进了队列或被线程取走。真正确认执行，得靠任务内部埋点或回调。
-
submit(Runnable)返回Future，但get()会阻塞，不适合调度场景；isDone()只能查是否结束，不能查是否已开始 - 更实用的是在任务体开头打日志或更新原子变量：
AtomicInteger runningCount = new AtomicInteger(); ... runningCount.incrementAndGet(); - 如果依赖外部状态判断，注意线程安全：不要用普通
int或ArrayList记录运行中任务 ID - 别依赖
Thread.currentThread().getName()判断线程池归属——名字可被覆盖，且多个池可能共用同名线程
为什么用完不 shutdown 会导致 JVM 不退出？
线程池里的工作线程默认是 non-daemon 线程，只要池没 shutdown，JVM 就认为还有用户线程在跑，不会退出。这是本地调试时最常见的“程序卡住”原因。
- 显式调用
shutdown()后，池不再接受新任务，但会等已有任务完成；想立刻停，再跟shutdownNow()（会中断正在跑的任务） - 务必在 finally 块或 try-with-resources 中关闭——尤其 Web 应用里，Spring 的
@PreDestroy或DisposableBean是更稳妥的位置 - 别在循环里反复 new ThreadPoolExecutor 又不关：每个池至少占 1 个线程 + 队列内存，几分钟就 OOM
复杂点在于：有些任务本身就在做异步回调，关池时机得和业务生命周期对齐；关早了，回调丢失；关晚了，资源泄漏。这事没有银弹，得看你的任务是否允许被中断、是否有外部依赖未清理完。
