细说单例设计模式

zoneless

已于 2023-11-02 16:24:54 修改

阅读量354

点赞数 1

分类专栏：设计模式文章标签：单例模式 java 开发语言

于 2022-07-21 13:49:14 首次发布

本文链接：https://blog.csdn.net/weixin_41927555/article/details/125908374

版权

设计模式专栏收录该内容

2 篇文章 0 订阅

订阅专栏

细说单例设计模式

单例模式：一个类有且仅有一个实例，并提供一个访问它的全局访问点。
单例模式又分为饿汉式、懒汉式。它们的区别仅在于初始化单例类的时机。
饿汉式
顾名思义就是在加载单例类的时候就开始初始化，并提供一个外界访问的入口。

public class HungryMode {
    private HungryMode(){}
    private static HungryMode hungryMode = new HungryMode();

    public static HungryMode getInstance(){
        return hungryMode;
    }
}

以上就是一个饿汉式单例模式，饿汉式单例模式是线程安全的，因为他是由类加载机制来保证的，有兴趣的可以做多线程测试，我这里不做测试。
那么，它一定是安全的吗？
答案是不安全，我们可以通过反射给 hungryMode 字段重新设置值。
代码如下：

public static void main(String[] args) {
    HungryMode hungryMode = HungryMode.getInstance();
    System.out.println("单例对象"+hungryMode);
    try {
        Constructor<HungryMode> declaredConstructor = 
	 	HungryMode.class.getDeclaredConstructor();
        declaredConstructor.setAccessible(true);
        HungryMode hungryMode1 = declaredConstructor.newInstance();

        Field field = HungryMode.class.getDeclaredField("hungryMode");
        field.setAccessible(true);
        field.set(hungryMode ,hungryMode1);

        HungryMode instance = HungryMode.getInstance();
        System.out.println("反射得到的单例对象："+instance);
    } catch (Exception e) {
        e.printStackTrace();
    }
}

怎么避免被被反射破坏呢？
其实也很简单，只要在单例类中的字段 hungryMode 前加一个关键字 final，如下：
添加final关键字

当加上final关键字后，当想再次想取篡改单例对象值时会抛出这个异常，中断程序，因为final修饰的字段只会在初始化字段时允许设置值，之后禁止修改值。所以字段加final是在反射机制上保证当前单例对象不会被篡改。

看起来我们的饿汉单例模式已经很安全了吧？
线程安全！反射也无法破坏了！那么就真的安全了码？
不一定，之所以不一定是因为单例对象类实现了序列化接口，那么破坏者就有可能通过序列化与反序列化来篡改单例对象。
如下：

public static void main(String[] args) {
    HungryMode hungryMode = HungryMode.getInstance();
    System.out.println("单例对象" + hungryMode);
    try {
        ObjectOutputStream objectOutputStream = new ObjectOutputStream(new FileOutputStream("hungry.txt"));
        objectOutputStream.writeObject(hungryMode);
        objectOutputStream.close();

        ObjectInputStream objectInputStream = new ObjectInputStream(new FileInputStream("hungry.txt"));
        HungryMode hungryMode1 =(HungryMode)objectInputStream.readObject();
        objectInputStream .close();
        System.out.println("反射得到的单例对象" + hungryMode1);
    } catch (Exception e) {
        e.printStackTrace();
    }
}

在这里插入图片描述

很明显反序列化后的单例对象和我们通过getInstance()获取的单例对象不是同一个对象。
怎么解决这个问题呢？
有两种方式：
1.不要让单例对象类实现序列化接口；
2. 如果必须要实现序列化接口那么就需要在单例类中加一个方法readResolve()方法，返回类型为Object,返回值为当前单例类中的单例对象字段。
在这里插入图片描述

