在上一篇, Redis实战11-实现优惠券秒杀下单 我们已经把超卖问题解决了。接下来,我们来开发,优惠券一人一单功能。通过本文学习,您将有如下收获:
1:悲观锁、乐观锁的使用场景;
2:synchronized关键字,在不同位置,锁的颗粒度是不同的,怎么优化呢;
3:toString方法之后,不能保证唯一,如果要保证唯一,需要在调用String的intern方法;
4:对spring事务有更深入了解-解决spring事务失效一种情况;
5:spring boot怎么开启对AspectJ的支持。
因为涉及到的知识点比较多,所以,这篇文章会比较长,但是凯哥(kaigejava)可以很负责地告诉大家,学习完本篇之后,你一定会有收获的。希望大家能耐心学完。好了,话不多少了,咱们开始学习吧~
我们来看看上一篇,解决超卖问题时候,100个优惠券领取情况:
都是被同一个用户领取了,这肯定不符合实际业务情况。
我们在原有业务中,订单入库之前,添加一人一单相关代码逻辑:
我们同样使用JMeter并发跑下试试:
设置登录状态请求头是一个用户的
我们,来看看执行结果:
异常率是95%。这不对啊,95%,意味着有10个成功的,不是一人一单吗?怎么这一人10单呢?
我们看看数据库中库存情况:
再来看看订单:
果然是10个单子。这个不符合我们实际业务情况啊。出现了一人多单的情况了。
其实和超卖情况是一样的,先查询,再判断。当多线程过来的时候,依然会出现多个线程竞争同一个资源并发安全问题。通过超卖问题,我们知道,可以通过加锁方法来解决。
我们需要知道乐观锁和悲观锁使用的场景:
乐观锁:更新数据的时候,可以使用
悲观锁:插入数据的时候。
那么,在我们这个一人一单场景下,是用乐观锁还是用悲观锁呢?应该用悲观锁。为什么呢?因为,我们查询的是数据是否存在。而不是更新数据的。
我们还需要分析,悲观锁代码块的添加范围是什么?悲观锁代码块范围应该是,查询是否已经抢到过优惠券、扣除库存以及优惠券订单入库这些逻辑都应该被悲观锁锁管理。
所以,我们就来对相关代码做抽取后进行封装:悲观锁,我们使用synchronized关键字来加锁。
如下图:
我们将锁直接加到方法上,可以吗?我们需要知道,如果我们在方法上加锁的话,
1:锁对象就是this.当前类对象。锁的粒度很大
2:整个方法都被锁住了。所有调用这个方法的线程,都要排队等候,前面线程释放锁之后,才可以继续操作。这就将并行强制转成串行了
3:我们其实是想处理的,同一个用户多下单情况。是同一个用户,如果张三和李四都过来抢,这种情况下,锁不应该生效才对。
根据上面的分析,我们将synchronized修改,不放到方法上。放到方法体内。锁对象也不用this。使用用户id
修改后:
我们再来分析,锁对象,userId.toString().真的能保证,不同用户锁对象是不同的,同一个用户锁对象是相同的吗?这里其实就考察了,我们对Long的toString()方法理解了。我们来看看Long对象的toString方法源码:
哦吼~~。看到什么了?竟然是new String的。我们知道,new关键字创建的对象在内存中是地址值是不一样的。我们可以写个小demo测试下:
看到结果了吗?toString后,是false。
通过上面的小demo,我们可以知道,如果我们直接使用用户id.toString()。作为锁对象的话,是会出问题的。既然使用id.toString不行,那么,我们可以考虑怎么改进。
我们知道,Java中String对象都是static fianl的,我们也知道有个常量池这个东西。String对象,在创建时候,先去常量池中获取,若存在,则直接返回常量池中相应Strnig的引用;若不存在,则会在常量池中创建一个等值的String,然后返回这个String在常量池中的引用。那么,我们可以不可以利用String这一特性来实现呢?答案是:可以的。
我们使用String.intern()方法就可以。
Java的String对象中intern()方法是干嘛的?
String.intern()是一个Native方法,底层调用C++的 StringTable::intern方法实现。当通过语句str.intern()调用intern()方法后,JVM 就会在当前类的常量池中查找是否存在与str等值的String,若存在,则直接返回常量池中相应Strnig的引用;若不存在,则会在常量池中创建一个等值的String,然后返回这个String在常量池中的引用。
(1)在jdk6中,字符串常量池在永久代,调用intern()方法时,若常量池中不存在等值的字符串,JVM就会在字符串常量池中创建一个等值的字符串,然后返回该字符串的引用;
(2)在jdk7/8中,字符串常量池被移到了堆空间中,调用intern()方法时,如果常量池已经存在该字符串,则直接返回字符串引用,否则复制该堆空间中字符串对象到常量池中并返回。
根据上面分析,有了理论知识,我们还是来个小demo,测试下:
看到什么了?使用string.intern()方法后,返回的是true.这就保证了,同一个用户id,在多次进入方法后,是同一个锁对象了。所以,我们修改锁对象:
将synchronized关键字由写在方法上,修改到如上代码,锁对象变化。锁的颗粒度变小了,性能比写在方法上有很大的提升。那么上面这么写,还有问题吗?答案是:还存在问题。
我们再来看看,synchronized代码块完整的代码如下图:
我们看到,方法上加了@Transactional注解,说明这个方法是在事务里面的。事务是被spring控制的,而synchronized关键字是在方法内部的。也就是说,是在事务内加锁的。这种情况下,可能会导致当前方法事务还没有提交,但是锁已经被释放掉了。因为,执行完save order后,锁的代码块就执行完了,锁就被释放了,但是事务的方法还没执行完成,事务可能还没有提交。事务没提交,根据spring事务传播机制,我们可以知道,可能还会存在问题的。线程1事务未提交,但是已经释放锁了,那么线程2就可以获取到锁,执行查询操作,因为线程1事务还未提交,就导致线程2查询数据库时候,查询count为0,就接着执行插入业务了。从而导致了一个人还是多单的情况。通过上面的分析,我们知道,是因为先释放锁,后提交事务,导致了一人多单情况。那么我们解决方案就是,可不可以先提交事务,在释放锁呢?修改后代码如下:
那么,上面代码是否存在问题呢?还是存在问题的!!存在什么问题呢?事务可能不生效。为什么呢?
我们再来看看整个秒杀抢券代码:
在调用doCreateOrder方法的时候,其实就是this.doCreateOrder().如下图:
这里的this是谁呢?就是我们当前类对象,也就是VoucherOrderServiceImpl这个对象。我们知道,spring的事务,其实是由动态代理对象来操作的。从上面的代码中,我们分析出this了,是真实的目标对象,不是代理对象。所以,事务是否会生效呢?这种情况下,会导致事务失效的。这就是spring事务失效的几种情况之一。
其实,我们在调用doCreateOrder方法的时候,不能直接用this调用,我们需要使用其代理对象来调用才可以。那么怎么获取当前对象的代理对象呢?
我们可以使用:Object proxy = AopContext.currentProxy()
修改代码:
代码都已经写完了。我们重启服务,然后再使用JMeter跑下,查看结果:
异常率是:99.5%,符合我们的预期。我们来看看数据库中的库存:
再来看看订单是否一条数据:
多并发报告、库存以及订单数据都符合我们的预期值,那么我们就解决了一人一单的问题。
大家好,我是凯哥Java(kaigejava),乐于分享技术文章,欢迎大家关注“凯哥Java”,及时了解更多。让我们一起学Java。也欢迎大家有事没事就来和凯哥聊聊~~~。
如操作有问题欢迎去 我的 个人博客(www#kaigejava#com)留言或者 微号(凯哥Java。Kaigejava或者kaigejava2022)留言交流哦。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。