关键在于让队列容量可见、行为可控、溢出可管；应使用显式容量的arrayblockingqueue替代无界队列，配callerrunspolicy拒绝策略、命名线程工厂及监控指标，并手动构造threadpoolexecutor而非executors工厂方法。
关键不是“不让队列存任务”，而是让队列容量可见、行为可控、溢出可管。任务队列吃内存，本质是任务对象（比如含大字段的 DTO、未释放的 IO 缓冲区、闭包引用）在堆里长期堆积，而非队列结构本身占多少空间。
用有界队列替代无界队列
LinkedBlockingQueue 默认构造是 Integer.MAX_VALUE 容量，等于“逻辑上无界”。几百个待执行任务就可能占用上百 MB 堆内存，尤其当任务携带 HTTP body、JSON 解析结果或数据库查询结果时。
- 改用 ArrayBlockingQueue，显式指定容量（如 128 或 256），确保上限清晰可预期
- 容量不是越大越好：设为 10000 只是把 OOM 推后，不是解决它；要结合核心线程数（如 8）和平均处理耗时（如 200ms）估算合理缓冲量
- 避免用 SynchronousQueue 除非你明确需要“提交即执行”，否则它不缓存任务，高并发下易触发拒绝策略
拒绝策略选 CallerRunsPolicy
队列满+线程数达上限时，拒绝策略决定系统如何“反压”。AbortPolicy 直接抛异常，可能引发上游重试风暴；DiscardPolicy 静默丢任务，可靠性难保障。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- CallerRunsPolicy 让提交线程自己执行任务，天然限流：生产者变消费者，提交速率自动匹配处理能力
- 它不阻塞提交线程，也不丢失任务，适合多数业务场景（如通知、日志异步落库）
- 若需更强控制，可自定义策略：记录被拒任务 ID + 降级写入本地文件或消息队列，后续补偿
线程工厂必须命名，监控必须接入
没名字的线程池就像黑盒——你不知道哪个模块在用、积压在哪、谁在撑内存。
- 用 ThreadFactoryBuilder 或自定义 ThreadFactory，生成带业务前缀的线程名（如 “order-async-1”），方便日志过滤与线程 dump 分析
- 定时采集关键指标：getQueue().size()（当前积压量）、getActiveCount()（活跃线程数）、getCompletedTaskCount()（完成总数）
- 当 queue.size() > 容量 × 0.8 时告警；activeCount 接近 maximumPoolSize 说明线程已打满，需查是否存在慢 SQL 或远程调用阻塞
绕过 Executors 工厂方法，手动构造
Executors.newFixedThreadPool() 等方法封装太深，隐藏了队列类型、拒绝策略、线程工厂等关键参数，生产环境禁用。
- 直接 new ThreadPoolExecutor(...)，明确传入 core/max 线程数、keepAliveTime、有界队列、命名线程工厂、CallerRunsPolicy
- 把线程池声明为 Spring Bean 或单例管理，避免重复创建；关闭时调用 shutdown() + awaitTermination()，防止任务丢失
- 配置项建议外置化（如 application.yml），便于不同环境差异化调整
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
