线程池工作队列大小由创建时传入的BlockingQueue实例决定，不可动态修改；应选用ArrayBlockingQueue(n)或LinkedBlockingQueue(n)明确设限，并配合拒绝策略使用。
线程池的工作队列（即阻塞队列）大小，是在创建 ThreadPoolExecutor 时通过构造函数传入的 BlockingQueue 实例来决定的，**不是在线程池对象上动态设置的**。关键在于：你选用的队列类型是否支持容量限制，以及初始化时是否指定了容量。
1. 用有界队列（如 ArrayBlockingQueue）显式指定大小
这是最直接控制队列容量的方式。例如：
int corePoolSize = 2;
int maxPoolSize = 4;
long keepAliveTime = 60L;
TimeUnit unit = TimeUnit.SECONDS;
BlockingQueue<Runnable> workQueue = new ArrayBlockingQueue<>(10); // 队列最多存 10 个任务
ThreadPoolExecutor executor = new ThreadPoolExecutor(
corePoolSize, maxPoolSize, keepAliveTime, unit, workQueue
);
此时队列满后，新提交的任务会触发拒绝策略（如抛出 RejectedExecutionException 或由调用者执行）。
2. 避免误用无界队列（如 LinkedBlockingQueue 默认容量）
注意：new LinkedBlockingQueue<>() 是**无界队列**（内部使用 Integer.MAX_VALUE 容量），看似“无限”，实际可能导致 OOM。若想限制它，必须显式传入容量：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
-
new LinkedBlockingQueue<>(100)→ 有界，最多 100 个待执行任务 -
new LinkedBlockingQueue<>()→ 逻辑上无界，不推荐用于生产环境
3. 拒绝策略配合队列大小才真正生效
队列大小只有在结合合适的拒绝策略时才有意义。常见搭配：
-
AbortPolicy（默认）：队列满 + 线程数达上限 → 直接抛异常 -
CallerRunsPolicy：由提交任务的线程自己执行该任务（可自然降速） - 自定义策略：比如记录日志、丢弃旧任务、或转存到消息队列
示例设置拒绝策略：
executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
4. 不建议运行时修改队列大小
ArrayBlockingQueue 和 LinkedBlockingQueue 的容量是初始化时固定的，无法后续调整。如果需要动态调节缓冲能力，应考虑：
- 用更上层的限流机制（如
RateLimiter、Sentinel）在任务提交前控制速率 - 根据监控指标（如队列积压数、拒绝率）动态重建线程池（需谨慎，注意资源释放）
- 选用支持动态扩容的自定义队列（极少场景，通常得不偿失）
BlockingQueue 实例决定；优先选 ArrayBlockingQueue(n) 或 LinkedBlockingQueue(n) 明确设上限；务必配好拒绝策略，否则队列满了任务就丢了或卡住。 
