单例模式

最新推荐文章于 2024-07-25 13:59:31 发布

千g

最新推荐文章于 2024-07-25 13:59:31 发布

阅读量548

点赞数

分类专栏：设计模式设计模式

本文链接：https://blog.csdn.net/n950814abc/article/details/61630164

版权

设计模式同时被 2 个专栏收录

6 篇文章 0 订阅

订阅专栏

设计模式

6 篇文章 0 订阅

订阅专栏

单例模式介绍：

一：定义

保证一个类仅有一个实例，并提供一个访问它的全局访问点。

二：特点

1.单例模式的类只提供私有的构造函数

2.类定义中含有一个该类的静态私有对象

3.该类提供了一个静态的共有的函数用于创建或获取它本身的私有对象

饿汉式单例类：

在自己被加载时就将自己实例化

第一种方法：

特点：类一加载就实例化的对象，所以要提前占用系统资源。典型的空间换取时间。

不用显示的编写线程安全的代码，它本身是线程安全的。

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

第二种：静态内部类（推荐）：

这种方式能达到双检锁方式一样的功效，但实现更简单。对静态域使用延迟初始化，应使用这种方式而不是双检锁方式。这种方式只适用于静态域的情况，双检锁方式可在实例域需要延迟初始化时使用。
这种方式同样利用了 classloader 机制来保证初始化 instance 时只有一个线程，它跟第一种方式不同的是：第一种方式只要 Singleton 类被装载了，那么 instance 就会被实例化（没有达到 lazy loading 效果），而这种方式是 Singleton 类被装载了，instance 不一定被初始化。因为 SingletonHolder 类没有被主动使用，只有通过显式调用 getInstance 方法时，才会显式装载 SingletonHolder 类，从而实例化 instance。想象一下，如果实例化 instance 很消耗资源，所以想让它延迟加载，另外一方面，又不希望在 Singleton 类加载时就实例化，因为不能确保 Singleton 类还可能在其他的地方被主动使用从而被加载，那么这个时候实例化 instance 显然是不合适的。这个时候，这种方式相比第一种方式就显得很合理。

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

懒汉式模式：

第一种方法：线程不安全

懒汉模式，有线程安全问题：

在第一次被引用时，才会将自己实例化

特点：面临着多线程访问的安全性问题。

public class Singleton {
    // 懒汉模式-有线程安全问题
    private static Singleton instance;

    private Singleton() {
    }

    public static Singleton getInstance() {
        if (instance == null) {
// 如果多个线程同时进入到这里就会创建多个实例
            instance = new Singleton();
        }
        return instance;
    }

}

测试：

 public static void main(String[] args) {

        Thread t1 = new Thread(new Runnable() {
            @Override
            public void run() {
                Singleton singleton1  = Singleton.getInstance();
                System.out.println(singleton1.hashCode());
            }
        });

        Thread t2 = new Thread(new Runnable() {
            @Override
            public void run() {
                Singleton singleton2 = Singleton.getInstance();
                System.out.println(singleton2.hashCode());
            }
        });

        Thread t3 = new Thread(new Runnable() {
            @Override
            public void run() {
                Singleton singleton3 = Singleton.getInstance();
                System.out.println(singleton3.hashCode());
            }
        });

        Thread t4 = new Thread(new Runnable() {
            @Override
            public void run() {
                Singleton singleton4 = Singleton.getInstance();
                System.out.println(singleton4.hashCode());
            }
        });

        t1.start();
        t2.start();
        t3.start();
        t4.start();
    }

第二种方法：懒汉加锁

在getInstance()上面加上synchronized关键字

懒汉线程安全：

第一种办法：在getInstance()上面加上synchronized关键字，但这种方法有很大的缺点，那就是并发效率太低。

 // 懒汉模式-线程安全(并发效率太低)
    private static Singleton instance;

    private Singleton() {
    }

    public static synchronized Singleton GetInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }

