设计模式(二):深入剖析单例模式(懒汉,饿汉,枚举,容器)

最新推荐文章于 2024-01-15 23:32:53 发布

陈橙橙丶

最新推荐文章于 2024-01-15 23:32:53 发布

阅读量5.3k

点赞数 2

分类专栏： JAVA 设计模式文章标签： java 设计模式多线程反射 spring

本文链接：https://blog.csdn.net/qq_40409260/article/details/104959398

版权

JAVA 同时被 2 个专栏收录

41 篇文章 1 订阅

订阅专栏

设计模式

4 篇文章 0 订阅

订阅专栏

单例模式(Singleton Pattern) 是指确保一个类在任何情况下都绝对只有一个实例,并提供一个全局的访问点。比方说，你只能有一个女朋友,你是new不出来的.

前言

写文章的目的主要是为了自己知识的巩固,当然也十分希望在此能够得到业界前辈们的指导。

本文主要围绕:懒汉单例、饿汉单例、枚举单例、容器单例。以及会分析他们为什么会是线程安全和不安全。

一、饿汉单例

该单例模式咱们直接看代码,因为比较简单。

1.1 直接声明

public class HungrySingleton {
	//声明一个实例 final修饰
    private static  final HungrySingleton hungrySingleton = new HungrySingleton();
    //私有化构造函数
    private HungrySingleton(){}
    //提供访问点
    public static HungrySingleton getInstance(){
        return hungrySingleton;
    }
}

1.2 使用静态块加载

public class HungrySingleton {
    private static  final HungrySingleton hungrySingleton ;
    static {
        hungrySingleton = new HungrySingleton();
    }
    private HungrySingleton(){}
    public static HungrySingleton getInstance(){
        return hungrySingleton;
    }
}

以上两种方法并没有特别之处,看个人喜欢选择.
饿汉单例:
1.私有化构造函数
2.对外提供一个访问点.

优点：
1.属性线程安全的(为什么是线程安全的?)
2.没有加任何的锁、执行效率比较高，
缺点：
浪费内存空间(因为只要类被加载就会创建一个实例。)

解释一下为什么是线程安全的,其实很容易理解,私有化了构造函数,无法主动创建实例,该类在被加载的时候创建了一个实例。也就是说在线程还没出现就已经实例化了，所以不存在线程安全问题。
对于饿汉单例的缺点,懒汉模式解决它的缺点。

二、懒汉单例

懒汉式单例,在第一次调用的时候实例化本身。

public class LazySimpleSingleton {
    private static LazySimpleSingleton lazy = null;
    
    private LazySimpleSingleton (){};
    
    //此处可以看做是一个简单的工厂方法.
    public static LazySimpleSingleton getInstance(){
        if(lazy == null){
            //此处有可能会出现两个实例，所以是线程不安全的
            lazy = new LazySimpleSingleton();
        }
        return lazy;
    }
}

懒汉式单例的设计,确实是在一定程度上解决了饿汉单例带来的内存浪费问题，但是也因此暴露了新的问题，那就是线程安全问题。下面请看,模拟两个线程

public class LazySimpleSingletonTest implements Runnable{
    @Override
    public void run() {
        LazySimpleSingleton simpleSingleton = LazySimpleSingleton.getInstance();
        System.out.println(Thread.currentThread().getName()+":"+simpleSingleton);
    }
}

public static void main(String[] args) {
        Thread t1 = new Thread(new LazySimpleSingletonTest());
        Thread t2 = new Thread(new LazySimpleSingletonTest());
        t1.start();
        t2.start();
}

Thread-0:com.gp.singleton.lazy.LazySimpleSingleton@5ee86afd
Thread-1:com.gp.singleton.lazy.LazySimpleSingleton@6f8ef171

