高频短任务优化核心是ThreadPoolExecutor四参数协同：corePoolSize设CPU核数×2～3，用SynchronousQueue配maxPoolSize为1.5～2倍，keepAliveTime设10～30秒，拒绝策略首选CallerRunsPolicy，并禁用Executors工厂方法。
核心线程数设为CPU核心数 × 2～3
高频短任务虽单次耗时短，但提交频率高，容易导致核心线程忙不过来，被迫频繁走队列→扩容路径，引发线程创建抖动。设为 CPU核心数 × 2～3 能覆盖大部分并发压力，让多数任务直接由核心线程消化，避免排队和临时线程开销。
例如：4核机器建议设 corePoolSize = 8～12；8核可设为 16～24。需配合监控 activeThreads 和 CPU usage 动态验证——若长期低于80%利用率，说明设高了；若常有排队且 core 常满，则需上调。
用 SynchronousQueue + 较大的 maximumPoolSize
高频短任务不宜堆积——排队本身就会抬高 P99 延迟。SynchronousQueue 不存储任务，要求“提交即执行”，天然匹配短平快场景：
• 任务提交时若无空闲线程，立刻触发创建新线程（直到 max）；
• 任务执行完线程立即回收（配合 keepAliveTime），不留冗余；
• 避免任务在队列中“躺平”等待，保障低延迟。
此时 maximumPoolSize 应设为 corePoolSize 的 1.5～2 倍（如 core=12，max=18～24），为突发流量留出弹性空间。注意：必须搭配合理的拒绝策略，否则瞬时洪峰会直接抛异常。
keepAliveTime 设为 10～30 秒，unit 用 TimeUnit.SECONDS
非核心线程不能“秒建秒毁”。设太短（如 1 秒）会导致洪峰过后大量线程被快速销毁，下次流量来临时又得重建，徒增开销；设太长（如 5 分钟）则低谷期空闲线程占资源，浪费内存与调度负担。
推荐值：10～30 秒。这个窗口足够吸收短时脉冲，又能在业务平稳后及时释放资源。实测表明，20 秒是一个兼顾响应与资源的常用折中点。
拒绝策略优先选 CallerRunsPolicy
高频场景下，拒绝不是失败信号，而是系统过载的实时反馈。CallerRunsPolicy 让调用线程自己执行任务，本质是反压机制：
• 调用方线程被占用，自然降低后续提交速率；
• 不丢任务、不抛异常，避免链路中断；
• 比 DiscardPolicy 更友好，比 AbortPolicy 更可控。
若业务允许少量丢弃（如非关键埋点），可用 DiscardOldestPolicy —— 丢掉队列里最老的任务（虽然 SynchronousQueue 无队列，但该策略在 fallback 场景仍有效）。
立即学习“Java免费学习笔记（深入）”；
务必禁用 Executors 工厂方法，手动构造 ThreadPoolExecutor
Executors.newCachedThreadPool() 看似适合高频短任务，但它内部用的是 SynchronousQueue + Integer.MAX_VALUE 的 maximumPoolSize，极易在突发流量下创建海量线程，拖垮系统。
必须手写构造，明确控制所有参数：
• 显式传入 ThreadFactory（用于命名线程，方便排查）；
• 使用 ArrayBlockingQueue(0) 或直接 new SynchronousQueue()；
• 拒绝策略不依赖默认，显式指定；
• 关闭前调用 shutdown()，避免 JVM 退出时线程残留。
