Java设计模式之单例模式

最新推荐文章于 2024-05-14 06:46:22 发布

.main.

最新推荐文章于 2024-05-14 06:46:22 发布

阅读量1.8k

点赞数 1

文章标签：单例模式 java 设计模式

本文链接：https://blog.csdn.net/qq_45743985/article/details/129797255

版权

定义与类型

定义：保证一个类仅有一个实例，并提供一个全局访问点

类型：创建型

单例模式使用场景

想确保任何情况下都绝对只有一个实例

例如：线程池，数据库连接池一般都为单例模式

单例模式优点

在内存中只有一个实例，减少内存开销
可以避免对资源的多重占用
设置全局访问点，严格控制访问

缺点

没有接口，扩展困难

单例模式-重点

私有构造器
线程安全（重点）
延迟加载（重点）
序列化和反序列化安全（序列化和反序列化会破坏单例模式）
反射（防止反射攻击）

实现单例模式-懒汉式

/**
 * 懒汉式
 */
public class LazySingleton {
    private static LazySingleton lazySingleton = null;
    private LazySingleton(){

    }
    public static LazySingleton getInstance(){
        if (lazySingleton == null){
            lazySingleton = new LazySingleton();
        }
        return lazySingleton;
    }
}

将构造器私有化，提供一个静态类来获取对象实例

但是该方法是线程不安全的，如果在LazySingleton未实例化前，多个线程同时调用，例如线程1判断lazySingleton为null，进入下一步并没有创建对象时，另一个对象也判断lazySingleton为空这时就会出现创造出多个实例的错误。

使用多线程debug方式显示问题

在idea中想要使用多线程debug方式需要按如图所示修改，将断点改为Thread级别

在Test的main方法中开辟两个线程

public class Test {
    public static void main(String[] args) {
//        LazySingleton instance = LazySingleton.getInstance();
        Thread t1 = new Thread(new T());
        Thread t2 = new Thread(new T());
        t1.start();
        t2.start();
        System.out.println("main end");
    }
}

T为Runnable的实现类

/**
 * 设置线程,开启其他线程获取LazySingleton实例
 */
public class T implements Runnable{
    @Override
    public void run() {
        LazySingleton instance = LazySingleton.getInstance();
        System.out.println(Thread.currentThread().getName()+"  "+instance);
    }
}

使用debug方式启动Test的main方法，此时在Frames中就可以看到除main线程外，还有两个运行中的Thread

切换到Thread-0线程，走到if判断后，且未创建LazySingleton实例时刻

切换到Thread-1线程，使Thread-1线程继续运行直到Thread-1线程结束

然后切回Thread-0线程，使Thread-0线程继续运行直到Thread-0线程结束

观看控制台即可发现在堆中创建了两个 LazySingleton实例

解决方式

1、在获取LazySingleton实例方法上加上synchronized关键字由于getInstance是静态方法，所有给该方法上加入synchronized关键字等同于给整个LazySingleton类加锁，虽然能解决并发情况下创建多个实例的问题，但是会影响性能。

DoubleCheck双重检查

通过双重检查既能解决并发情况下创建多个实例的问题，也可以很好的提升性能

双重检查代码实现

第一版双重检查代码实现

在第一次判断后加上synchronized关键字再判断一次，这样既可以解决并发情况下创建多个实例的问题，对性能的影响也非常有限

但是这种做法也会产生问题因为创建对象的过程并不是原子操作，在jvm内部可能会使创建过程发生指令重排序

一般创建过程

分配内存给这个对象
初始化对象
设置lazyDoubleCheckSingleton 指向分配的内存地址

jvm会在什么情况下发生指令重排序呢？

jvm允许在单线程中不影响最终结果的情况下发生指令重排序

在该实例中第二步和第三步发生重排序，即先指向内存地址在初始化对象并不会改变单线程中的最终结果，所有jvm会允许这两步发生重排序

