单例模式(Singleton Pattern)

一、简述

单例模式是 Java 中最简单的设计模式之一。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。这种模式涉及到一个单一的类，该类负责创建自己的对象，同时确保只有单个对象被创建。这个类提供了一种访问其唯一对象的方式，可以直接访问，不需要实例化该类的对象。即两私一公：①私有的构造函数②私有静态实例属性③公共的获取实例的静态方法。

1️⃣注意

  1. 单例类只能有一个实例。
  2. 单例类必须自己创建自己的唯一实例。
  3. 单例类必须给所有其他对象提供这一实例。

2️⃣资源加载和性能

饿汉式在类创建的同时就实例化一个静态对象出来，无论会不会用到，都会占据一定的内存。相应的，在第一次调用时速度更快，因为其资源已经初始化完成。

懒汉式，会延迟加载，在初次使用该单例时才会实例化对象出来。首次调用时要做初始化，如果要做的工作比较多，性能会有所延迟，之后就和饿汉式一样了。

主要解决：一个全局使用的类频繁地创建与销毁。
何时使用：当想控制实例数目，节省系统资源的时候。
如何解决：判断系统是否已经有这个单例，有则返回，没有则创建。
关键代码：构造函数是私有的。

3️⃣应用实例

  1. 一个男人只能有一个妻子。
  2. Windows 是多进程多线程的，难免会出现多个进程或线程同时操作一个文件的现象，所以所有文件的处理必须通过唯一的实例来进行。
  3. 一些设备管理器常常设计为单例模式。比如一个电脑有两台打印机，在输出的时候就要处理不能两台打印机打印同一个文件。

4️⃣优点

  1. 在内存里只有一个实例，减少了内存的开销，尤其是频繁的创建和销毁实例(比如管理学院首页页面缓存)。
  2. 避免对资源的多重占用(比如写文件操作)。

5️⃣缺点

没有接口，不能继承，与单一职责原则冲突，一个类应该只关心内部逻辑，而不关心外面怎么样来实例化。

6️⃣使用场景

  1. 要求生产唯一序列号。
  2. WEB 中的计数器，不用每次刷新都在数据库里加一次，用单例先缓存起来。
  3. 创建的一个对象需要消耗的资源过多，比如 I/O 与数据库的连接等。

二、饿汉式---线程安全

饿汉就是类一旦加载，就把单例初始化完成，保证 getInstance 的时候，单例已经存在。

  • 描述：这种方式比较常用，但容易产生垃圾对象。
  • 优点：没有加锁，执行效率会提高。
  • 缺点：类加载时就初始化，浪费内存。
  • 它基于 classloder 机制避免了多线程的同步问题。不过，instance 在类装载时就实例化，虽然导致类装载的原因有很多种，在单例模式中大多数都是调用 getInstance 方法， 但是也不能确定有其他的方式(或者其他的静态方法)导致类装载，这时候初始化 instance 显然没有达到 lazy loading 的效果。
public class EagerSigleton() {
    //持有自己的引用
    private static final EagerSigleton m_instatnce = new EagerSigleton();
    //构造器私有化，不能在类的外部随意创建对象
    private EagerSigleton() {
    }
    //提供一个全局的访问点来获得这个“唯一”的对象
    public static EagerSigleton getInstance() {
        System.out.println("加载饿汉式....");
        return m_instatnce;
    }
}

静态代码块实现：

public class EagerSigleton{
    private static EagerSigletoninstance;
    static {
        m_instatnce = new EagerSigleton();
    }
    private EagerSigleton() {}
    public static EagerSigletongetInstance() {
        return m_instatnce;
    }
}

这种方式和上面的方式其实类似，只不过将类实例化的过程放在了静态代码块中，也是在类装载的时候，就执行静态代码块中的代码，初始化类的实例。优缺点和上面是一样的。

三、懒汉式---非线程安全

  • Lazy 初始化。
  • 描述：最基本的实现方式，最大的问题就是不支持多线程。因为没有加 synchronized 锁，所以严格意义上它并不算单例模式。
  • 这种方式 lazy loading 很明显，不要求线程安全，在多线程不能正常工作。
public class LazySigleton(){
  private static LazySigleton instatnce=null;
  // 构造器私有化,不能在类的外部随意创建对象
  private LazySigleton(){}
  // 提供一个全局的访问点来获得这个"唯一"的对象
  public static LazySigleton getInstance(){      
       if(instatnce == null){               //1：读取instance的值
          instatnce = new LazySigleton();   //2: 实例化instance   
        }            
        return instatnce;        
    }
}

懒汉比较懒，只有当调用 getInstance 的时候，才会去初始化这个单例。

四、懒汉非线程安全原因(两点)

对于以上代码注释部分，如果此时有两个线程，线程甲执行到 1 处读取了 instance 为 null，然后 cpu 就被线程乙抢去了，此时线程甲还没有对 instance 进行实例化。因此，线程乙读取 instance 时仍然为 null，于是它对 instance 进行实例化了。然后，cpu 时间片轮到线程甲。此时，线程甲已经读取了 instance 的值并且认为它为 null，再次对 instance 进行实例化。所以，线程甲和线程乙返回的不是同一个实例。

如何解决呢？

  1. 在方法前面加 synchronized 修饰。这样肯定不会再有线程安全问题。
public class LazySigleton(){
    private static LazySigleton instatnce=null;
    private LazySigleton(){}
    public static synchronized LazySigleton getInstance(){      
      if(instatnce == null){        
         instatnce = new LazySigleton();      
       }            
       return instatnce;        
     }
}

