当前位置：首页 > 问答 > 正文

Java高并发下数据库锁怎么用，性能和安全得兼顾点吧

革姣丽
问答
2026-01-08 18:08:06
9

要搞清楚Java高并发下怎么用数据库锁，又能保证性能和安全，我们得先明白一个核心矛盾：锁得太死，安全是安全了，但大家（线程）都得排队，系统就慢得像蜗牛；锁得太松或者干脆不加锁，速度是快了，但数据可能就乱套了，比如你买票明明看到还有一张，付完钱却发现票没了,我们的目标就是在这两者之间找到一个最佳平衡点。

我们得知道数据库里常见的几种锁,它们就像是不同严苛程度的门卫。

悲观锁：先假设会出事，提前把人管住。 这就像你去银行柜台取一大笔钱，柜员会先把你这笔钱在系统里“锁”起来，告诉别人“这笔钱我正在处理，你们别动”，等整个操作完成（数完钱、你签字）后才释放，在数据库里，最典型的用法就是在SQL语句后加 FOR UPDATE。

Java里怎么用？ 通常是在一个数据库事务（Transaction）中，使用类似这样的代码：

// 开始事务
beginTransaction();
// 查询商品库存，并加上悲观锁
String sql = "SELECT stock FROM products WHERE id = ? FOR UPDATE";
// ... 执行查询，获取当前库存
if (stock > 0) {
    // 扣减库存
    String updateSql = "UPDATE products SET stock = stock - 1 WHERE id = ?";
    // ... 执行更新
}
// 提交事务，释放锁
commitTransaction();

兼顾点： 悲观锁非常安全，能绝对防止别人修改数据，但性能代价大，因为整个过程中（从SELECT到COMMIT），这条数据都被锁住，其他想修改它的事务必须傻等着，这在高并发场景下容易造成大量线程阻塞，拖垮系统，所以它适合那些“争抢”非常激烈、冲突概率极高，且业务逻辑执行起来很快的场景（比如秒杀中的核心库存扣减）。

乐观锁：先假设没事，出事了我再重试。 这就像用Git或者SVN这类版本管理工具，你修改文件前先拉取最新版本，改完之后提交时，系统会检查一下在你修改的期间有没有别人也修改了这个文件，如果有，它就告诉你“有冲突，提交失败”，让你自己处理（通常是拉取最新代码重新修改一次），在数据库里，通常用一个额外的version字段来实现。

Java里怎么用？

// 假设商品表有一个version字段，初始为0
// 1. 先查询出商品信息和当前的version
String selectSql = "SELECT id, stock, version FROM products WHERE id = ?";
// ... 执行查询，得到stock和oldVersion
// 2. 业务逻辑计算新库存
int newStock = stock - 1;
// 3. 更新时，带上version作为条件
String updateSql = "UPDATE products SET stock = ?, version = version + 1 WHERE id = ? AND version = ?";
int affectedRows = jdbcTemplate.update(updateSql, newStock, productId, oldVersion);
// 4. 判断更新是否成功
if (affectedRows > 0) {
    // 成功！说明这段时间没人动过数据
    System.out.println("扣减成功");
} else {
    // 失败！说明数据已经被别人修改过了，version对不上了
    // 这时候通常需要重试整个业务逻辑：重新查询、计算、更新
    System.out.println("扣减失败，请重试");
    // ... 可以加入重试机制，比如循环几次
}

兼顾点： 乐观锁的优点是在大部分情况下（读多写少）根本不加锁，性能非常好，因为只有在最后更新的瞬间才去检查冲突，缺点是万一冲突真的发生了，业务需要处理失败的情况（比如告知用户或自动重试），如果冲突频率很高，不断重试反而会降低性能，所以它特别适合读多写少、冲突发生概率相对较低的业务场景。

除了这两种核心思路，还有一些其他的技巧来兼顾性能和安全：

合理设置事务范围和隔离级别（来源：数据库事务原理）： 事务不要开得太大太久，尽快提交释放锁，数据库有不同的事务隔离级别（比如读未提交、读已提交、可重复读、串行化），级别越高越安全，但并发性能越差，通常默认的“读已提交”级别是个不错的平衡点，它能避免脏读，又比“可重复读”性能好，不要轻易使用最高的“串行化”级别,那相当于全局加锁。
使用数据库特定的高效语句（来源：SQL优化实践）： 有时候可以尝试把悲观锁的“查询-计算-更新”三步合并成一步，比如上面的扣库存例子,可以优化成：
```
String sql = "UPDATE products SET stock = stock - 1 WHERE id = ? AND stock > 0";
```
这条SQL本身在执行时数据库会对记录加锁，但它非常高效，因为只需要一次数据库交互，持有锁的时间极短，不过缺点是，我们无法在Java代码里进行复杂的业务判断（比如库存必须大于某个值）,它只适合非常简单的原子操作。
分散热点（来源：分布式系统设计思想）： 如果有一条数据是超级热点（比如一场热门演出的总门票数），所有人都来抢这一条记录，锁冲突必然严重，这时候可以考虑把数据分散，比如把10万张门票库存拆成100个库存包，每个包1000张票，这样并发请求会被分散到100条数据记录上，大大降低了单个锁的争用压力,这在秒杀系统中是常见策略。

总结一下怎么兼顾：