发生指令重拍寻后的创建过程

分配内存给这个对象
设置lazyDoubleCheckSingleton 指向分配的内存地址
初始化对象

但在并发的情况下就有可能出现线程1发生指令重排刚指向完内存地址时，

线程2进入第一层判断发现lazyDoubleCheckSingleton并不为空，然后直接返回

这时就有可能出现别的线程返回的是没有初始化完成的对象从而发生一些意想不到的错误

解决指令重排序

1.禁用指令重排序

想要禁用指令重排序非常简单只需将私有的成员变量 lazyDoubleCheckSingleton 增加 volatile关键字即可

2.线程1的指令重排对线程2是不可见的

想要线程1 的指令重排对线程2 不可见需要应用静态内部类

/**
 *  想要线程1 的指令重排对线程2 不可见 需要应用静态内部类
 */
public class StaticInnerClassSingleton {
    private StaticInnerClassSingleton(){

    }

    private static class Inner{
        private static StaticInnerClassSingleton staticInnerClassSingleton = new StaticInnerClassSingleton();
    }

    public static StaticInnerClassSingleton getInstance(){
        return Inner.staticInnerClassSingleton;
    }
}

原理

在介绍原理前首先介绍下静态内部类的加载时机

外部类初次加载，会初始化静态变量、静态代码块、静态方法，但不会加载内部类和静态内部类。
实例化外部类，调用外部类的静态方法、静态变量，则外部类必须先进行加载，但只加载一次。
直接调用静态内部类时，外部类不会加载。

即静态内部类不会自动初始化，只有调用静态内部类的方法，静态域，或者构造方法的时候才会加载静态内部类。

在了解静态内部类的加载时机后，再来解释利用静态内部类是如何实现隔离线程间的指令重排的

jvm在类初始化阶段会给class对象加锁，在多个线程同时初始化该类时会使多个线程初始化处于同步阶段，所以在静态内部类初始化阶段可以做到对其他线程的隔离。

基于该特性可以设计出一个通过静态内部类的基于类初始化的延迟加载（懒加载）解决方案

实现单例模式-饿汉式

饿汉式是在类加载阶段就进行实例化，饿汉式创造简单，也能解决并发情况下创建多实例的问题

/**
 * 饿汉式
 */
public class HungrySingleton {
    private static HungrySingleton hungrySingleton;
    
    private HungrySingleton(){
        
    }
    
    static {
        // 基于静态代码块的饿汉式单例模式
        hungrySingleton = new HungrySingleton();
    }
    
    public HungrySingleton getInstance(){
        return hungrySingleton;
    }
    
}

饿汉式虽然简单易用但是由于在类加载阶段就会创建实例，如果大量使用这种方式会导致内存占用过大问题

单例模式-序列化和反序列化安全

以饿汉式为例，将实例对象输出到磁盘

代码示例

public class Test {
    public static void main(String[] args) throws IOException, ClassNotFoundException {

        HungrySingleton instance = HungrySingleton.getInstance();
        ObjectOutputStream outputStream = new ObjectOutputStream(new FileOutputStream("singleton_file"));
        outputStream.writeObject(instance);

        ObjectInputStream inputStream = new ObjectInputStream(new FileInputStream("singleton_file"));
        HungrySingleton object = (HungrySingleton)inputStream.readObject();


        System.out.println("instance: "+instance);
        System.out.println("object: "+object);

    }
}

要想将实例对象输出到磁盘上需要让实例类实现 Serializable接口使其可序列化

题外话 serialVersionUID版本号的作用

当对同一个实体序列化反序列化时，需要serialVersionUID值一致才能成功。如果我们不显示指定serialVersionUID，在序列化时会自动生成一个serialVersionUID。当实体类改动了，反序列化时，会生成一个新serialVersionUID。这两个serialVersionUID的值肯定不一致，从而反序列化会失败。但是如果显示指定，就不会生成新serialVersionUID值了。反序列化的serialVersionUID就是原序列化的serialVersionUID。