第三种方式：双重锁/双重检验锁（推荐）：

getDs()方法中添加了类锁(synchronized (DubbleSingleton.class))，这种锁直接把整个类都锁住了，其它线程访问这个类的任何方法都要排队等候，目的是当第一个线程访问getDs()方法时，它把整个类锁住，然后它把这个类实例化，然后后面的线程进入getDs()方法后一判断发现ds已经不是null了，于是便把第一个线程实例化好的实例返回。这样后续的线程无论并发有多少都没有问题，也不用再排队，直接拿取实例化好的实例即可。

既然这样，为何在synchronized (DubbleSingleton.class)当中再判断一次ds是否为null呢？

synchronized上面不是模拟了一下初始化对象的准备时间吗？这个模拟是很有必要的，当第一个线程进入getDs()方法后，判断了一下df是否为null，发现是null，然后它就进入初始化对象的准备工作中去了，这个过程可能需要几秒钟，注意这时第一个线程还没有执行到synchronized这一行代码，也就是说还没有加上类锁，在这个过程当中假如又有多个线程要调用getDs()方法，它们便可以同时访问这个方法，这些线程判断ds依然是null，因此会进入到if判断里面，这些线程也进入到初始化对象的准备过程，等到第一个线程初始化对象准备完毕之后，它进入到synchronized这块代码处，给整个类加上了锁，这时后续再有线程的话，就要排队等候调用getDs()了。等第一个线程执行完实例化代码之后，刚才那些趁第一个线程没有锁住类的间隙偷偷摸进来的线程便也都进入到synchronized代码处，这些线程会依次锁住类进入到synchronized代码块中，这时如果代码块中不加一层if判断的话，就会再实例化一次DubbleSingleton类并返回，有几个这样偷溜进来的线程便会实例化几次Dubblesingleton实例。除了这些偷溜进来的线程之外，再来访问的线程由于在类外等待第一个线程执行完之后才有机会进入到方法体中，这时ds早已经实例化过了，因此第一个if判断便不成立，于是直接把当前Dubblesingleton实例返回。也就是说，后面的线程便可以高并发了，不用受锁的限制了。而如果在synchronized锁内再加一层判断的话，由于第二个线程进入锁内时，第一个线程肯定已经执行完了（synchronized这时扮演的是类锁），因此这时ds肯定不是null了，第二个线程一判断，发现ds不为null了，便直接把第一个线程实例化好的实例返回了，同理，其它线程也把第一个线程实例化好的实例返回。从而保证了线程安全。
双重检查与懒汉加锁模式最大的区别在于，双重检查加锁只是一瞬间的事儿，后续无论有多少个线程都可以自由访问，没有线程安全问题。而懒汉加锁模式由于每个线程都要排队访问getInstance方法，因此效率太低。这就是他们之间的区别。

public class DubbleSingleton {  
      
    private static DubbleSingleton ds;  
      
    public static DubbleSingleton getDs(){  
        if(ds == null){  
            try {  
                //模拟初始化对象的准备时间...  
                Thread.sleep(3000);  
            } catch (Exception e) {  
                e.printStackTrace();  
            }  
// 给类加锁
            synchronized (DubbleSingleton.class) {  
                if(ds == null){  
                    ds = new DubbleSingleton();  
                }  
            }  
        }  
        return ds;  
    }

双重加锁也不是很严谨：

博客参考：https://www.jianshu.com/p/1c72a061b40e

public class Singleton {

    // 线程安全的懒汉式单例
    //使用volatile关键字防止重排序，因为 new Instance()是一个非原子操作，可能创建一个不完整的实例
    private static volatile Singleton singleton;

    private Singleton() {
    }

    public static Singleton getSingleton3() {
        // Double-Check idiom
        if (singleton == null) {
            synchronized (Singleton.class) {      
                // 只需在第一次创建实例时才同步
                if (singleton == null) {
                    singleton = new Singleton();     
                }
            }
        }
        return singleton;
    }
}