线程池配置必须匹配任务类型：cpu密集型任务应设为cpu核心数+1以减少上下文切换；io密集型任务则需2~4倍cpu核心数（或按公式cpu核数×(1+等待时间/计算时间)）以充分利用cpu空闲时间。
核心问题不在“分发逻辑”，而在线程池配置与任务性质不匹配——当大量图片加载任务被误投进一个专为CPU密集型设计的线程池时，每个线程在等待网络响应或磁盘读取时长期处于 BLOCKED/WAITING 状态，线程无法释放，新请求持续涌入，最终压垮上游网关的舱壁（circuit breaker）机制，触发 503。
确认任务类型：别把IO操作塞进CPU线程池
图片异步加载本质是典型的 IO密集型任务：下载网络图片、解码Bitmap、读取磁盘缓存，这些操作绝大部分时间都在等待I/O完成，线程实际占用CPU极少。若使用 Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors()) 这类默认按CPU核数配置的池，线程数过少，极易积压阻塞任务。
- ✅ 正确做法：为图片加载单独创建 IO 专用线程池，核心线程数建议设为 2 × CPU核心数 + 1 或基于并发请求数预估（如支持 200 并发图片加载，可设 coreSize=32）
- ❌ 错误做法：复用全局业务线程池或 @Async 默认池，尤其未重写
AsyncTask或CompletableFuture的执行器
避免线程阻塞：禁用同步IO，强制异步化
即使在线程池足够的情况下，若单个任务内部仍含同步阻塞调用（如 OkHttpClient.execute()、FileInputStream.read()），该线程仍会卡死，无法参与调度。
- 使用非阻塞HTTP客户端：OkHttp 配合
enqueue()，或 Retrofit +Call.enqueue() - 磁盘读写走异步封装：用
Files.readAllBytes() → CompletableFuture.supplyAsync(..., ioPool)，而非直接new FileInputStream() - Glide/Picasso/Fresco 等库默认已做异步处理，但需确认未手动调用
.submit().get()这类阻塞方法
加舱壁与降级：从网关层切断雪崩链路
线程池只是后端一环；上游网关抛 503，说明它已检测到下游服务不可用（如响应超时、连接拒绝、线程池满）。必须在图片服务入口主动限流+熔断：
- 接入 Resilience4j 或 Sentinel，在图片加载接口上配置 线程隔离（thread pool bulkhead），限制最大并发数（如 maxConcurrentCalls=50），超出直接快速失败
- 设置合理超时：网络请求 ≤ 3s，磁盘缓存读取 ≤ 100ms，整体接口超时 ≤ 5s，避免长尾请求拖垮整个池
- 提供降级策略：超时/失败时返回占位图（placeholder）、低分辨率缩略图，或直接跳过加载，保障主流程可用
可观测性补位：让阻塞“看得见”
没有监控的线程池等于盲开——需实时掌握线程活跃度、队列堆积、平均等待时间：
- 暴露
ThreadPoolExecutor指标：activeCount、poolSize、queueSize、taskCount、completedTaskCount（可通过 Micrometer + Prometheus 抓取） - 关键告警项：队列堆积 > 80% 容量、线程活跃率 500ms
- 结合链路追踪（如 SkyWalking），标记图片加载 Span 的状态，定位是网络慢、磁盘慢，还是解码慢