现在可以说单例模式–饿汉式是真正安全了吗？是的，我们发现问题，解决问题，一步一步优化，现在可以保证线程安全、避免反射破坏、避免了序列化破坏。
那么，这种单例模式又这么多优点，为什么用它的反而很少呢？
答案恰好是它的初始化时机，饿汉式模式随着类的加载而开始初始化，换句话说，即使在整个JVM启动到关闭这个期间内我们不使用这个单例对象也会被初始化出来，这就会浪费很多内存空间，甚至于霸占珍贵的IO资源。至此，懒汉式单例模式应运而生。

懒汉式
在第一次使用该单例类的时候就开始初始化。

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

如上，为懒加载单例模式。存在一个问题，可能有小伙伴已经看出来了，对，lazyMode 这个对象没有加final关键字，这是可以通过反射重新篡改单例对象的值的（反序列化破坏这个和饿汉式一样的，不再赘述）。
在这里插入图片描述

这里是不能加final关键字的，这个有解决方案吗？
想下，反射获取新的实力对象的本质是什么，就是通过类class文件去获取当前类的构造器，并初始化构造器创建一个类实例出来，也就是它最终是通过new 一个构造器来构建实例对象的。那么我们是不是可以在构造器中做点文章呢？
在这里插入图片描述

我们在构造器中加了这么一段代码，当有不法者想通过反射篡改单例对象时会抛出非法状态异常，会中断流程，防止被反射破坏。

现在懒汉式我们也通过一步步优化做到了线程安全、避免反射破坏，而且还节约了资源，做到有需要才会将单例对象加载到内存中，饿汉式单例有的，懒汉式单例也有，饿汉式单例没有的，懒汉式也有，JVM内存宠儿，这就是懒汉式。。。

但，就跟我们平时写bug一样，当我们解决了我们写的一个BUG后随之而来又是一个BUG，有诗曰：
BUG复BUG,
BUG何其多，
线上全BUG,
四阿哥背锅。

收！
因为饿汉式的线程安全是通过类加载机制实现的，但是懒汉式不能这么做，必须得通过锁来保证线程安全（如上代码）。这个锁的作用只是用于当前单例对象第一次加载的时候来保证实例对象只会初始化一份在JVM中，当这个对象初始化完成后这个锁其实就没用了，反而会影响性能，但是这个锁又不能去掉。
鱼与熊掌不可得兼，二者只取一者也，怎么选？还能怎么选，我全都要！

解决办法很简单，双重判断锁，加锁前先判断一次，然后再加锁。
在这里插入图片描述

不够优雅？
开发就是苦啊，有需求就必须得解决，求必应，应必达！

public class StaticInnerClassMode {
    private StaticInnerClassMode() {
    }
    private static class StaticInnerClassModeHolder {
        final static StaticInnerClassMode INSTANCE = new 
				StaticInnerClassMode();
    }

    public static StaticInnerClassMode getInstance() {
        return StaticInnerClassModeHolder.INSTANCE;
    }
}

注：final这个关键字还是要加上的，不然还是可以通过反射进行破坏的。

静态内部类算是懒加载模式的一种，也是延迟加载，它的延迟加载是基于类加载机制的。当加载外部类时不会去加载内部的静态类，静态内部类也不会自动初始化，只有调用静态内部类的方法或者静态域或者其他的一些静态资源才会去加载静态内部类，而且线程安全也是由加载机制来保证的。

那么静态内部类单例模式和枚举单例模式就真的很完美吗？它们就没有缺点吗？还是有的。严重的可能会出现内存泄漏问题。取决于JVM厂商对垃圾回收算法的实现，一般来说有两种，引用计数算法和可达性分析算法。现在绝大部分都是实现的可达性分析垃圾回收算法，这种算法下会导致静态资源在不使用时无法被回收，如果较多的话就会出现内存泄漏问题。

孟子诚不欺我，鱼与熊掌果然不可得兼！

众人寻他千百度，慕然回首！枚举却在灯火阑珊处
枚举单例是什么？啥？都2202年了还不知道枚举单例。等着！