实战篇-07.优惠券秒杀-实现一人一单功能_哔哩哔哩_bilibili
1.之前的问题
虽然解决了超卖问题，但是无法保证一人只能买一张，容易发生黄牛行为。
2.解决方案
2.1订单查询：判断该用户是否已下单
在库存判断之前，判断用户id和优惠券id是否已经存在，如果存在就停止
但是因为先判断再执行，仍然会出现多线程穿插执行的情况。
为了解决多线程冲突，要加锁
乐观锁因为要根据修改判断版本号，所以只能适用于更新情况。对于多线程查询情况只能用悲观锁。
2.2对订单查询加悲观锁sychronized锁
但是没必要对整个方法加锁，所以这里把后面5，6，7封装到createVoucherOrder方法里。
2.2.1
如果对整个方法加sychronized锁，那么锁监视器是this（当前对象），那么不管什么用户来，监视器都是this，相当于串行执行了，性能差。
2.2.2
一人一单是同一个用户来造成的并发安全问题，所以需要用某个用户的特征作为锁监视器，锁住某个用户的并发操作，而不影响不同用户之间的操作。
toString返回值会new一个String，所以每次都是新对象，即便是同一个用户，每次的锁监视器都不一样。
2.2.3
所以需要intern()方法，相当于只要内容一样，就返回常量池中那个String的地址，而不会返回toString new的地址。
这样就能保证只要用户id一样，字符串内容一样，就能从常量池获取一样的引用返回值，从而保证同一用户锁监视器的一致性。
2.2.4释放锁的时机
因为上述代码锁只到return，而spring会在return之后函数结束之后才提交数据库事务，因此在锁释放到事务提交期间仍有并发问题，所以要把锁括住整个业务函数。
基本解决一人一单问题
2.2.5事务失效
spring 事务失效的 12 种场景_spring 截获duplicatekeyexception 不抛异常-CSDN博客
Spring同一个Service类非事务方法调用事务方法事务失效解决方案-CSDN博客
但是该代码调用事务业务的时候的this不能处理事务，所以有事务失效的可能。所以要拿当前对象的代理对象
