归纳一下修改后的逻辑：
1.查询缓存，如果缓存存在，返回结果
2.缓存不存在，查询数据库
3.争夺分布式锁
4.成功获得锁，再次判断缓存的存在
5.如果缓存仍旧不存在，把查询数据库的结果循环放入缓存
6.释放分布式锁
这种二次判断存在性的机制有一个专门的名字，叫做双重检测。该方法在线程安全的单例模式中也常常被用到。
几点补充：
1.文中所使用的分布式锁，其实并不是“正宗”的分布式锁，当线程争夺锁失败的时候，会直接返回查询DB的结果，而不会依靠自旋机制来等锁。
2.为什么优惠券列表的信息要使用List类型来存入缓存，而不是把整个列表存为一个很长的Json字符串？这是由于业务需要，使用List在某些情况下更方便对单个优惠券信息进行修改（LSET指令）。
3.为什么优惠券列表的信息不使用Redis的Set或者Hash数据类型来存储，实现自动去重呢？对于Set类型，去重前需要对比整个字符串是否完全相同，而每一张优惠券是一个较长的Json字符串，对比的效率会比较低。使用Hash倒是可以实现高效的去重，但并未在根本上解决重复更新的问题。