14-java的单例设计模式详解

Posted 2022-04-15 fesng

预加载模式

代码：

public class Singleton

    private volatile static Singleton singleton = new Singleton();
    private Singleton()      
    public static Singleton getInstance()   
        return singleton;
    

分析：

这种方式是预先加载单例，适合于单例对象初始化非常快，而且占用内存非常小，而且使用频繁的时候。
对于单例初始化的操作耗时比较长而应用对于启动速度又有要求，或者单例的占用内存比较大，再或者单例只是在某个特定场景的情况下才会被使用，需要延迟加载提高性能

volatile关键字作用##

1.这个变量不会在多个线程中存在复本，直接从内存读取。

2.这个关键字会禁止指令重排序优化。也就是说，在 volatile 变量的赋值操作后面会有一个内存屏障（生成的汇编代码上），读操作不会被重排序到内存屏障之前。

双重检验锁方式

代码

public class Singleton

    private volatile static Singleton singleton = null;
    private Singleton()      
    public static Singleton getInstance()   
        if (singleton== null)  
            synchronized (Singleton.class) 
                if (singleton== null)  
                    singleton= new Singleton();
                
            
        
        return singleton;
    

singleton = new Singleton()这句，这并非是一个原子操作

事实上在 JVM 中这句话大概做了下面 3 件事情。

1.给 singleton 分配内存
2.调用 Singleton 的构造函数来初始化成员变量，形成实例
3.将singleton对象指向分配的内存空间（执行完这步 singleton才是非 null 了）
但是在 JVM 的即时编译器中存在指令重排序的优化。也就是说上面的第二步和第三步的顺序是不能保证的，最终的执行顺序可能是 1-2-3 也可能是 1-3-2。如果是后者，则在 3 执行完毕、2 未执行之前，被线程二抢占了，这时 instance 已经是非 null 了（但却没有初始化），所以线程二会直接返回 instance，然后使用，然后顺理成章地报错。

volatile关键字作用##

1.这个变量不会在多个线程中存在复本，直接从内存读取。

2.这个关键字会禁止指令重排序优化。也就是说，在 volatile 变量的赋值操作后面会有一个内存屏障（生成的汇编代码上），读操作不会被重排序到内存屏障之前。

内部类方式（优雅）

代码

public class Singleton 
    private static class SingletonHolder 
        private static final Singleton INSTANCE = new Singleton();
    
    private Singleton ()
    public static final Singleton getInstance() 
        return SingletonHolder.INSTANCE;
    

分析

老版《Effective Java》中推荐的方式
利用JVM的类加载机制去实现。在很多情况下JVM已经为我们提供了同步控制，比如：

在static区块中初始化的数据
访问final字段时
等等

因为在JVM进行类加载的时候他会保证数据是同步的

枚举：（优雅的我快那啥了。。。）

代码

public enum Singleton
   INSTANCE;

分析

新版effective java推荐，非常优雅

使用方式

Singleton singleton = Singleton.INSTANCE;

本文参考了如下两篇博客

http://mp.weixin.qq.com/s?__biz=MzA4NTQwNDcyMA==&mid=403126596&idx=1&sn=101c6d4e363213bcdbe1879edeb08736#wechat_redirect
http://blog.csdn.net/haoel/article/details/4028232