锁和双重检验单例

锁

//一个单体服务下 防止缓存击穿（某个数据缓存过期，然后同时多个线程来查询；缓存穿透是指来查的是空数据）的一个场景
		@Override
    public Map<String, List<Catelog2Vo>> getCatalogJson(){
        /**
         * 1.空结果缓存 ---缓存穿透
         * 2.设置过期时间（随机值）---缓存雪崩
         * 3.加锁 ---缓存击穿
         */
        // 1.加入缓存逻辑
        String catalogJSON = redisTemplate.opsForValue().get("catalogJSON");
        if (StringUtils.isEmpty(catalogJSON)){
            // 2.缓存中没有，从数据库查询
            Map<String, List<Catelog2Vo>> catalogJsonFromDB = getCatalogJsonFromDB();
            // 3.查询到到数据转为JSON字符串放入缓存（缓存中的数据都用JSON传）
            String jsonString = JSON.toJSONString(catalogJsonFromDB);
            redisTemplate.opsForValue().set("catalogJSON", jsonString);
        }
        // 4.把JSON对象逆转[序列化，反序列化]
        Map<String, List<Catelog2Vo>> res = JSON.parseObject(catalogJSON,
                new TypeReference<Map<String, List<Catelog2Vo>>>(){});
        return res;
    }

    // 从数据库查询并封装分类数据
    public Map<String, List<Catelog2Vo>> getCatalogJsonFromDB() {

      synchronized(this){
    // 为什么这这里需要再进行一次校验？
    // 因为高并发的时候，可能很多线程都通过了第一次了校验，然后进入锁前面等着拿这个this锁
    // 当第一个拿到这个锁的线程完成工作后 其他来排队的线程如不再进行一次校验，那么他们都会再进行一次查询
  
    	String catalogJSON = redisTemplate,opsForValue.get("catalogJSON");
    	if(StringUtils.isEmpty(catalogJSON)){
        // 优化，将多次查询改成一次查询
        List<CategoryEntity> selectList = baseMapper.selectList(null);

        // 1.查出所有1级分类
        List<CategoryEntity> level1Categorys = getParent_cid(selectList, 0L);

        // 2.封装数据
        Map<String, List<Catelog2Vo>> res = level1Categorys.stream().collect(Collectors.toMap(k -> k.getCatId().toString(), v -> {
            // k是cid v要进行封装 先找出这个cid的子分类
            List<CategoryEntity> categoryEntities = getParent_cid(selectList, v.getCatId());
            // 封装
            List<Catelog2Vo> catelog2Vos = null;
            if (categoryEntities != null) {
                catelog2Vos = categoryEntities.stream().map(item -> {
                    Catelog2Vo catelog2Vo = new Catelog2Vo(v.getCatId().toString(), null, item.getCatId().toString(), item.getName());
                    // 找当前2级分类的3级分类
                    List<CategoryEntity> level3Catelog = getParent_cid(selectList, item.getCatId());
                    if (level3Catelog != null) {
                        //重新封装需要放在一个2级vo中的3级volist
                        List<Catelog2Vo.Catelog3Vo> collect = level3Catelog.stream().map(l3 -> {
                            Catelog2Vo.Catelog3Vo catelog3Vo = new Catelog2Vo.Catelog3Vo(item.getCatId().toString(), l3.getCatId().toString(), l3.getName());
                            return catelog3Vo;
                        }).collect(Collectors.toList());
                        catelog2Vo.setCatalog3List(collect);
                    }
                    return catelog2Vo;
                }).collect(Collectors.toList());

            }
            return catelog2Vos;
        }));
        return res;
        }
  		}
    }

 

还有一个问题，就是实测下来并不是只有第一个会去查数据库 可能还有一些线程会去查数据库，这是因为第一个线程释放锁以后，在和redis建立连接，存入redis的过程中可能会有其他线程来进行二次校验，这个时候是没可以通过校验的，所以会一些多的查询。