运行Test的main方法，查看打印结果

可以看到在经过序列化后获取的对象实例并不是同一个对象了，这就破坏了单例模式。

如何解决？

先说结论，在单例类上加上readResolve方法就可以实现序列化后的对象也是同一个对象


    private Object readResolve(){
        return hungrySingleton;
    }

加上该方法后重新执行main方法，查看打印结果

发现确实已经是同一个对象了

为什么需要加一个readResolve方法呢？

让我们来看下ObjectInputStream的源码

首先ObjectInputStream的readObject方法调用了readObject0

进入readObject0方法，发现内部有一个switch case判断，我们是序列化的对象实例，所有直接看case TC_OBJECT 这一部分

发现他的checkResolve方法调用的readOrdinaryObject方法，继续进入该方法

    /**
     * Reads and returns "ordinary" (i.e., not a String, Class,
     * ObjectStreamClass, array, or enum constant) object, or null if object's
     * class is unresolvable (in which case a ClassNotFoundException will be
     * associated with object's handle).  Sets passHandle to object's assigned
     * handle.
     */
    private Object readOrdinaryObject(boolean unshared)
        throws IOException
    {
        if (bin.readByte() != TC_OBJECT) {
            throw new InternalError();
        }

        ObjectStreamClass desc = readClassDesc(false);
        desc.checkDeserialize();

        Class<?> cl = desc.forClass();
        if (cl == String.class || cl == Class.class
                || cl == ObjectStreamClass.class) {
            throw new InvalidClassException("invalid class descriptor");
        }

        Object obj;
        try {
            obj = desc.isInstantiable() ? desc.newInstance() : null;
        } catch (Exception ex) {
            throw (IOException) new InvalidClassException(
                desc.forClass().getName(),
                "unable to create instance").initCause(ex);
        }

        passHandle = handles.assign(unshared ? unsharedMarker : obj);
        ClassNotFoundException resolveEx = desc.getResolveException();
        if (resolveEx != null) {
            handles.markException(passHandle, resolveEx);
        }

        if (desc.isExternalizable()) {
            readExternalData((Externalizable) obj, desc);
        } else {
            readSerialData(obj, desc);
        }

        handles.finish(passHandle);

        if (obj != null &&
            handles.lookupException(passHandle) == null &&
            desc.hasReadResolveMethod())
        {
            Object rep = desc.invokeReadResolve(obj);
            if (unshared && rep.getClass().isArray()) {
                rep = cloneArray(rep);
            }
            if (rep != obj) {
                // Filter the replacement object
                if (rep != null) {
                    if (rep.getClass().isArray()) {
                        filterCheck(rep.getClass(), Array.getLength(rep));
                    } else {
                        filterCheck(rep.getClass(), -1);
                    }
                }
                handles.setObject(passHandle, obj = rep);
            }
        }

        return obj;
    }

原来readOrdinaryObject首先会通过一个三目运算来创建序列化的对象。如果这个对象能实例化就创建一个新的对象。

obj = desc.isInstantiable() ? desc.newInstance() : null;

那为什么在单例类中加入一个readResolve方法就能改变这种情况呢？

继续往下看，在第2076行有个判断，从名字上就能看得出是用来判断是否能获取到readResolve方法的

进入readResolve方法查看

在这里可以看到如果没有readResolveMethod不为空那么就会返回true。

走到在就终于明白原因了，太不容易了

原来是readOrdinaryObject会查看实例类内部是否有readResolve方法，如果存在readResolve方法

那么就会通过反射的方式获取readResolve中的返回值，将obj的引用改为readResolve方法的返回，

从而最终改变了反序列化的引用地址，使其的引用变为单例的创建的实例。

