上篇文章《【Java实战】分布式锁实战之重现高并发场景一》介绍分布式锁使用的前因的准备，这篇文章我们将继续分布式锁重现出现的效果，即借助Jmeter压力测试工具来复现！！让诸位小伙伴能一睹高并发下出现的“数据不一致或者并非预期的结果”的现象！

既然是需要使用Jmeter工具，那在这里建议各位小伙伴先了解了解这个工具才能往下面学习。

上篇文章我们已经基本简单大致模拟搭建了“抢单系统/商城秒杀系统”的抢单场景，下面我们采用Jmeter测试工具来模拟这一高并发场景。

1、首先我们设置1s并发100个线程，后面你可以在这里设置1000、10000甚至更多个线程！

2、接着我们设置 “HTTP信息头管理器” ，因为我们的抢单接口接收的媒体类型是 json格式的post请求！

3、接着我们创建 “HTTP请求” ，设置我们的项目上下文、端口以及我们的请求接口路径跟方法体（ProductLockDto的字段：商品的id跟需要抢的量stock）

4、最后我们设置stock字段来源于我们配置的CSV数据文件设置中读取的变量stock 的值，即代表我们的用户可以任意随机的下单一定的量！！

5、 其中的csv文件是长这样的：

6、最后，我们点击这一按钮，即开启了 1s 内启动100个并发线程对设定的产品进行 “抢” 的请求。

7、这个时候，我们先对这一产品的库存量在数据库进行设置，我们设置为 100，即现有的库存量为100。理论情况下，不管发生多少次的“哄抢”，“最终的库存应当是被抢完而且应当是恰好被抢完，而且需要发送相应的短信/通知告知用户抢到了！！”，然后，现实是很残酷的（当你按下那一个start run的按钮时，数据库最终出现的结果却不是我们预期的那样！！）

8、下面是抢单接口的打印日志以及数据库最终对这一商品更新的结果：

你会惊讶的看到，100个库存在随机产生的100个线程（每个线程获取库存2或者5-csv文件读取的）更新之后竟然变成了负数（按道理来说，我们写的数据库更新逻辑以及代码判断逻辑没有多大问题啊！！！）

实战分析

“按道理来说，我们写的数据库更新逻辑以及代码判断逻辑没有多大问题啊！！！”，实则不然，其实问题正是出在这两点：数据库更新逻辑跟代码判断逻辑 。 欲知问题何在，请听下回分解！！

此篇文章加上篇文章主要是基于SpringBoot微服务项目重现了高并发多线程并发访问同一共享资源时出现的问题，该文章现在debug已将其整理视频教程并更新完毕，如果能结合视频教程来学习，我觉得效果会更佳，领会起来会更快。

推荐阅读：

【重磅发布】SpringBoot实战实现分布式锁视频教程

【Java实战】分布式锁实战之重现高并发场景一