java线程池可通过有界队列+拒绝策略实现硬限流，核心是拒绝超载任务；推荐核心数=最大数、arrayblockingqueue（如容量100）、abortpolicy或callerrunspolicy；静态配置为主，仅低峰缩容或瞬时高峰慎调maxpoolsize；精细限流需叠加semaphore；须监控activecount、queuesize、拒绝数等指标。
Java线程池本身不是限流器，但通过合理配置 ThreadPoolExecutor 的核心参数（尤其是队列容量和拒绝策略），可以实现轻量、可控的并发数限制——本质是“以资源约束换流量控制”。
用有界队列 + 拒绝策略实现硬限流
关键在于让线程池**拒绝超出承载能力的任务**，而非无限制积压。推荐组合：
- 核心线程数 = 最大线程数：避免动态扩容，保持并发数恒定
-
使用
ArrayBlockingQueue（有界队列）：例如容量设为 100，表示最多排队 100 个任务 -
拒绝策略选
AbortPolicy或CallerRunsPolicy：
–AbortPolicy直接抛RejectedExecutionException，调用方需捕获并降级/重试；
–CallerRunsPolicy让提交线程自己执行任务，天然减速，适合突发流量缓冲
动态调整 vs 静态配置：何时该变？
线程池参数一般应静态初始化，避免运行时频繁修改引发状态混乱。但以下场景可谨慎调整：
-
业务低峰期主动缩容：调用
setCorePoolSize()和setMaximumPoolSize()，注意已创建的空闲线程会在超时后销毁 -
突发流量临时扩容（慎用）：仅当监控发现持续拒接且确认是瞬时高峰，才调大
maximumPoolSize；但需配套熔断机制，防雪崩 -
不建议动态改队列容量：
BlockingQueue容量不可运行时变更，需重建线程池
配合信号量（Semaphore）做多层限流
单靠线程池只能控“执行中+排队中”的总任务数，若需更精细控制（如每用户每秒最多 5 次请求），需叠加应用层限流：
- 在任务提交前，先尝试获取
Semaphore许可；获取失败则快速失败 - 线程池负责系统级并发资源控制，信号量负责业务维度配额控制，二者正交不冲突
- 示例：用户 ID 哈希后映射到 10 个
Semaphore实例，分摊锁竞争
监控与可观测性不能少
限流生效与否，得靠数据验证：
- 定期采集
getActiveCount()（当前执行数）、getQueue().size()（排队数）、getCompletedTaskCount() - 记录被拒绝的任务数（可通过自定义
RejectedExecutionHandler统计） - 结合 Micrometer + Prometheus，暴露指标如
threadpool_rejected_tasks_total，设置告警阈值
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
