应避免在线程池中调用 time.sleep()，因其会阻塞核心线程、降低吞吐、导致任务堆积甚至oom；须改用异步延迟（如 asyncio.sleep）、前置调度、专用有界线程池及监控熔断机制。
避免在图片异步分发逻辑中因长周期 sleep() 阻塞线程池核心线程，关键在于**不在线程池里做同步休眠**——这会直接占用工作线程、降低吞吐、堆积任务，最终压爆队列引发 OOM。
别在线程池里调用 time.sleep()
这是最常见也最危险的操作。比如在 ThreadPoolExecutor 提交的任务里写 time.sleep(5)，该线程就卡死 5 秒，无法处理新任务。若并发提交量大，所有核心线程很快被占满，后续任务只能进队列等待；一旦队列无界或容量过大，内存就撑不住。
- 同步 sleep 是“真阻塞”，它让 OS 线程挂起，事件循环或线程池调度器完全无法介入
- 尤其在图片处理场景（如缩略图生成、水印叠加、EXIF 解析）中，若混入本地 I/O 或 CPU 计算 + sleep，风险更高
- 即使只 sleep 100ms，当 QPS 达到几百时，积压速度也会远超消费能力
用异步延迟替代同步休眠
如果业务确实需要“延后执行”（例如错峰上传、防刷限流、重试退避），应改用真正的异步延迟机制，把时间控制权交还给调度系统：
- 在 asyncio 环境中，统一用
await asyncio.sleep(n)——它只是挂起协程，不占线程 - 若必须用线程池跑同步代码，延迟逻辑应前置：比如用
asyncio.get_event_loop().call_later(delay, submit_task)触发后续分发，而不是在线程里等 - 对重试类场景，推荐用指数退避 + 异步调度库（如
asyncio.create_task()配合asyncio.sleep()），而非在线程中 sleep 后重试
隔离耗时操作，限制线程池资源边界
图片分发常涉及网络上传、磁盘读写、格式转换等混合操作。不能指望一个通用线程池扛住全部压力：
- 为图片上传单独配置专用线程池，设置合理
corePoolSize（如 2–4）、maxPoolSize（如 8）、queueCapacity（严格有界，如 100） - 拒绝使用
Executors.newCachedThreadPool()或无界LinkedBlockingQueue，它们在突发流量下极易失控 - 对已知长耗时任务（如 >2s 的 PNG 压缩），可提前预估并走降级路径（跳过压缩、转 WebP、或异步通知回调）
监控与快速熔断
光靠设计不够，需实时感知异常：
- 暴露线程池指标：活跃线程数、队列大小、拒绝任务数（如通过 Micrometer 接入 Prometheus）
- 当队列使用率持续 >70% 或单任务平均耗时突增，自动触发告警或降级（如暂停非关键图片分发）
- 在提交任务前加轻量级准入检查：
if (executor.getQueue().size() > threshold) throw new RejectedExecutionException()
