synchronized无法解决分布式秒杀超卖问题，因其仅作用于单jvm实例；高并发需redis+lua或数据库行锁+乐观锁；atomicinteger仅保障单机原子读写，不支持“查-判-减”复合操作。
秒杀库存扣减为什么不能只用 synchronized
因为 synchronized 锁的是 JVM 内的某个对象，而秒杀场景下请求通常分散在多个实例（比如多台服务器），单机锁根本拦不住并发超卖。哪怕你本地压测没问题，一上生产集群就崩。
实操建议：
- 别把
synchronized(this)或synchronized(StockService.class)当成并发安全的万能解——它只管得住当前 JVM 进程 - 高并发秒杀必须依赖分布式协调机制，比如 Redis + Lua 原子操作，或数据库行锁 + 乐观锁
- 如果只是单机 Demo 演示原子类能力，可以用
AtomicInteger模拟库存，但得明确标注“仅限学习，不可用于真实秒杀”
AtomicInteger 在秒杀中能做什么、不能做什么
AtomicInteger 能保证单个 JVM 内对一个整数变量的读-改-写是原子的，比如 decrementAndGet() 不会丢失更新。但它不提供“检查后扣减”的复合原子性——也就是典型的“先查库存是否 >0，再扣减”这种两步操作，中间仍可能被其他线程插队。
常见错误现象：get() 返回 1，两个线程同时通过判断，接着都调用 decrementAndGet()，结果变成 -1。
立即学习“Java免费学习笔记（深入）”；
实操建议：
- 用
compareAndSet(expected, updated)手动实现带条件的原子更新，例如：int current; do { current = stock.get(); if (current <= 0) break; } while (!stock.compareAndSet(current, current - 1)); - 注意
compareAndSet是乐观策略，失败需重试，高争用下可能循环多次，不适合超大并发 - 别用
getAndDecrement()替代判断——它无脑减，不检查业务逻辑前提
为什么秒杀里 volatile 不能替代原子类
volatile 只保证可见性和禁止指令重排，不保证操作的原子性。对 int 类型的读写本身是原子的，但 count++ 是读+加+写三步，volatile 完全拦不住中间被截断。
使用场景：适合做状态标记，比如 volatile boolean isStarted 表示秒杀是否开启；不适合做库存计数。
实操建议：
- 把
volatile int stock改成AtomicInteger stock，否则所有递减逻辑都是假并发安全 - 不要以为加了
volatile就能放心写stock--—— 编译器不会帮你合成原子操作 - 如果真要用
volatile配合其他机制（比如 CAS 循环），那底层还得靠Unsafe.compareAndSwapInt这类支持，不是靠关键字本身
Redis + Lua 实现真正可用的秒杀扣库存（单机 Demo 级）
这才是贴近实际的轻量级方案：利用 Redis 单线程执行 Lua 脚本的特性，把“查库存、扣减、记录订单”打包成一个原子操作。Java 层只负责发请求，不操心并发控制。
示例 Lua 脚本（保存为 seckill.lua）：
local stock = redis.call('GET', KEYS[1])
if not stock or tonumber(stock) <= 0 then
return -1
end
redis.call('DECR', KEYS[1])
return tonumber(stock) - 1
Java 调用要点：
- 用
RedisTemplate.execute()加载并执行脚本，传入Arrays.asList("seckill:stock:123") - 返回值为 -1 表示库存不足，非负数表示扣减后的剩余量
- 别在 Lua 里做耗时操作（比如 HTTP 请求、复杂计算），会阻塞整个 Redis
- 注意 Redis 持久化配置和内存淘汰策略，避免秒杀后库存被误清
复杂点在于：一旦引入 Redis，就得考虑连接池配置、超时设置、脚本加载失败降级逻辑。很多人卡在“本地跑通了，上线发现 Redis 响应慢，直接拖垮整个服务”。这不是原子类能绕过去的坎。
