corepoolsize=0会导致任务全入队而不启线程，引发高延迟；合理值≈qps×平均耗时×1.2～1.5，并按cpu/io密集型调整；setcorepoolsize()不立即生效，仅影响后续创建。
核心线程数设为 0 会怎样？
很多同学以为 corePoolSize=0 就是“不预热”，实际它会让线程池跳过核心线程创建逻辑，所有任务都走 execute() 的第三分支（先入队，队满再新建非核心线程）。这意味着：即使队列未满、CPU 空闲，也不会启动任何线程——任务全堵在队列里，响应延迟陡增。
除非你用的是 SynchronousQueue（无容量），否则 corePoolSize=0 在多数业务场景下等于自废武功。
怎么根据 QPS 和平均耗时反推合理 corePoolSize？
别拍脑袋填数字。用这个粗略公式：corePoolSize ≈ (QPS × 平均响应时间秒数) × 1.2～1.5
例如：接口 QPS=100，平均耗时 200ms → 基础并发需求 = 100 × 0.2 = 20，再乘 1.3 得到 26，取整设为 28 比较稳妥。
注意：这个值只是起点，必须结合 CPU 密集型/IO 密集型调整：
• CPU 密集型（如加解密、图像处理）：不宜超过 Runtime.getRuntime().availableProcessors()
• IO 密集型（如 HTTP 调用、DB 查询）：可放大到 2～4 倍，但需观察 GC 和线程上下文切换开销
动态调参时为什么 setCorePoolSize() 不一定立刻生效？
setCorePoolSize() 只影响后续的线程创建行为，不会主动销毁已有空闲核心线程，也不会唤醒等待中的线程。常见误区：
• 以为调小后空闲线程会立即退出 → 实际要等空闲超时（keepAliveTime）才可能回收
• 以为调大后马上多出一堆线程 → 实际仍需新任务触发创建，且受 workQueue 是否已满影响
真正能“立竿见影”的只有 setMaximumPoolSize()（影响拒绝策略触发阈值）和 setKeepAliveTime()（影响回收节奏）
用 Micrometer + Actuator 暴露线程池指标后，重点关注哪几个字段？
Spring Boot 项目开启 management.endpoint.metrics.show-details=always 后，访问 /actuator/metrics/jvm.threads.live 或自定义线程池指标（如 executor.pool.active），盯住这三项：
• executor.pool.active：持续接近 corePoolSize 说明线程不够用；长期为 0 说明配置过大或流量极低
• executor.queue.remainingCapacity：剩余容量持续趋近 0，代表队列积压，要么扩容队列，要么提升 corePoolSize，别硬扛
• executor.pool.completed 与 executor.pool.task.submitted 的比值：若明显小于 1，说明大量任务被拒绝或卡死，得查拒绝策略和线程阻塞点
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
