高并发下的间隙漏洞：SpringBoot + MyBatis-Plus + ShardingSphere 的检查与防御|share blog

在高并发场景中，数据操作的 “间隙漏洞” 如同隐藏的暗礁，往往在业务量激增时引发数据不一致、重复提交等严重问题。当 SpringBoot 的快速开发能力、MyBatis-Plus 的便捷 CRUD 与 ShardingSphere 的分库分表能力结合时，虽然能应对大规模数据处理，但也可能因分布式环境的复杂性放大间隙漏洞的影响。本文将深入剖析这类场景下间隙漏洞的成因，并提供具体的检查与防御方案。

什么是操作的间隙漏洞？

简单来说，间隙漏洞指的是在多线程或分布式环境中，由于操作的非原子性、资源竞争或同步机制失效，导致两个或多个操作之间出现 “时间差”，进而引发数据异常。

例如，在秒杀场景中，两个请求同时查询库存（均为 1），随后都执行扣减操作，最终库存变为 - 1—— 这就是典型的间隙漏洞导致的超卖问题。在 SpringBoot + MyBatis-Plus + ShardingSphere 架构中，分库分表带来的分布式环境、MyBatis-Plus 的 CRUD 封装可能隐藏的非原子操作，都会增加间隙漏洞的风险。

超卖的判定标准是 “实际订单数> 初始库存数“，库存不能为负数。当库存变成负数时，意味着 “实际卖出的商品数已经超过了初始库存总量”，这正是超卖最直观的量化结果。

时间点	事务 A 操作	事务 B 操作	商品实际库存 (实际值)	说明
T1	开始	-	1	事务 A 启动
T2	SELECT stock FROM t_stock WHERE id=1	-	1	事务 A 读取库存，无锁，此时实际库存大于0可以创建订单
T3	-	开始	1	事务 B 启动
T4	-	SELECT stock FROM t_stock WHERE id=1	1	事务 B 读取库存，无锁，此时实际库存大于0可以创建订单
T5	UPDATE t_stock SET stock=stock-1 WHERE id=1	-	1	事务 A 更新库存
T6	提交	-	0	事务 A 提交，数据生效
T7	-	UPDATE t_stock SET stock=stock-1 WHERE id=1	-1	事务 B 基于旧值更新
T8	-	提交	-1	事务 B 提交，异常结果生效

从表中能直观看到，在未加锁时，两个事务可同时读取到原始库存值。由于没有锁的限制，它们各自基于旧数据完成计算和更新，最终导致库存出现负数，这就是未加锁场景下间隙漏洞引发的典型问题。

在 SpringBoot + MyBatis-Plus + ShardingSphere 架构中，这种问题会因以下因素被放大：

MyBatis-Plus 的select+update模式天然形成事务内的操作间隙
ShardingSphere 的分库分表使数据分布在多节点，事务一致性更难保证
分布式环境下网络延迟增加了操作间隙的时间窗口

比如在秒杀场景中，两个请求同时查询到库存为 1，之后都执行扣减操作，最终库存变为 - 1，这便是未加锁时间隙漏洞导致的超卖问题。

高并发下间隙漏洞的常见成因

在 SpringBoot + MyBatis-Plus + ShardingSphere 组合中，未加锁时间隙漏洞的产生往往与以下因素相关：

1. 分布式环境下的 “可见性” 问题

ShardingSphere 的分库分表会将数据分散到不同节点，而分布式系统的 CAP 理论决定了无法同时保证一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）。当多个请求操作不同分片的数据时，由于网络延迟或节点同步问题，一个操作的结果可能无法及时被其他操作感知，从而产生间隙。

例如，用户 A 在分片 1 更新了用户余额，用户 B 同时在分片 2 查询该用户余额（未同步），此时 B 查询到的仍是旧数据，后续操作自然基于错误的数据进行，形成漏洞。

2. MyBatis-Plus 的 CRUD 操作非原子性

MyBatis-Plus 简化了 CRUD 操作，但部分便捷方法可能隐藏着 “查询 + 更新” 的非原子逻辑。例如：

// 先查询再更新，存在间隙
User user = userMapper.selectById(id);
user.setBalance(user.getBalance() - amount);
userMapper.updateById(user);

这种操作在单线程下没问题，但高并发且未加锁时，两个线程可能同时查询到相同的 balance，导致最终更新结果错误。

3. 未正确使用事务或锁机制

SpringBoot 的声明式事务（@Transactional）在分布式环境中可能因配置不当失效（如未使用分布式事务），而 ShardingSphere 的分布式事务支持需要额外配置。在未加锁且事务配置不合理的情况下，多个操作之间的间隙就会成为数据异常的温床。

如何检查系统中的间隙漏洞

识别未加锁场景下的间隙漏洞需要结合业务场景和技术手段，以下是具体可操作的检查方法：

1. 业务场景分析法

梳理核心业务流程（如支付、秒杀、库存扣减等），标记其中涉及 “查询 - 判断 - 操作” 三步的逻辑，这些是间隙漏洞的高发区。例如：

查询库存 → 判断是否充足 → 扣减库存