总结，反序列化时会创建了一个新的实例对象，如果在单例对象代码中添加public Object readResolve()方法，会在最后改变了这个实例对象的引用为单例对象readResolve()方法的返回结果。

通过枚举类实现单例模式

Google 首席 Java 架构师、《Effective Java》一书作者、Java集合框架的开创者Joshua Bloch在Effective Java一书中提到：

单元素的枚举类型已经成为实现Singleton的最佳方法。【大佬真是这么说的】

那么枚举类型有什么神奇之处呢？

特点

枚举类型可以解决序列化问题
枚举类型可以解决反射功能的问题

创建一个枚举类型

public enum EnumInstance {
    INSTANCE;
    private Object data;
    private String name;

    public Object getData() {
        return data;
    }

    public void setData(Object data) {
        this.data = data;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public static EnumInstance getInstance(){
        return INSTANCE;
    }
}

序列化枚举类实例

查看打印结果

发现枚举类的序列化结果是一致的

同样的来看一下readEnum方法的具体逻辑

核心逻辑是通过cl(类型)，和name获取枚举常量，由于枚举name是唯一的并且对应一个枚举常量，所有最终拿到的是同一个枚举常量，没有重新创建对象。因此序列化对单例模式的破坏对于枚举类型是不起作用的。

枚举是如何实现单例模式的呢？

通过jad 反编译工具来看下答案

jad的官网为

JAD Java Decompiler Download Mirrorhttps://varaneckas.com/jad/下载jad，并解压

配置环境变量在系统变量中创建JAD_HOME变量，将jad目录配置进去

然后配置系统变量里的path变量

这样就配置成功了。

找到EnumInstance的class文件执行jad EnumInstance.class命令

可以看到生成了一个EnumInstance.jad文件，这样就使用jad生成了 EnumInstance.class的反编译文件，看一下反编译后的文件

首先可以发现枚举类居然是被final修饰的

public final class EnumInstance extends Enum

再往下看发现虽然没有写构造方法，但是内部却已经被创建出来一个私有的构造器

 private EnumInstance(String s, int i)
    {
        super(s, i);
    }

再然后就是定义的getInstance方法和一个被final修饰的静态成员变量INSTANCE；

    public static EnumInstance getInstance()
    {
        return INSTANCE;
    }
    public static final EnumInstance INSTANCE;

最后可以看到一个静态代码块用来对成员变量INSTANCE初始化

    static 
    {
        INSTANCE = new EnumInstance("INSTANCE", 0);
        $VALUES = (new EnumInstance[] {
            INSTANCE
        });
    }

从枚举类的反编译文件可以看出，枚举类是一个饿汉式的单例模式，在类被加载时初始化，没有延迟加载。

单例模式之线程单例

变量值的共享可以使用public static的形式，所有线程都使用同一个变量，如果想实现每一个线程都有自己的共享变量该如何实现呢？JDK中的ThreadLocal类正是为了解决这样的问题。

ThreadLocal类并不是用来解决多线程环境下的共享变量问题，而是用来提供线程内部的共享变量，在多线程环境下，可以保证各个线程之间的变量互相隔离、相互独立。在线程中，可以通过get()/set()方法来访问变量。

ThreadLocal实例通常来说都是private static类型的，它们希望将状态与线程进行关联。这种变量在线程的生命周期内起作用，可以减少同一个线程内多个函数或者组件之间一些公共变量的传递的复杂度。

ThreadLocal主要api介绍

get()方法：获取与当前线程关联的ThreadLocal值。

set(T value)方法：设置与当前线程关联的ThreadLocal值。

initialValue()方法：设置与当前线程关联的ThreadLocal初始值。

remove()方法：将与当前线程关联的ThreadLocal值删除。

当调用get()方法的时候，若是与当前线程关联的ThreadLocal值已经被设置过，则不会调用initialValue()方法；否则，会调用initialValue()方法来进行初始值的设置。

通常initialValue()方法只会被调用一次，除非调用了remove()方法之后又调用get()方法，此时，与当前线程关联的ThreadLocal值处于没有设置过的状态（其状态体现在源码中，就是线程的ThreadLocalMap对象是否为null），initialValue()方法仍会被调用。

initialValue()方法是protected类型的，很显然是建议在子类重写该函数的，所以通常该方法都会以匿名内部类的形式被重写，以指定初始值，例如：

创建一个ThreadLocalInstance

/**
 * ThreadLocal类可以实现线程之间的单例
 */
public class ThreadLocalInstance {
    private static ThreadLocal<ThreadLocalInstance>
            threadLocalInstanceThreadLocal = new ThreadLocal<ThreadLocalInstance>(){
        // 匿名内部类重写 initialValue方法
        @Override
        protected ThreadLocalInstance initialValue() {
//            return super.initialValue();
            return new ThreadLocalInstance();
        }
    };