这种解决方式有个问题：假如有 100 个线程同时执行，那么每次去执行 getInstance 方法时都要先获得锁再去执行方法体。如果没有锁就要等待，耗时长，像是变成了串行处理。
特点：
性能不高，同步范围太大。在实例化后，获取实例仍然是同步的，效率太低，需要缩小同步的范围。

  1. 加同步代码块，减少锁的颗粒大小。判断 instance 是否为 null 是读的操作，不存在线程安全问题。因此，只需要对创建实例的代码进行同步代码块的处理，也就是所谓的对可能出现线程安全的代码进行同步代码块的处理。
public class LazySigleton(){
    private static LazySigleton instatnce=null;
    private LazySigleton(){}
    public static LazySigleton getInstance(){      
         if(instatnce == null){ 
            synchronized (LazySigleton.class){       
               instatnce = new LazySigleton();      
            }  
          }          
          return instatnce;        
      }
}

这样处理就没有问题了吗？同样的原理，线程甲读取 instance 值为 null，此时 cpu 被线程乙抢去了，线程乙判断 instance 值也为 null，于是它开始执行同步代码块，对 instance 进行实例化。此时，线程甲获得 cpu，由于线程甲之前已经判断 instance 值为 null，于是开始执行它后面的同步代码块。它也会去对 instance 进行实例化。这样就导致了还是会创建两个不一样的实例。
特点：
缩小同步范围，来提高性能，但是仍然存在多次执行instance=new Singleton()的可能，由此引出 double check。

如何解决上面的问题？

很简单，在同步代码块中 instance 实例化之前进行判断，如果 instance 为 null，才对其进行实例化。这样，就能保证 instance 只会实例化一次了。也就是所谓的双重检查加锁机制。

再次分析上面的场景：
线程甲读取 instance 值为 null，此时 cpu 被线程乙抢去了，线程乙再来判断 instance 值为 null。于是，它开始执行同步代码块，对 instance 进行了实例化。这时线程甲获得 cpu 执行权，当线程甲去执行同步代码块时，它再去判断 instance 的值，由于线程乙执行完后已经将这个共享资源 instance 实例化了，所以 instance 不再为 null，所以，线程甲就不会再次实行实例化代码了。

public class LazySigleton() {
    private LazySigleton(){}
    private static LazySigleton instatnce=null;
    public static LazySigleton getInstance(){
        if(instatnce== null) {
            synchronized (LazySigleton.class){
                if (instatnce == null){
                    instatnce = new LazySigleton();
                }
            }
        }
        return instatnce;
    }
}

双重检查加锁并不表示一定没有线程安全问题了。因为，Java内存模型(JVM)并不限制处理器重排序。instatnce = new LazySigleton()并不是原子语句，其实可以分为下面的步骤：

  1. 申请一块内存空间；
  2. 在这块空间里实例化对象；
  3. instatnce 的引用指向这块空间地址(instatnce 指向分配的内存空间后就不为 null 了)。
    【由此可理解，Java 中 new 操作是不具有原子性的】

指令重排序存在的问题是：
对于以上步骤，指令重排序很有可能不是按上面【1、2、3】步骤依次执行的。比如，先执行 1 申请一块内存空间，然后执行 3，instatnce 的引用去指向刚刚申请的内存空间地址。那么，当它再去执行 2，判断 instatnce 时，由于 instatnce 已经指向了某一地址，它就不会再为 null 了，因此，也就不会实例化对象了。这就是所谓的指令重排序安全问题。那么，如何解决这个问题呢？

加上 volatile 关键字，因为 volatile 可以禁止指令重排序。volatile 可以保证【1、2、3】的执行顺序，没执行完 1、2 就肯定不会执行 3，也就是没有执行完 1、2，instance 一直为空。这样就可以保证 3(instance 赋值操作)是最后一步完成，这样就不会出现 instance 在对象没有初始化时就不为 null 的情况了。这样也就实现了正确的单例模式。具体代码如下：

public class LazySigleton() {
    private LazySigleton(){}
    private static volatile LazySigleton instatnce=null;
    public static LazySigleton getInstance(){
        if(instatnce== null) {
            synchronized (LazySigleton.class){
                if (instatnce == null){
                    instatnce = new LazySigleton();
                }
            }
        }
        return instatnce;
    }
}

附：
1️⃣静态内部类懒汉模式

public class Singleton{
    private Singleton(){}
    public static Singleton getInstance(){
        return InstanceHolder.instance;
    }
    static class InstanceHolder{
        private static Singleton instance=new Singleton();
    }
}

静态内部类在没有显示调用的时候是不会进行加载的，当执行了
return InstanceHolder.instance后才加载初始化，这样就实现了正确的单例模式。
2️⃣利用枚举的特性在 JVM 层保证绝对的单例

class EnumSingleton {
      //私有构造函数，防止new对象
      private EnumSingleton() {}
      public static EnmuSingleton getInstance() {
          return Singleton.INSTANCE.getSingleton();
      }
      //JVM层保证绝对单例
      private enum Singleton {
          INSTANCE;
          private EnumSingleton singleton;
          Singleton() {
                singleton = new EnumSingleton();
          }
          public EnumSingleton getSingleton() {
                  return singleton;
          }
      } 
}

为啥枚举的单例就完美了？枚举本身是无法通过反射、克隆、反序列化等等把对象初始出来的。

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 216,591评论 6赞 501
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 92,448评论 3赞 392
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 162,823评论 0赞 353
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 58,204评论 1赞 292
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 67,228评论 6赞 388
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 51,190评论 1赞 299
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 40,078评论 3赞 418
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 38,923评论 0赞 274
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 45,334评论 1赞 310
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,550评论 2赞 333
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,727评论 1赞 348
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 35,428评论 5赞 343
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 41,022评论 3赞 326
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,672评论 0赞 22
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,826评论 1赞 269
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 47,734评论 2赞 368
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 44,619评论 2赞 354