corepoolsize是线程池主动维持的最小活跃线程数，按需创建且默认永不销毁；它独立于队列和maximumpoolsize，设定需兼顾cpu核心数与业务qps压测。
corePoolSize 是线程池最基础的容量锚点，它定义的不是“平均线程数”，而是线程池**主动维持的最小活跃线程数量**。它的底层逻辑不依赖队列是否空、任务是否密集，而是一套“按需创建 + 长期驻留”的刚性策略。
核心线程的创建时机很明确
每当有新任务提交（调用 execute()），线程池会立即检查当前运行中的线程数：
- 若小于
corePoolSize，不管有没有空闲线程，都立刻新建一个线程来执行该任务； - 这个行为发生在任务提交的那一刻，不排队、不等待、不复用已有空闲线程；
- 哪怕刚创建的线程执行完任务立刻变为空闲，只要总数未达
corePoolSize，下个任务来时仍会继续创建。
核心线程默认永不销毁
一旦线程数量达到 corePoolSize，这些线程就会被长期保留：
- 即使持续空闲，也不会因
keepAliveTime被回收（除非显式开启allowCoreThreadTimeOut(true)）； - 它们是线程池的“基座”，承担稳定流量；
- 你可以通过
prestartAllCoreThreads()提前全部启动，避免首次任务触发创建延迟。
它和队列、最大线程数是解耦的
corePoolSize 的作用独立于后续流程判断：
- 它不决定队列是否启用——队列在核心线程满后才开始接收任务；
- 它不限制扩容上限——
maximumPoolSize才控制是否允许临时线程； - 选无界队列（如
LinkedBlockingQueue）时，线程数往往就卡死在corePoolSize，因为任务总能入队，永远触不到扩容条件。
数值设定要贴合业务稳定性需求
它不是越大越好，也不是越小越省资源：
- 设得太小（如 1），高并发下大量任务排队，响应延迟飙升；
- 设得太大（如 200），低峰期空转大量线程，白白占用栈内存和上下文切换开销；
- 推荐从系统 CPU 核心数 × (1–2) 出发，再结合平均 QPS 和任务平均耗时做压测微调。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