这类流程天然存在时间间隙，在未加锁时需重点排查。

2. 代码审计：寻找非原子操作

检查 MyBatis-Plus 的使用是否存在 “先查后改” 的非原子操作，尤其是涉及金额、库存等关键字段的代码。可通过以下特征快速定位：

连续调用selectXXX和updateXXX方法
方法中包含基于查询结果的条件判断（如if (stock > 0)）

3. 压力测试：模拟高并发场景

使用 JMeter 或 Gatling 模拟高并发请求，观察数据是否出现异常（如库存为负、订单重复）。测试时需注意：

针对分库分表场景，需覆盖不同分片的并发操作
持续压测至少 30 分钟，观察长期运行下的漏洞暴露

4. 日志追踪：记录操作时间线

在关键操作（查询、更新、删除）中添加详细日志，包括操作时间、线程 ID、分片信息等。例如：

log.info("查询库存 | 商品ID: {} | 分片: {} | 时间: {} | 线程: {}", 
         productId, shardingKey, LocalDateTime.now(), Thread.currentThread().getId());

通过分析日志时间线，可发现两个操作之间的间隙是否导致了数据异常。

预防间隙漏洞的核心技术建议

要解决 SpringBoot + MyBatis-Plus + ShardingSphere 架构中的间隙漏洞，需从操作原子性、锁机制、分布式一致性三个核心维度入手，结合架构特点给出具体方案。

1、用原子 SQL 替代 “查询 - 更新” 非原子操作（最基础有效）

MyBatis-Plus 的 “select+update” 模式是间隙漏洞的重灾区，需直接将逻辑写入 SQL，减少中间间隙。

具体操作：

库存扣减场景：避免先查询再更新，直接用条件更新 SQL，将判断和扣减合并为原子操作。

// 错误方式：先查后改，存在间隙
Stock stock = stockMapper.selectById(id);
if (stock.getStock() > 0) {
    stock.setStock(stock.getStock() - 1);
    stockMapper.updateById(stock);
}

// 正确方式：原子SQL，条件判断与更新同语句
UpdateWrapper<Stock> updateWrapper = new UpdateWrapper<>();
updateWrapper.eq("id", id).gt("stock", 0); // 仅当库存>0时执行扣减
updateWrapper.setSql("stock = stock - 1");
int rows = stockMapper.update(null, updateWrapper);
// 通过返回的rows判断是否更新成功（rows>0则操作有效）
if (rows == 0) {
    throw new RuntimeException("库存不足");
}

优势：SQL 执行由数据库保证原子性，无中间间隙，分库分表下也能生效（ShardingSphere 会将条件路由到对应分片）。

2、按需选择锁机制：悲观锁 / 乐观锁 / 分布式锁

根据并发量和业务场景，选择合适的锁机制堵住间隙：

锁类型	实现方式	适用场景	架构适配注意事项
悲观锁	数据库行锁：`SELECT ... FOR UPDATE`	并发量低、数据一致性要求高（如支付）	ShardingSphere 分表时，需确保锁在分片内生效（通过分片键路由，避免跨分片锁失效）；使用`FOR UPDATE`时，需确保`WHERE`条件中的字段（如`id`）有索引，避免表锁影响并发性能
乐观锁	版本号机制：表加`version` 字段，更新时校验版本	并发量高、冲突少（如秒杀）	MyBatis-Plus 可通过 @Version 注解自动实现，分库分表下需保证版本号在全局唯一（或通过分片键 + 版本号组合唯一）
分布式锁	Redis/ZooKeeper 实现跨节点锁（如 Redisson 的`RLock` ）	跨分片操作、全局资源竞争	需设置合理超时时间，避免死锁；ShardingSphere 环境下建议与分片键绑定锁键；使用 Redisson 等工具时，开启看门狗（Watch Dog）机制自动续期，确保锁持有时间与事务执行时间匹配

示例：悲观锁解决超卖（在事务内加锁查询）

@Transactional
public void deductStock(Long id) {
    // 加行锁查询，其他事务需等待锁释放
    Stock stock = stockMapper.selectByIdForUpdate(id); 
    if (stock.getStock() <= 0) {
        throw new RuntimeException("库存不足");
    }
    stock.setStock(stock.getStock() - 1);
    stockMapper.updateById(stock);
}

（MyBatis-Plus 需自定义selectByIdForUpdate方法，SQL 为SELECT * FROM t_stock WHERE id=? FOR UPDATE）

示例：乐观锁解决超卖（配合重试机制）

@Transactional
public void deductStock(Long id) {
    int retryCount = 3;
    while (retryCount > 0) {
        try {
            Stock stock = stockMapper.selectById(id);
            if (stock.getStock() <= 0) {
                throw new RuntimeException("库存不足");
            }
            stock.setStock(stock.getStock() - 1);
            int rows = stockMapper.updateById(stock);
            if (rows > 0) {
                return;
            }
        } catch (Exception e) {
            retryCount--;
            if (retryCount == 0) {
                throw new RuntimeException("更新失败，请重试");
            }
            // 短暂休眠后重试
            Thread.sleep(100);
        }
    }
}