关键在于将压力传导转为可控节流：主线程不阻塞靠流程控制与拒绝策略协同，callerrunspolicy 仅用于轻量兜底，配合有界队列、弹性线程池、上游限流与信号反馈实现系统稳定。
主线程不被阻塞、又不让下游雪崩，关键在于把“压力传导”变成“可控节流”。CallerRunsPolicy 本身不是释放主线程的手段，而是让主线程在过载时主动承担任务——这看似加重负担，实则是用同步执行换来系统整体的稳定性。真正安全释放主线程，靠的是流程控制与拒绝策略的协同设计。
明确主线程的角色边界
主线程（如 Web 容器线程、RPC 调用线程）本不该长期阻塞。若它频繁执行耗时任务，会直接拖垮上游服务。因此必须区分：
- 可降级路径：非核心逻辑（如日志上报、埋点统计、缓存预热）应走异步线程池，且配置 CallerRunsPolicy + 有界队列，使其在过载时由主线程“临时顶上”，但只执行轻量操作（例如只做本地内存计数，不发远程调用）
- 不可降级路径：主业务逻辑（如订单创建、支付扣款）必须走独立线程池 + AbortPolicy，并配超时熔断，确保主线程在拒绝时快速抛异常、走降级逻辑，绝不等待
用有界队列+合理参数封住缓冲失控
无界队列（如 LinkedBlockingQueue(Integer.MAX_VALUE)）是雪崩温床。一旦下游慢，队列无限堆积，内存爆、GC 频繁、主线程提交任务越来越慢，最终集体卡死。
- 强制使用 ArrayBlockingQueue 或带容量限制的 LinkedBlockingQueue(100~1000)，容量根据平均 RT 和容忍延迟反推（例如：期望最大排队延迟 ≤ 200ms，平均处理耗时 50ms → 队列 ≈ 4 个任务）
- corePoolSize 和 maximumPoolSize 不要设成 1:1 或差距过小；建议 core=8，max=32，给弹性扩容留出空间，避免过早触发拒绝
在 CallerRunsPolicy 中嵌入轻量兜底逻辑
CallerRunsPolicy 的本质是“让调用者减速”，但不能让它干重活。可在任务包装层做一层轻量拦截：
- 任务提交前检查当前系统负载（如 CPU > 90%、或自定义健康指标不达标），直接返回失败或降级响应，跳过线程池
- 若进入 CallerRunsPolicy 执行阶段，任务 Runnable 内部加 try-catch + 最大执行时间限制（如 if (System.nanoTime() - start > 50_000_000) return;），防止主线程被单个长任务锁死
- 对日志类任务，CallerRunsPolicy 下只做 log.debug() 或内存原子计数，禁止 IO、网络、锁竞争等阻塞操作
配合上游限流与信号反馈形成闭环
单靠线程池内部策略不够，需向上游传递压力信号：
- 当 CallerRunsPolicy 被频繁触发（可通过监控 rejectedExecution 次数 + 主线程执行耗时），自动触发 API 网关限流（如 QPS 降为 50%）
- 对外暴露 /actuator/health 等端点，将“拒绝率 > 5%”作为 OUT_OF_SERVICE 状态依据，让注册中心摘除实例
- 对 RPC 调用方返回特殊错误码（如 BUSY_RETRY_LATER），引导其退避重试而非重放，避免放大流量
