换用有界队列、显式拒绝策略和命名监控的自定义线程池是止住移动端h5接口雪崩最有效的一招，因其可防止无界队列导致的oom与卡死，并支持前端降级和后端熔断。
直接换掉 FixedThreadPool，改用带明确边界、可拒绝、可监控的自定义线程池，是止住移动端 H5 接口雪崩最有效的一招。FixedThreadPool 的核心问题是队列无界（LinkedBlockingQueue 默认容量为 Integer.MAX_VALUE），一旦下游响应变慢（比如 H5 调用的网关或风控接口 RT 从 100ms 拉长到 2s），请求就会在队列里无限堆积，内存暴涨、GC 频繁，最终整个 App 进程卡死或崩溃。
为什么 FixedThreadPool 在移动端特别危险
移动端 H5 接口常由 WebView 或 Hybrid 容器发起，特点是：并发不可控（用户快速连点、下拉刷新触发多请求）、重试机制粗暴（前端 JS 常设 3 次固定间隔重试）、超时感知弱（JS 层 timeout 设置不统一）。FixedThreadPool 在这种场景下既无法拒绝过载请求，又无法快速反馈失败，等于把压力全部吃下再缓慢释放，极易引发“排队→OOM→白屏/闪退”的雪崩链路。
自定义线程池的关键配置项
必须同时满足三个条件：有界队列、有拒绝策略、有命名与监控能力。
-
队列必须有限：使用
new ArrayBlockingQueue(200)，容量按预估峰值 QPS × 平均处理耗时（秒）估算，H5 场景建议初始值 100–300 -
拒绝策略必须显式指定：用
AbortPolicy（抛RejectedExecutionException）或CallerRunsPolicy（让调用线程自己执行，天然限流），避免静默丢任务 -
线程工厂必须命名：便于日志追踪和 APM 工具识别，例如
new ThreadFactoryBuilder().setNameFormat("h5-api-pool-%d").build() -
核心/最大线程数不宜过大：移动端后端通常 I/O 密集，推荐
corePoolSize = 4–8，maxPoolSize = corePoolSize（不扩容），避免线程上下文切换开销
一个可直接落地的 Kotlin 示例
适用于 Android 端 Retrofit + OkHttp 封装的 H5 接口调用层：
val h5ApiExecutor = ThreadPoolExecutor(
6, 6,
60, TimeUnit.SECONDS,
ArrayBlockingQueue(200),
ThreadFactoryBuilder()
.setNameFormat("h5-api-executor-%d")
.build(),
ThreadPoolExecutor.AbortPolicy() // 明确拒绝，前端可捕获异常做降级
)
// Retrofit CallAdapter 使用该线程池执行回调
val retrofit = Retrofit.Builder()
.baseUrl("https://api.example.com/")
.addCallAdapterFactory(LifecycleAwareCallAdapterFactory(h5ApiExecutor))
.build()
当队列满时，会立即抛出 RejectedExecutionException，前端 JS 层可监听网络错误码（如 503 或自定义 code=999），触发本地缓存兜底、提示“稍后再试”或降级为静态页，而不是无意义等待超时。
配套必须做的两件事
- 前端同步改造重试逻辑：禁用固定重试，改用指数退避（如 500ms → 1s → 2s），并在第 2 次失败后主动上报埋点，便于后端判断是否触发区域性雪崩
- 服务端增加熔断标记：在线程池拒绝率连续 30 秒 > 10%，自动触发 Sentinel 或 Resilience4j 的熔断开关，将 H5 流量导向轻量级降级接口（如返回预置 JSON 或 CDN 静态数据）
