秒杀场景需多层防护：用有界线程池削峰、semaphore限流、redis+lua原子扣库存、异步落库保最终一致性。

秒杀场景下，瞬时高并发请求直接打到数据库，极易引发连接池耗尽、CPU飙升、锁表甚至物理库崩溃。Java中仅靠CountDownLatch无法解决根本问题——它只是同步工具，不控制并发量也不缓冲请求。真正有效的方案是：用线程池做**请求削峰**，用CountDownLatch（或更合适的工具）做**结果聚合/等待**，同时配合缓存、限流、异步落库等手段保护数据库。

用固定大小线程池控制并发写入量

避免所有请求直冲数据库，应将秒杀请求统一提交到有界线程池，让其以可控速率处理：

• 线程数建议设为数据库连接池最大连接数的1.5~2倍（如Druid连接池maxActive=20，则线程池corePoolSize=30）
• 使用LinkedBlockingQueue并指定容量（如1000），超量请求快速失败或降级，不堆积内存
• 拒绝策略推荐AbortPolicy（抛异常）或自定义策略返回“秒杀已结束”

用Semaphore替代CountDownLatch做实时并发限流

CountDownLatch适合“等待N个任务完成”，但不适合“限制同时只有M个任务执行”。秒杀库存扣减需精确控制并发数，应改用Semaphore：

js2java

JavaScript 到 Java 全栈翻译助手，专为前端开发者学习 Java 或快速实现后端业务逻辑而设计。当用户提到以下场景时必须使用此技能： - "帮我把这段 JS 代码转成 Java" - "用 Java 怎么写这个逻辑" - "我习惯用 JS 写，想翻译成 Java" - "教我 Java，我要写后端接...

下载

• 初始化Semaphore semaphore = new Semaphore(100)，表示最多100人能同时尝试扣库存
• 每个请求先semaphore.tryAcquire()，获取失败立即返回“系统繁忙”
• 成功后在try-finally中确保semaphore.release()，防止信号量泄漏

库存校验与扣减必须走Redis+Lua原子操作

数据库不是秒杀第一道防线。正确流程是：

• 预热：活动开始前将商品库存写入Redis（如seckill:stock:1001）
• 校验+扣减用Lua脚本一次执行，避免查+改的竞态：
  if redis.call("GET", KEYS[1]) >= tonumber(ARGV[1]) then
    redis.call("DECRBY", KEYS[1], ARGV[1])
    return 1
  else
    return 0
  end
• Lua返回1才提交订单，否则拒绝；失败请求不进线程池、不碰DB

异步化落库 + 最终一致性保障

扣减成功后，订单数据不直接INSERT主库，而是：

• 写入消息队列（如RocketMQ/Kafka），由消费者异步分批入库
• 数据库写操作加本地重试+死信队列兜底，避免单点失败导致数据丢失
• 用户端显示“下单成功，正在生成订单”，提升感知速度
• 超时未落库的订单，通过定时任务对账补偿

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南