直接用 callerrunspolicy 替代 abortpolicy 并配合适当的有界队列与线程数，是避免秒杀订单静默丢失最有效、最落地的做法；因其能自然反压、确保任务不丢、提升可观测性，且需配合队列容量（maxthreads 的1～1.5倍）、合理 maxthreads（cpu×20～30）、关闭 allowcorethreadtimeout 及网关限流等措施。
直接用 CallerRunsPolicy 替代默认 AbortPolicy，并配合有界队列容量与线程数的合理配比，是避免秒杀订单静默丢失最有效、最落地的做法。
为什么 AbortPolicy 在金融秒杀中特别危险
AbortPolicy 遇到拒绝时直接抛出 RejectedExecutionException。若上层 Controller 或网关未显式捕获并做兜底（如记录日志、降级返回、触发补偿），该异常会一路向上直到被 Tomcat 默认错误处理器吞掉——用户收不到响应，前端超时重试，后端却毫无痕迹。秒杀场景下这种“零日志、零监控、零反馈”的静默失败，极易引发客诉与资损争议。
- 金融类请求通常具备强事务语义，丢一个订单可能意味着少一笔入账或漏一次风控校验
- 秒杀流量呈脉冲式，短时间大量任务涌入，AbortPolicy 容易在队列刚满、线程尚未扩容完成的窗口期集中触发
- 多数 Spring Boot 项目未对
@Async或自定义线程池的拒绝异常做全局@ExceptionHandler拦截
CallerRunsPolicy 如何解决这个问题
当线程池和队列都满时，CallerRunsPolicy 不丢任务，而是让提交任务的线程（比如 Tomcat 的 http-nio-8080-exec-xx 工作线程）**同步执行该任务**。这带来三个关键效果：
- 自然反压：Tomcat 线程被占用，无法立即接收新连接，HTTP 请求延迟上升，客观上降低上游发压速度
- 任务不丢失：所有请求最终都会被执行（哪怕慢一点），业务逻辑可完整走完风控、库存扣减、消息投递等环节
- 可观测性强：延迟升高、TP99 上涨、Tomcat active threads 持续高位，这些指标在监控系统中一目了然，便于快速定位瓶颈
必须配套的关键配置
单独换策略不够，需同步收紧队列与线程边界，否则 CallerRunsPolicy 可能引发线程雪崩：
- 队列用
ArrayBlockingQueue，容量设为 maxThreads 的 1～1.5 倍（例如 maxThreads=200 → queue=250），杜绝无界堆积 - maxThreads 设为 CPU 核数 × 20～30（如 16 核 → 320～480），确保有足够并发能力承接峰值，但不过度抢占系统资源
- 务必关闭
allowCoreThreadTimeOut（除非明确需要动态缩容），避免核心线程过早回收导致冷启动延迟 - 在网关层（如 Spring Cloud Gateway）叠加 IP 级限流（
redis-rate-limiter）与请求体校验（如 JSON 大小 ≤ 100KB），提前过滤无效/恶意流量
更进一步：加一层可感知的兜底
CallerRunsPolicy 是保底，但不是终点。建议在任务入口处增加轻量级拒绝标记：
- 自定义拒绝策略继承
CallerRunsPolicy，在执行前打点日志 + 上报 Prometheus counter（如order_rejected_by_pool_total{reason="caller_runs"}） - 监控该指标突增，联动告警（如 1 分钟内 > 50 次，触发 P1 告警）
- 前端配合做“排队中”提示（类似 12306），而非直接报错，提升用户体验与信任感
