不能直接减少核心线程数——corePoolSize 是只读属性，需通过 allowCoreThreadTimeOut(true) + keepAliveTime 触发空闲核心线程超时退出；setCorePoolSize() 仅影响后续任务分配，不终止已有线程。
线程池创建后还能动态减少核心线程数吗？
不能直接减少——ThreadPoolExecutor 的 corePoolSize 是只读属性，构造后无法通过公开 API 修改。所谓“减少线程数”，实际是指让空闲线程自然退出，或触发回收机制，而非强制销毁正在运行的线程。
关键前提是：必须启用允许核心线程超时（allowCoreThreadTimeOut(true)），否则即使空闲，核心线程也永不终止。
- 调用
setCorePoolSize(newSize)只影响后续新任务的准入阈值，不终止已有线程 - 真正触发线程退出依赖空闲等待 + 超时机制，不是“立刻减”
- 如果未设
allowCoreThreadTimeOut(true)，哪怕corePoolSize被调小，现有核心线程仍常驻
如何让空闲线程真正退出？
核心操作是组合两个设置：allowCoreThreadTimeOut(true) + 合理的 keepAliveTime。线程池会定期检查空闲线程是否超过 keepAliveTime，满足条件则中断并移除。
示例配置：
立即学习“Java免费学习笔记（深入）”；
ThreadPoolExecutor executor = new ThreadPoolExecutor(
10, 20, 60L, TimeUnit.SECONDS,
new LinkedBlockingQueue<>()
);
executor.allowCoreThreadTimeOut(true); // 必须显式开启
-
keepAliveTime建议不低于 10 秒，太短会导致频繁创建/销毁，抵消复用收益 - 该机制对
newCachedThreadPool()默认生效（它内部已启用超时），但对newFixedThreadPool()无效（它禁用超时且不可改） - 注意：线程退出前会尝试完成队列中已排队但未执行的任务，不会丢任务
shutdown() 和 shutdownNow() 对线程数的影响区别
这两个方法不“减少线程数”，而是控制生命周期，间接导致线程归零，但行为完全不同：
-
shutdown()：拒绝新任务，等所有已提交任务（含队列中）执行完后，线程自然退出 → 安全但耗时不确定 -
shutdownNow()：尝试中断所有正在执行的线程，并清空队列、返回未执行任务列表 → 线程可能立即停止，但任务可能丢失或处于不一致状态 - 二者调用后，
getPoolSize()会逐步降为 0，但这是终止过程，不是“缩容”
为什么 setCorePoolSize(5) 后线程数没变？
因为 setCorePoolSize() 不会主动驱逐线程，只改变后续任务分配逻辑。例如当前有 8 个线程在跑，调用 setCorePoolSize(5) 后：
- 第 9 个任务来时，若活跃线程 ≤ 5 才考虑复用；若 > 5，则优先进队列或触发扩容（取决于 maxPoolSize）
- 已存在的 8 个线程仍继续工作，直到它们空闲且超时（前提仍是
allowCoreThreadTimeOut(true)） - 常见误操作：只调
setCorePoolSize()却忘了开超时，结果线程数卡住不动
真正可控的“减员”路径只有一条：空闲 + 超时 + 允许核心超时。其他都是障眼法。
