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

àì夳堔傛蜴生んèń 2023-07-17 02:43 1阅读 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

此处就出现了线程安全问题,线程本身就是存在概率的你可以多测几次。  
那么会什么会出现这个问题呢？  
 我 们 来 进 行 断 点 测 试 ( 使 用 线 程 d e b u g ) \\color\{\#FF0000\}\{我们来进行断点测试(使用线程debug)\} 我们来进行断点测试(使用线程debug)  
在以下两处打个断点,右键断点选择Thread可以选择线程模式。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNDA5MjYw_size_16_color_FFFFFF_t_70]  
![在这里插入图片描述][20200319093526512.jpg]  
当第一个线程进入到if方法中的时候切换线程(从Thrad0切换到Thrad1,目的为了让两个线程同时处在if方法中) 注 意 T h r a d 0 还 没 有 赋 值 \\color\{\#FF0000\}\{注意Thrad0还没有赋值\} 注意Thrad0还没有赋值  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNDA5MjYw_size_16_color_FFFFFF_t_70 1]  
当Thread1进入到if方法中的时候可以先让Thread1执行完，在切换Thread0执行完毕！  
我们来看下结果.  
![在这里插入图片描述][20200319094858729.jpg]  
![在这里插入图片描述][20200319094913565.jpg]  
你就会发现此处就出现了两个实例了.破坏了单例的原则。因为线程本来就是抢时间执行的，当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()方法。  
这里就不给大家演示了。  
 注 意 s y n c h r o n i z e d \\color\{\#FF0000\}\{注意synchronized\} 注意synchronized使用此方法能够解决线程安全问题，虽然JDK1.6之后就对synchronized性能做了优化，但是还是会不可避免的造成一些新的问题。  
例如：当线程数较多的情况下使用 s y n c h r o n i z e d \\color\{\#FF0000\}\{synchronized\} 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()方法内部阻塞。在逻辑不是很复杂的条件下对于调用者是不会察觉到的。  
但是使用 s y n c h r o n i z e d \\color\{\#FF0000\}\{synchronized\} 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("非法创建实例!");
            }
        };

我们来看看现在继续使用反射返回的结果---->  
![在这里插入图片描述][20200319103528500.png]  
直接抛出了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()的源码  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNDA5MjYw_size_16_color_FFFFFF_t_70 2]  
emmmmm,那么一脸懵逼 Modifier.ENUM是啥？？？？？  
继续看  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNDA5MjYw_size_16_color_FFFFFF_t_70 3]  
好像突然明白了。  
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);
            }
        }
    }

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

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNDA5MjYw_size_16_color_FFFFFF_t_70]: /images/20230528/1e978a034ec94e01845d48b8f23f1f6d.png
[20200319093526512.jpg]: /images/20230528/8054860d2e4a4c779a1d489b88b5342c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNDA5MjYw_size_16_color_FFFFFF_t_70 1]: /images/20230528/18673eb93f8b46358a0caa8a6b933639.png
[20200319094858729.jpg]: /images/20230528/c76c3cabe2c845f69f18a572321f128f.png
[20200319094913565.jpg]: /images/20230528/31c2a07c3117427e83f60a3c1a62aed1.png
[20200319103528500.png]: /images/20230528/ee94e635e08b4882aede8726beb09c1e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNDA5MjYw_size_16_color_FFFFFF_t_70 2]: /images/20230528/055a4367465741bebe79d652b523a63b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNDA5MjYw_size_16_color_FFFFFF_t_70 3]: /images/20230528/81322a6518ca4b76a4c2bd5ae58a898a.png