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
这不是性能高低问题，而是「可控性」和「风险偏好」的选择。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
ArrayBlockingQueue 是有界队列，构造时必须指定容量。优点是能防止任务无限堆积导致 OOM；缺点是容量设小了容易触发拒绝策略，需配套处理逻辑（如降级、重试、告警）。
LinkedBlockingQueue 默认无界（实际是 Integer.MAX_VALUE），看似“永不拒绝”，但极易掩盖问题：下游慢、上游快 → 队列持续膨胀 → 堆内存打满 → Full GC 频繁 → 最终 STW 卡死。
真实建议：
• 生产环境一律用有界队列，如 new ArrayBlockingQueue(1024) 或 new SynchronousQueue()（适合高响应要求、配合 maxPoolSize 快速扩容）；
• 绝对不要用无参 LinkedBlockingQueue()；如果要用，至少显式传参：new LinkedBlockingQueue(2048)；
• 若选 SynchronousQueue，意味着“不存任务，只转交”，此时 maxPoolSize 必须足够大，否则拒绝率飙升。
RejectedExecutionHandler 不只是打印日志那么简单
默认的 AbortPolicy 直接抛 RejectedExecutionException，很多同学只 catch 一下就完事，但没想清楚：这个异常到底该由谁兜底？
典型误用：
– 在 Web 层 catch 后返回 500：用户请求直接失败，体验差；
– 在定时任务里忽略异常：任务静默丢失，监控无感知；
– 自定义 handler 中做复杂逻辑（如写 DB、发 MQ）：反而加重线程池负担，形成恶性循环。
靠谱做法：
• CallerRunsPolicy：让提交任务的线程自己执行，适合低吞吐、允许延迟的后台任务；
• 自定义 handler 记录关键指标（如拒绝次数、当前队列大小），并触发告警（如 Prometheus + AlertManager）；
• 对重要业务，可在提交前加简单限流（如 RateLimiter）或降级开关，比等拒绝再处理更前置；
• 注意：Spring 的 ThreadPoolTaskExecutor 拒绝策略必须通过 setRejectedExecutionHandler 显式设置，不会继承 JDK 默认行为。
线程池参数不是一次配好就一劳永逸的事。最常被忽略的是「动态可观测性」——没有暴露 getActiveCount()、getQueue().size()、getCompletedTaskCount() 这些指标，就等于闭着眼开车。哪怕只加个定时打点到日志，也能在出问题时快速判断是线程不够、队列满了，还是任务本身卡死。