此处就出现了线程安全问题,线程本身就是存在概率的你可以多测几次。
那么会什么会出现这个问题呢？
$\color{#FF0000}{我们来进行断点测试(使用线程debug)}$
在以下两处打个断点,右键断点选择Thread可以选择线程模式。
在这里插入图片描述

当第一个线程进入到if方法中的时候切换线程(从Thrad0切换到Thrad1,目的为了让两个线程同时处在if方法中) $\color{#FF0000}{注意Thrad0还没有赋值}$

当Thread1进入到if方法中的时候可以先让Thread1执行完，在切换Thread0执行完毕！
我们来看下结果.
在这里插入图片描述

你就会发现此处就出现了两个实例了.破坏了单例的原则。因为线程本来就是抢时间执行的，当A线程执行到if中被B线程夺走了执行权，那么只要当他们同时进入到if中那么就都会new个各自的实例出来。

解决方法1：

给方法加上synchronized关键字

public synchronized static LazySimpleSingleton getInstance(){
        if(lazy == null){
            //此处有可能会出现两个实例，所以是线程不安全的
            lazy = new LazySimpleSingleton();
        }
        return lazy;
    }

synchronized 的作用是可以让此方法变成线程同步的方法。如果这个时候当我们将其中一个线程执行并调用getInstance()方法时，另一个线程在调用 getInstance()方法，线程的状态由RUNNING 变成了MONITOR,出现阻塞。直到第一个线程执行完，第二个线程才恢复RUNNING状态继续调用getInstance()方法。
这里就不给大家演示了。
$\color{#FF0000}{注意synchronized}$ 使用此方法能够解决线程安全问题，虽然JDK1.6之后就对synchronized性能做了优化，但是还是会不可避免的造成一些新的问题。
例如：当线程数较多的情况下使用 $\color{#FF0000}{synchronized}$ 加锁，会出现类锁，导致大批线程阻塞，从而导致性能大幅度下降。那么有没有解决办法呢？使用 $\color{#FF0000}{双重检查锁}$

解决方法2：

双重检查锁
我们修改一下getInstance()方法

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

解释一下：当第一个线程调用getInstance()方法时，第二个线程也可以调用getInstance()。当第一
个线程执行到synchronized时会上锁，第二个线程就会变成MONITOR 状态，出现阻塞。此时，阻塞并不是基于整个LazySimpleSingleton类的阻塞，而是在getInstance()方法内部阻塞。在逻辑不是很复杂的条件下对于调用者是不会察觉到的。
但是使用 $\color{#FF0000}{synchronized}$ 关键字就会在一定程度上降低性能，因为不管怎么样总会上锁。优化：使用静态内部类

解决方法3

静态内部类
此方法也能实现线程安全，性能最优
优点：
1.没有synchronized关键字，提高了性能
2.内部类会先加载。当外部方法调用了getInstance时才会返回一个实例.
这种形式兼顾饿汉式的内存浪费，也兼顾synchronized性能问题，为什么这么说呢？
因为内部类会比外部类先加载，而我们只有使用了外部类内部类才会被加载。

public class LazyInnerClassSingleton {

    private LazyInnerClassSingleton (){};
    //此次相当于懒汉单例
    public static final LazyInnerClassSingleton getInstance(){
        return LazyHolder.LAZY;
    }
    //此次相当于饿汉式单例
    private static class  LazyHolder{
        private static final LazyInnerClassSingleton LAZY = new LazyInnerClassSingleton();
    }
}

此方法虽然性能最优，但是你会发现构造器只是被私有化了，并没有做任何处理。那么会存在什么问题呢？ 反射攻击

问题1.反射攻击

 public static void main(String[] args) {
 try {
            Class<?> cls = LazyInnerClassSingleton.class;
            Constructor constructor = cls.getDeclaredConstructor(null);
            constructor.setAccessible(true); //得到私有访问权限
            Object o1 = constructor.newInstance();
            Object o2 = LazyInnerClassSingleton.getInstance();
            System.out.println( o1 == o2); //o1 == o2 false
        } catch (Exception e) {
            e.printStackTrace();
        }
}

你会发现通过反射得到的对象与getInstance()方法返回的对象时不相等的。此处调用了两次构造方法，相当于new了两次。如何解决？在构造方法中添加判断?

解决1：反射攻击

修改内部类中的构造方法。

private LazyInnerClassSingleton (){
        //此处加个判断能放止反射攻击
        if(LazyHolder.LAZY != null){
            throw new RuntimeException("非法创建实例!");
        }
    };

我们来看看现在继续使用反射返回的结果---->
在这里插入图片描述
直接抛出了RuntimeException，这样就解决了反射带来的危害。
那么这样就一定是安全的吗？答案：当然不是

问题2：序列化攻击

结合问题一优化后的代码看以下案例
首先创建一个类实现Serializable

public class SeriableSingleton implements Serializable {
/**
     * 反序列化,
     * 将已经持久化的字节码内容,转换为IO流
     * 通过IO流的读取,进而将读取的内容转换为java对象
     */
    private final static  SeriableSingleton SINGLETON = new SeriableSingleton();
    private SeriableSingleton(){};
    public static SeriableSingleton getInstance(){
        return SINGLETON;
    }
}

使用反序列化攻击

public static void main(String[] args) {
SeriableSingleton s1 = null;
        SeriableSingleton s2 = SeriableSingleton.getInstance();

        FileOutputStream fos = null;
        try{
            fos = new FileOutputStream("SeriableSingleton.obj");
            ObjectOutputStream oos = new ObjectOutputStream(fos);
            oos.writeObject(s2);
            oos.flush();
            oos.close();

            FileInputStream fis = new FileInputStream("SeriableSingleton.obj");
            ObjectInputStream ois = new ObjectInputStream(fis);
            s1 = (SeriableSingleton) ois.readObject();
            System.out.println(s1);
            System.out.println(s2);
            System.out.println(s1==s2);
        }catch (Exception e){
            e.printStackTrace();
        }
}

结果:
不做演示了,说一下,结果是s1 和 s2 是两个对象 s1 == s2为false
原因：
序列化是将对象写入我们的磁盘中,反序列化的时候就会从我们的磁盘中进行读取,读取后转为内存对象。然后会重新分配内存，所以破坏了单例.
如何解决?

解决2：重新readResolve()方法

在我们刚刚创建的实例对象SeriableSingleton中添加 readResolve()返回一个对象

private Object readResolve(){
        return SINGLETON; //我们的实例名称
    }

结果：
同样用刚刚编写的测试进行测试，结果是s1 和 s2 是1个对象 s1 == s2为true,这样就符合了单例的原则。
readResolve()从何而来
在这我稍微解释一下，我会专门整理一遍来阐述。
readResolve()不是谁的方法,它的作用是如果我们的反序列对象中存在此方法的话，在反序列化读取readObject（）方法中会查找是否存在name为readResolve的方法。
readResolve()为什么能阻止重新创建对象
readObject()会在内部反射进行查找有没有name为readResolve的方法,如果有的话会返回方法return的对象覆盖之前反序列出来的对象,实际上还是触发了两次。之前反序列化出来的对象没有了引用,自然的等待GC的回收。

三、注册式单例(枚举，容器)

3.1 枚举式单例

枚举式单例的代码十分简单，并且能够很好解决安全问题。
《Effective Java》中也推荐我们使用枚举式单例

public enum EnumSingleton { 
	INSTANCE; 
	private Object data; 
	public Object getData() { return data; } 
	public void setData(Object data) { this.data = data; } 
	public static EnumSingleton getInstance(){
		return INSTANC
	}
}

测试代码1,和测试序列化代码方法一致。

public static void main(String[] args) {
		//测试枚举式单例
        EnumSingleton s1 = null;
        EnumSingleton s2 = EnumSingleton.getInstance();

        FileOutputStream fos = null;
        try{
            fos = new FileOutputStream("SeriableSingleton.obj");
            ObjectOutputStream oos = new ObjectOutputStream(fos);
            oos.writeObject(s2);
            oos.flush();
            oos.close();

            FileInputStream fis = new FileInputStream("SeriableSingleton.obj");
            ObjectInputStream ois = new ObjectInputStream(fis);
            s1 = (EnumSingleton) ois.readObject();

            System.out.println(s1);
            System.out.println(s2);
            System.out.println(s1==s2);
        }catch (Exception e){
            e.printStackTrace();
        }
}

测试1结果s1==s2。
测试2反射能否破坏枚举单例

public static void main(String[] args) {
	Class cls = EnumSingleton.class;
	Constructor constructor = cls.getDeclaredConstructor();
	constructor.newInstance();
}

结果:失败->抛出java.lang.NoSuchMethodException的异常.->没找到方法？我们查看Enum的源码

protected Enum(String name, int ordinal) {
        this.name = name;
        this.ordinal = ordinal;
    }

发现只有一个有参构造方法，好，那么我们在代码中加上参数,
修改一下

public static void main(String[] args) {
		Class cls = EnumSingleton.class;
        Constructor constructor = cls.getDeclaredConstructor(String.class,int.class);
        constructor.setAccessible(true);
        EnumSingleton enumSingleton = (EnumSingleton)constructor.newInstance("Ccc",18);
}

测试结果:失败->抛出java.lang.IllegalArgumentException: Cannot reflectively create enum objects.不能
用反射来创建枚举类型

为什么呢？
我们来查看一下newInstance()的源码
在这里插入图片描述
emmmmm,那么一脸懵逼 Modifier.ENUM是啥？？？？？
继续看

好像突然明白了。
newInstance()方法中做了强制性的判断，如果修饰符是Modifier.ENUM枚举类型,那么就会直接抛出异常。在JDK中已经对枚举式单例做个特别对待，所以在《Effective Java》中也推荐我们使用枚举式单例。
较为简单,

3.2 容器单例

容器式写法适用于创建实例非常多的情况，便于管理。但是，是非线程安全的。在spring框架中应用广泛。

public class ContainerSingleton {

    private ContainerSingleton(){};

    private static Map<String,Object> ioc = new ConcurrentHashMap<String,Object>();
    public static Object getBean(String className){
        synchronized (ioc){
            if(!ioc.containsKey(className)){
                Object obj = null;
                try{
                    obj = Class.forName(className).newInstance();
                    ioc.put(className,obj);
                }catch (Exception e){
                    e.printStackTrace();
                }
                return obj;
            }
            return ioc.get(className);
        }
    }
}

关于单例模式在这就介绍这么些了，如果发现有补充的地方，我会继续添加，同时希望各位看过的伙伴们如果发现了问题能够及时批评指正，在此感谢。

陈橙橙丶

关注

2
点赞
踩
6

收藏

觉得还不错? 一键收藏
打赏
1
评论
设计模式(二):深入剖析单例模式(懒汉,饿汉,枚举,容器)

单例模式(Singleton Pattern) 是指确保一个类在任何情况下都绝对只有一个实例,并提供一个全局的访问点。比方说，你只能有一个女朋友,你是new不出来的.前言写文章的目的主要是为了自己知识的巩固,当然也十分希望在此能够得到业界前辈们的指导。本文主要围绕:懒汉单例、饿汉单例、枚举单例、容器单例。以及会分析他们为什么会是线程安全和不安全。一、饿汉单例该单例模式咱们直接看代码,...
复制链接

扫一扫