CallerRunsPolicy 实现压力反馈需配合有界队列（如 ArrayBlockingQueue），因仅在队列满且线程数达 maximumPoolSize 时触发；无界队列（如 LinkedBlockingQueue 默认构造）导致任务无限堆积，策略失效；调用线程同步执行任务产生阻塞，使上游感知压力，但需避免任务内死锁、长阻塞或忽略 RejectedExecutionException。
直接用 CallerRunsPolicy 就能实现压力反馈，但前提是线程池配置必须配合有界队列，否则它根本不会触发。
为什么 CallerRunsPolicy 必须搭配有界队列
无界队列（比如 LinkedBlockingQueue 默认构造）会让任务无限堆积，永远不触发拒绝策略；CallerRunsPolicy 只在「队列满 + 线程数已达 maximumPoolSize」时才生效。所以必须用 ArrayBlockingQueue 这类显式指定容量的队列。
- 错误配置：
new LinkedBlockingQueue()→ 任务照单全收，CallerRunsPolicy形同虚设 - 正确配置：
new ArrayBlockingQueue(10)→ 队列满后，新任务走拒绝逻辑 - 额外注意：如果
corePoolSize == maximumPoolSize，且队列已满，第n+1个任务立即由调用线程执行
如何让调用线程“感知”到压力
CallerRunsPolicy 的压力反馈不是靠日志或指标，而是靠调用线程被阻塞这个事实本身——你提交任务的线程（比如 Web 容器的 http-nio-8080-exec-5）会停下来同步执行任务，自然就无法继续接收/转发新请求。
- 典型现象：HTTP 接口 RT 突然升高，监控看到部分请求由
main或http-*线程执行，而非线程池工作线程 - 关键点：任务体里不能有死锁、长时间阻塞或未处理的中断 —— 否则调用线程卡住，整个上游线程池可能被拖垮
- 建议在任务中加超时控制，例如用
CompletableFuture.orTimeout(3, TimeUnit.SECONDS)包裹耗时操作
常见误用导致反压失效的三个坑
即使配了 CallerRunsPolicy 和有界队列，以下情况仍会让反压机制失灵：
- 用
submit()提交任务但没消费Future→ 任务异常会被吞掉，调用线程不阻塞，压力无感 - 线程池被封装在 SDK 或框架里（如 Spring 的
@Async），实际使用的是SimpleAsyncTaskExecutor这类无队列、无拒绝策略的伪线程池 - 业务代码捕获了
RejectedExecutionException并静默忽略 → 错过了策略生效的信号，等于关掉了压力开关
真正起作用的压力反馈，从来不是靠打印一行日志，而是让调用线程老老实实等在那里跑完任务——这一步卡住，才是系统在说“我快不行了”。别绕过它，也别替它兜底。
