corePoolSize应据任务类型与系统资源设定：CPU密集型设为CPU核心数，IO密集型可设为2倍CPU核心数或依压测调整；maxPoolSize与keepAliveTime需协同配置，IO密集型推荐maxPoolSize=2×corePoolSize、keepAliveTime=60秒。
corePoolSize 设多少才不浪费又不断线
这个值不是拍脑袋定的，得看任务类型和系统资源。CPU 密集型任务，corePoolSize 通常设为 Runtime.getRuntime().availableProcessors()；IO 密集型（比如大量 HTTP 调用、数据库查询），可以翻倍甚至更高，常见设成 2 * CPU核心数 或根据压测结果调整。
容易踩的坑：
– 设得太小：线程不够用，任务排队或拒绝，尤其在突发流量时；
– 设得太大：线程上下文切换开销剧增，反而降低吞吐，还可能耗尽 JVM 线程数（默认单 JVM 线程上限约 1024～2048，受 -Xss 影响）。
建议：
• 先按业务典型负载压测，观察 CPU 使用率和 GC 频率；
• 如果任务平均执行时间 > 100ms 且含远程调用，优先考虑提高 corePoolSize；
• Spring Boot 应用中，若用 @Async，注意 spring.task.execution.pool.core-size 默认仅 8，生产环境几乎必调。
maxPoolSize 和 keepAliveTime 怎么配合用
maxPoolSize 只有在线程池中所有核心线程都在忙、且工作队列已满时才会触发扩容。它和 keepAliveTime 是一对“弹性开关”：后者决定非核心线程空闲多久后被回收。
立即学习“Java免费学习笔记（深入）”；
常见错误配置：
– keepAliveTime = 0L：非核心线程一空闲立刻销毁，导致频繁创建/销毁线程，增加 GC 压力；
– keepAliveTime 过长（如 60 秒）+ maxPoolSize 过大：突发流量退去后，大量空闲线程长期驻留，白白占内存和句柄；
– maxPoolSize == corePoolSize：彻底关闭弹性能力，等于固定大小线程池，无法应对流量毛刺。
实操建议：
• IO 密集型场景可设 maxPoolSize = 2 * corePoolSize，keepAliveTime = 60L（单位秒）；
• 若任务执行时间极短（keepAliveTime 降到 10L 以加快回收；
• 注意：当 allowCoreThreadTimeOut(true) 时，keepAliveTime 对核心线程也生效——慎用，除非你明确需要完全动态伸缩。
BlockingQueue 选 ArrayBlockingQueue 还是 LinkedBlockingQueue
这不是性能高低问题，而是「可控性」和「风险偏好」的选择。