所以我们要调整序列化放入缓存的时间，要保证查数据库和放缓存是圆子操作

单例模式

1、饿汉式单例模式 所谓饿汉式就是不管原来有没有上来就新创建一个 不管肚子里面有没有先吃一个再说

public class Singleton {
     public static Singleton singleton=new Singleton();
     public Singleton(){};
     public static Singleton getSingleton(){
           return singleton;
     }
}

2、饱汉模式单例 所谓饱汉式就是先看下自己吃饱没 没吃饱再吃 吃饱了就直接拍肚

public class Singleton{
	public static Singleton singleton=null;
  public Singleton(){};
  public static Singleton getSingleton(){
         if(singleton==null){
            singleton=new Singleton();
          }
          return singleton;

  }

}

饿汉式反应快但是占资源多 饱汉式反应慢每次都需要检查一下有没有吃饱但是占资源少 为解决饿汉式占资源多的瓶颈出现一种 双重检测的单例模式（有重大缺陷）
3、单例模式的双重检测(双重检测锁定失败的原因是jvm的无序写入，请看代码xxxxxx处 若线程1执行到此处 在构造函数执行之前得到一个非空的对象 线程2再拿的时候是非空 但是不是一个经过赋值的对象)

public class Singleton{
  public volatile static Singleton singleton=null;
  public Singleton(){};
  public static Singleton getSingleton(){
     if(singleton==null){
         synchronized(Singleton.class){
              singleton=new Singleton();  //xxxxxx
          } 
     }
      return singleton;
  }

}

4.1

class Singleton{
    private static Singleton singleton;    
    private Singleton(){}
    
    public static Singleton getInstance(){
        if(singleton == null){
            synchronized(Singleton.class){
                if(singleton == null)
                    singleton = new Singleton();   //创建实例
            }
        }
        return singleton;
    }
}

到这里已经很完美了，看起来没有问题。No！！！因为这种双重检测机制在JDK1.5之前是有问题的，问题还是出在（//创建实例），由所谓的无序写入造成的。

一般来讲，当初始化一个对象的时候，会经历

a. 内存分配

b. 初始化

c. 返回对象引用

这种方式产生的对象是一个完整的对象，可以正常使用。但是JAVA的无序写入可能会造成顺序的颠倒，即

a. 内存分配、

b. 返回对象引用

c. 初始化的顺序，

这种情况下对应到（//创建实例）就是singleton已经不是null，而是指向了堆上的一个对象，但是该对象却还没有完成初始化动作。当后续的线程发现singleton不是null而直接使用的时候，就会出现意料之外的问题。

这里的问题就不是多创建了一个对象了 而是使用一个其实是null 但是看上去不是null的对象导致的了

解决方案： JDK1.5之后，可以使用volatile关键字修饰变量来解决无序写入产生的问题，因为volatile关键字的一个重要作用是禁止指令重排序，即保证不会出现内存分配、返回对象引用、初始化这样的顺序，从而使得双重检测真正发挥作用

public class Singleton{

    private volatile static Singleton instance = null;
    private Singleton() {}

    public static Singleton getInstance() {
            if (instance == null) {
                synchronized (Singleton.class) {
                    if (instance == null) {
                        instance = new Singleton();
                    }
                }
            }
            return instance;
     }
}

4.2、解决单例模式的双重检测 ThreadLocal模式的单例

public class Singleton{
  public static final ThreadLocal  threadInstance=new ThreadLocal();
	public static Singleton singleton=null;
  public static getSingleton(){
     if(threadInstance.get()==null){
         createSingleton();
      }
  }
  public static Singleton createSingleton(){
     synchronized(Singleton.class){
       if(singleton==null){
            singleton=new Singleton();
        }
      }
  }

} 

借助了ThreadLocal的全局变量局部化 第一次检测采用线程局部来做如果线程已经访问过则不需要进入同步块