必须用有界队列，因其设容量上限（如arrayblockingqueue(200)），满载即触发拒绝策略，从源头阻断请求向数据库传递，防止无界队列（如linkedblockingqueue）在秒杀洪峰中无限积压导致oom。
Java利用有界线程池保护底层数据库，核心不是“让线程池去拦请求”，而是通过资源硬限、执行隔离和快速失败，把数据库从高并发洪峰中摘出来——它不参与业务判断，只做一道可控的“物理闸门”。
为什么必须用有界队列？
无界队列（如 LinkedBlockingQueue）在秒杀流量突增时会无限堆积任务，导致 JVM 堆内存持续增长，最终 OOM；而有界队列（如 ArrayBlockingQueue）强制设上限（例如 100～500），一旦满载立即触发拒绝策略，从源头掐断请求向数据库传递的路径。这不是丢弃，而是主动止损。
关键参数怎么设才真起作用？
针对秒杀下单这类写操作，需单独配置专用线程池，并满足以下硬约束：
- corePoolSize 极小：设为 2～5，确保日常低负载下几乎不占用资源，也避免空闲线程长期持有数据库连接
- maxPoolSize 严控：不超过 30～50，防止突发刷量瞬间拉起大量线程争抢 DB 连接池
- workQueue 容量固定：ArrayBlockingQueue(200) 是常见选择，配合拒绝策略形成确定性响应边界
- 拒绝策略用 CallerRunsPolicy：超限时由 Web 容器线程（如 Tomcat 的 NIO 线程）同步执行任务，自然反压上游，避免后端雪崩
它如何与数据库真正解耦？
有界线程池本身不碰 SQL，它的价值体现在调度层：
- 所有进入该池的任务，必须已通过网关层的 Token 校验、时间窗口检查、防重放 nonce 验证 —— 参数篡改请求根本到不了这一步
- 任务体内部只做轻量操作：查 Redis 库存、扣减本地缓存、发 MQ 异步落库；绝不在此线程池内执行 JDBC update 或 select for update
- 真正的数据库写入交由独立的异步线程池（或消息队列消费端）处理，与秒杀入口完全隔离
配合监控实现动态熔断
仅靠静态配置不够，需实时感知压力：
- 当线程池排队平均时长 > 300ms 或拒绝率连续 30 秒超 25%，自动调用 setCorePoolSize(0)，冻结全部执行能力
- 同时上报告警，触发降级开关（如返回“系统繁忙，请稍后再试”）
- 待指标回落，再平滑恢复 corePoolSize 至初始值，避免震荡
本质上，有界线程池是秒杀链路里的“物理保险丝”：不干预业务逻辑，但用资源上限和确定性拒绝，守住数据库不被拖垮的底线。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