    // 私有化构造器
    private ThreadLocalInstance(){

    }

    public static ThreadLocalInstance getInstance(){
        return threadLocalInstanceThreadLocal.get();
    }
    
}

main线程中多次调用getInstance，在开辟新线程调用

        ThreadLocalInstance instance1 = ThreadLocalInstance.getInstance();
        ThreadLocalInstance instance2 = ThreadLocalInstance.getInstance();
        ThreadLocalInstance instance3 = ThreadLocalInstance.getInstance();
        ThreadLocalInstance instance4 = ThreadLocalInstance.getInstance();
        System.out.println(instance1);
        System.out.println(instance2);
        System.out.println(instance3);
        System.out.println(instance4);
        Thread t1 = new Thread(new T());
        Thread t2 = new Thread(new T());
        t1.start();
        t2.start();
        System.out.println("main end");

查看打印结果

可以发现ThreadLocalInstance会在每一个线程都创建一个实例，同一线程多次调用都是调用的该实例，这样就实现了线程的单例

spring中的bean单例模式

Spring单例Bean与单例模式的区别在于他们关联的环境不一样，单例模式是指在一个jvm进程中仅有一个实例，而Spring单例是指一个Spring Bean容器(ApplicationContext)中仅有一个实例。

单例设计模式，在一个JVM进程中(理论上，一个运行的Java程序，就必定有自己独立的JVM)仅有一个实例，于是无论在程序的何处获取实例，始终都返回同一个对象，以Java内置的Runtime为例（现在枚举是单例模式的最佳实践），无论何时获取，下面的判断始终为真：

//  基于懒汉模式实现
//  在一个JVM实例中始终只有一个实例
Runtime.getRuntime() == Runtime.getRuntime()

与此相比，Spring的单例Bean是与其容器（ApplicationContext）密切相关的，所以在一个JVM进程中，如果有多个Spring容器，即使是单例bean，也一定会创建多个实例，代码示例如下：

@SpringBootApplication
public class DemoApplication {
    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class,args);

        // 第一个spring bean容器
        AnnotationConfigApplicationContext context1 = new AnnotationConfigApplicationContext(Contextbean.class);
        User user1 = context1.getBean("user1", User.class);
        // 第二个spring bean容器
        AnnotationConfigApplicationContext context2 = new AnnotationConfigApplicationContext(Contextbean.class);
        User user2 = context2.getBean("user1", User.class);
        System.out.println("==========");
        // 这里绝对不会相等，因为创建了多个实例
        System.out.println(user1==user2);

    }

打印结果和预想的一样果然不是同一个对象实例

附：配置类和实体类

Spring的配置类

@Configuration
public class Contextbean {

    @Bean("user1")
    public User getUser(){
        return new User("zhangsan","18");
    }

}

User实体类

public class User {
    private String name;
    private String age;

    public User(String name, String age) {
        this.name = name;
        this.age = age;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getAge() {
        return age;
    }

    public void setAge(String age) {
        this.age = age;
    }
}