并发测试是如何产生锁、脏数据的
结合数据库底层、事务隔离级别、并发场景，用最直白好懂的逻辑，一次性讲清：并发测试为什么会造出锁、脏读、不可重复读、幻读、脏数据，附带真实业务场景、SQL 过程、锁升级全过程。
一、先搞懂前提：并发是什么
并发测试 =多个线程 / 用户同时操作同一张表、同一行数据数据库默认事务 ACID，为了保证数据不乱，就必须加锁；锁控制不好、隔离级别太低，就直接出脏数据。
简单因果链：
多线程同时改数据 → 数据库必须上锁防冲突 → 锁粒度 / 隔离级别不合适 → 脏读、不可重复读、幻读、数据覆盖错乱 → 脏数据
二、并发为什么会产生【锁】
1. 不加锁会发生什么？
假设两个事务同时修改同一行余额：
- A：余额 100，要减 50
- B：余额 100，要减 50
不加锁并行执行：
- A 读取余额：100
- B 同时读取余额：100
- A 计算：100-50=50，准备写回
- B 计算：100-50=50，准备写回
- 最后数据库余额变成50实际应该扣两次：0这就是丢失更新，属于最典型脏数据。
2. 数据库为了解决上面问题，自动加锁
数据库规则：同一行数据，写操作必须排他只要有事务在修改、插入、删除，数据库就自动上锁，禁止其他事务同时修改。锁本质就是：资源独占标记。
常见锁分类（并发测试必遇）
- 行锁（InnoDB 默认）只锁被修改的那一行，并发好、阻塞少。
- 表锁直接锁整张表，其他所有读写都阻塞，并发差。
- 意向锁、共享锁 (S)、排他锁 (X)
- 共享锁：读加锁，允许多个读，禁止写
- 排他锁：写加锁，禁止读、禁止其他写
3. 并发压测时锁会越来越严重（锁升级）
高并发下会出现：大量单行行锁 → 数据库认为行锁太多开销大 →自动升级为表锁结果：整个表被锁死，所有接口超时、TPS 暴跌、服务雪崩。这就是并发压测经常测出来的锁等待、锁超时、数据库卡顿。
三、并发如何产生【脏数据】（三大经典问题 + 业务脏数据）
数据库标准三大并发问题，全部由隔离级别太低 + 事务未提交导致。MySQL 默认隔离级别：可重复读 RR，仍挡不住幻读；最低隔离级别读未提交 Read Uncommitted全问题暴露。
1. 脏读（Dirty Read）—— 最典型脏数据
过程
- 事务 A 修改数据，但还没提交
- 事务 B 直接读到了 A 未提交的数据
- 之后事务 A回滚，修改作废
- 事务 B 读到的数据就是无效、虚假脏数据
例子：转账
- A 给 B 转 100，事务内更新余额，未提交
- B 查询余额，看到多了 100
- A 事务报错回滚，余额恢复原样
- B 之前查到的数据就是脏数据
2. 不可重复读（Non-repeatable Read）
同一个事务内，多次查询同一行，结果不一样原因：其他事务中途提交了更新、修改。侧重：同一行数据被修改
场景：
- 事务 B 第一次查余额：100
- 事务 A 修改余额为 200 并提交
- 事务 B同个事务内再次查询：变成 200两次结果不一致。
3. 幻读（Phantom Read）
同一个事务内，前后查询记录条数不一样原因：其他事务中途插入、删除数据。侧重：记录行数增减
场景：
- 事务 B 查询用户总数：10 人
- 事务 A 新增一个用户并提交
- 事务 B 再次查询：11 人像凭空多出来数据，像幻觉一样。
4. 业务真实脏数据（开发最常踩坑，压测必现）
不止数据库标准问题，业务层面脏数据：
- 丢失更新（前面余额例子）多线程覆盖更新，后执行的把先执行的结果冲掉。
- 重复扣款、重复下单并发请求重复提交，同一订单创建多条、余额重复扣减。
- 库存超卖高并发减库存，行锁没控制好，库存减成负数。
- 事务长 + 并发高 → 死锁A 锁 B 资源，B 锁 A 资源，互相等待，数据库死锁，接口永久阻塞。
四、完整串起来：并发测试全过程
你做并发压测时，整个链路是这样发生的：
- JMeter/LoadRunner 起大量线程，同时请求接口
- 接口同时开启数据库事务，执行 update/insert
- InnoDB 为防止数据错乱，自动加行排他锁
- 并发量越大，并行事务越多，锁竞争越激烈
- 部分事务读取其他未提交事务的数据→脏读
- 多个事务同时更新同一行 →丢失更新
- 行锁数量过多 →锁升级为表锁，数据库阻塞
- 事务互相等待资源 →死锁
- 超时回滚异常、数据错乱、余额不对、库存超卖 →最终脏数据
五、一句话总结
并发产生锁的原因多线程同时修改数据，数据库为防止数据错乱，强制加锁独占资源；并发越高锁竞争越严重，甚至锁升级、死锁。
并发产生脏数据的原因
- 隔离级别低，读到未提交回滚的数据（脏读）
- 事务交叉修改，覆盖更新、丢失更新
- 插入删除导致前后查询不一致（幻读）
- 长事务 + 锁竞争，导致异常回滚、数据错乱、业务超卖重复操作
六、附带解决方案（面试必背）
- 提高数据库隔离级别：RR → Serializable
- 加悲观锁
select ... for update - 乐观锁：版本号 version 控制更新
- 业务加分布式锁（Redis 锁）防止重复请求
- 缩短事务时长，避免长事务锁占用
- 索引优化，避免无索引导致行锁升级表锁
- 接口幂等设计，防重复下单扣款