我要评论在高并发场景中（比如电商秒杀、抢票系统、转账交易），多个线程/用户会同时操作同一共享资源（如库存、账户余额、订单号）。如果不做控制，会导致数据错误（如库存超卖、余额负数）、业务逻辑混乱（如重复下单）。锁（lock）是解决这类问题的核心工具之一。
一、概述：为什么高并发下需要锁？
1. 高并发的“数据竞争”问题
当多个线程同时修改同一个共享资源时（如数据库的库存字段、内存中的缓存值），如果没有控制，会出现“数据不一致”。例如：
- 电商场景：商品库存剩余10件，用户a和用户b同时下单，两个线程同时读取到库存为10，都扣减1后写回9，最终库存变成9（实际应卖出2件，库存应为8）。
- 转账场景：用户账户余额100元，同时发起两笔50元转账，两个线程都读到余额100，都扣减50后写回50，最终余额变成50（实际应扣减100，余额0）。
2. 锁的核心作用
锁是一种“互斥机制”，保证同一时刻只有一个线程能操作共享资源，避免数据竞争。类比现实中的“公共卫生间”：锁门后，其他人必须等待，直到当前用户释放锁（开门）。
二、锁的类型与适用场景
在spring boot中，常用的锁分为3类，需根据业务场景选择：
| 锁类型 | 实现方式 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|---|
| jvm内置锁 | synchronized关键字 | 单体应用（单进程）的小范围并发 | 代码简单，jvm自动管理锁 | 无法跨进程（分布式场景无效） |
| juc显式锁 | reentrantlock（lock接口） | 单体应用需要灵活控制锁（如超时、可中断） | 支持超时、可中断、公平锁 | 需要手动释放锁（否则死锁） |
| 分布式锁 | redis（redisson）、zookeeper | 分布式系统（多进程/多服务器）的并发 | 跨进程协调，全局唯一 | 依赖外部组件（如redis），有性能开销 |
三、锁的具体使用与代码实现
场景说明：模拟“电商库存扣减”
需求：用户下单时扣减商品库存，要求高并发下库存不能超卖（库存≥0）。
假设商品id为1001，初始库存10件。
1. jvm内置锁：synchronized
适用于单体应用（只有1个spring boot实例），代码简单，jvm自动加锁/释放。
@service
public class stockservice {
// 模拟数据库中的库存（实际开发中用数据库或缓存）
private int stock = 10;
// 下单扣减库存（synchronized保证同一时刻只有1个线程执行）
public synchronized boolean deductstock(int productid, int count) {
// 检查库存是否足够
if (stock < count) {
return false; // 库存不足
}
// 模拟业务耗时（如查询数据库、记录日志）
try {
thread.sleep(100);
} catch (interruptedexception e) {
thread.currentthread().interrupt();
}
// 扣减库存
stock -= count;
system.out.println("扣减成功，剩余库存：" + stock);
return true;
}
}
关键说明
synchronized修饰方法时，锁的是当前对象（this）；若修饰静态方法，锁的是类（stockservice.class）。- 缺点：无法跨进程（如果部署多个spring boot实例，每个实例的
stock是独立的，锁无效）。
2. juc显式锁：reentrantlock
适用于单体应用，但需要更灵活的锁控制（如设置超时、可中断）。
@service
public class stockservice {
private int stock = 10;
// 显式锁（可重入锁，支持公平/非公平）
private final reentrantlock lock = new reentrantlock();
public boolean deductstock(int productid, int count) {
// 尝试加锁（最多等待2秒，避免死锁）
try {
if (lock.trylock(2, timeunit.seconds)) {
if (stock >= count) {
thread.sleep(100); // 模拟业务耗时
stock -= count;
system.out.println("扣减成功，剩余库存：" + stock);
return true;
} else {
system.out.println("库存不足");
return false;
}
} else {
system.out.println("获取锁超时");
return false;
}
} catch (interruptedexception e) {
thread.currentthread().interrupt();
return false;
} finally {
// 必须在finally中释放锁（避免异常导致锁未释放）
lock.unlock();
}
}
}
关键说明
trylock(timeout, unit)：尝试加锁，超时未获取则放弃（避免线程无限等待）。finally中释放锁：必须手动释放，否则其他线程永远无法获取锁（死锁）。- 优点：比
synchronized灵活（支持超时、可中断），适合复杂业务逻辑。
3. 分布式锁：redisson（基于redis）
适用于分布式系统（多个spring boot实例部署），解决跨进程的并发问题。
@service
public class stockservice {
@autowired
private redissonclient redissonclient;
// 模拟数据库库存（实际用数据库或缓存，如redis存储库存）
private int stock = 10;
public boolean deductstock(int productid, int count) {
// 定义锁的名称（按商品id隔离，不同商品用不同锁）
string lockkey = "lock:product:" + productid;
rlock lock = redissonclient.getlock(lockkey);
try {
// 加锁（自动续期，防止业务耗时过长锁过期）
// waittime: 等待锁的最大时间（5秒）
// leasetime: 锁自动释放时间（30秒，防止死锁）
boolean locked = lock.trylock(5, 30, timeunit.seconds);
if (!locked) {
system.out.println("获取锁失败，稍后再试");
return false;
}
// 检查并扣减库存
if (stock >= count) {
thread.sleep(100); // 模拟业务耗时
stock -= count;
system.out.println("扣减成功，剩余库存：" + stock);
return true;
} else {
system.out.println("库存不足");
return false;
}
} catch (interruptedexception e) {
thread.currentthread().interrupt();
return false;
} finally {
// 释放锁（只有自己加的锁才能释放）
if (lock.isheldbycurrentthread()) {
lock.unlock();
}
}
}
}
关键说明
- 锁名称：用
lock:product:1001隔离不同商品，避免不同商品的库存操作互相阻塞。 - 自动续期：redisson默认会为锁“续期”（每10秒续30秒），防止业务逻辑未执行完锁就过期（比如扣库存需要20秒，锁30秒过期，续期避免提前释放）。
- 分布式场景有效性：多个spring boot实例通过redis的
lockkey协调，同一时刻只有1个实例能获取锁，避免跨进程的库存超卖。
四、实际业务举例：电商秒杀场景
场景描述
某商品开启秒杀（库存100件），1000个用户同时点击“立即购买”，需要保证：
- 只有前100个用户能成功购买（库存不超卖）。
- 后续用户提示“已售罄”。
解决方案（分布式锁）
- 用户点击下单时，先通过redisson获取该商品的分布式锁（
lock:seckill:productid）。 - 获得锁的线程检查库存是否足够（
stock > 0）。 - 库存足够则扣减库存，生成订单；否则返回“已售罄”。
- 释放锁，让其他线程继续竞争。
关键点
- 锁粒度：按商品id加锁（如
lock:seckill:1001），不同商品的秒杀互不影响，提升并发效率。 - 防死锁：设置锁的自动释放时间（如30秒），即使业务异常未释放锁，锁也会自动过期。
- 性能优化：库存可存储在redis中（
get/set操作比数据库快），减少数据库压力。
五、总结
1. 锁的选择原则
- 单体应用：优先用
synchronized（简单）或reentrantlock（需要灵活控制）。 - 分布式系统：必须用分布式锁（如redisson），避免跨进程数据竞争。
2. 注意事项
- 锁粒度：尽量缩小锁的范围（只锁共享资源的操作代码），避免“锁整个方法”降低性能。
- 防死锁：设置锁的超时时间（如
trylock(5, 30, timeunit.seconds)），避免线程无限等待。 - 性能权衡：锁会降低并发吞吐量（同一时刻只有1个线程操作），需结合业务场景（如秒杀允许少量延迟）。
3. 扩展思考
- 无锁方案：对于简单计数（如访问量），可用
atomicinteger（基于cas无锁操作），但无法解决复杂业务逻辑（如库存扣减+订单生成）。 - 读写锁：读多写少场景（如商品详情页缓存），可用
reentrantreadwritelock（允许多个读锁并发，写锁互斥）。
到此这篇关于详解解spring boot高并发锁的使用方法的文章就介绍到这了,更多相关spring boot高并发锁内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！
发表评论