模拟一般抢购活动中需要加锁的程序，采用synchronized锁与CAS锁，比较二者的性能。说明二者的区别，并指出合适应该使用CAS锁。
首先创建一个spring boot 的项目，不修改任何默认tomcat的配置，模拟抢购程序耗时100ms
模拟参数并发数200，请求数1000
压测结果如下：
比较惨啊，1000只成功了不到50个线程。这些程序的失败只是说明在压测是时间内程序没有响应（5s以上），后台继续在运行，用监控工具可以看到
实际上处理完1000个线程耗时的时间是两分钟（visualVM反应有点小迟钝），并且可以大致看出spring boot 默认的线程数大概在200（还有一些程序存活的守护线程，我们并不能利用起来），在内存时序图中，可以大致看到，新建一个线程，大概消耗10m的内存。
这些意味着如果你采用synchronized，两分钟内，你的服务处于假死状态（tomcat的线程被占完），不做测试的话其实也能估算出大概的耗时，毕竟主要就是抢购程序内部耗时，每个100ms，1000个就是两分钟左右，加锁的性能很低，不到万不得已不要加重锁。
换成CAS的操作
结果很惊人
0.4s全部完成，虽然只完成了四个抢购，但还是快啊。根据测试的结果，可以大致判断CAS锁的使用场景：快速响应失败。比如会场活动，或者需要连续点击的抢购，不需要按时间点击顺序（这个需要mq的帮助）确定抢购结果的活动。
网友评论