java单例模式深度解析

应用场景

由于单例模式只生成一个实例, 减少了系统性能开销(如: 当一个对象的产生需要比较多的资源时, 如读取配置, 产生其他依赖对象, 则可以通过在应用启动时直接产生一个单例对象, 然后永久驻留内存的方式来解决)

  • Windows中的任务管理器;
  • 文件系统, 一个操作系统只能有一个文件系统;
  • 数据库连接池的设计与实现;
  • Spring中, 一个Component就只有一个实例Java-Web中, 一个Servlet类只有一个实例;

实现要点

  • 声明为private来隐藏构造器
  • private static Singleton实例
  • 声明为public来暴露实例获取方法

单例模式主要追求三个方面性能

  • 线程安全
  • 调用效率高
  • 延迟加载

实现方式

主要有五种实现方式，懒汉式（延迟加载，使用时初始化），饿汉式（声明时初始化），双重检查，静态内部类，枚举。

懒汉式，线程不安全的实现

由于没有同步，多个线程可能同时检测到实例没有初始化而分别初始化，从而破坏单例约束。

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

懒汉式，线程安全但效率低下的实现

由于对象只需要在初次初始化时需要同步，多数情况下不需要互斥的获得对象，加锁会造成巨大无意义的资源消耗

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

双重检查

这种方法对比于上面的方法确保了只有在初始化的时候需要同步，当初始化完成后，再次调用getInstance不会再进入synchronized块。

NOTE

内部检查是必要的

由于在同步块外的if语句中可能有多个线程同时检测到instance为null，同时想要获取锁，所以在进入同步块后还需要再判断是否为null，避免因为后续获得锁的线程再次对instance进行初始化

instance声明为volatile类型是必要的。

  • 指令重排

    由于初始化操作 instance=new Singleton()是非原子操作的，主要包含三个过程

    1. 给instance分配内存
    2. 调用构造函数初始化instance
    3. 将instance指向分配的空间（instance指向分配空间后，instance就不为空了）

      虽然synchronized块保证了只有一个线程进入同步块，但是在同步块内部JVM出于优化需要可能进行指令重排，例如（1->3->2），instance还没有初始化之前其他线程就会在外部检查到instance不为null，而返回还没有初始化的instance，从而造成逻辑错误。

      • volatile保证变量的可见性

        volatile类型变量可以保证写入对于读取的可见性，JVM不会将volatile变量上的操作与其他内存操作一起重新排序，volatile变量不会被缓存在寄存器，因此保证了检测instance状态时总是检测到instance的最新状态。

注意：volatile并不保证操作的原子性，例如即使count声明为volatile类型，count++操作被分解为读取->写入两个操作，虽然读取到的是count的最新值，但并不能保证读取与写入之间不会有其他线程再次写入，从而造成逻辑错误

public class Singleton {
    private static volatile Singleton instance;
    private Singleton() {
    };
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

饿汉式

这种方式基于单ClassLoder机制，instance在类加载时进行初始化，避免了同步问题。饿汉式的优势在于实现简单，劣势在于不是懒加载模式（lazy initialization）

  • 在需要实例之前就完成了初始化，在单例较多的情况下，会造成内存占用，加载速度慢问题
  • 由于在调用getInstance（）之前就完成了初始化，如果需要给getInstance（）函数传入参数，将会无法实现
public class Singleton {
    private static final Singleton instance = new Singleton();
    private Singleton() {
    };
    public static Singleton getInstance() {
        return instance;
    }
}

静态内部类

由于内部类不会在类的外部被使用，所以只有在调用getInstance()方法时才会被加载。同时依赖JVM的ClassLoader类加载机制保证了不会出现同步问题。

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

枚举方法

参见枚举类解析

- 线程安全

由于枚举类的会在编译期编译为继承自java.lang.Enum的类，其构造函数为私有，不能再创建枚举对象，枚举对象的声明和初始化都是在static块中，所以由JVM的ClassLoader机制保证了线程的安全性。但是不能实现延迟加载

- 序列化

由于枚举类型采用了特殊的序列化方法，从而保证了在一个JVM中只能有一个实例。

  • 枚举类的实例都是static的，且存在于一个数组中，可以用values()方法获取该数组
  • 在序列化时，只输出代表枚举类型的名字属性 name
  • 反序列化时，根据名字在静态的数组中查找对应的枚举对象，由于没有创建新的对象，因而保证了一个JVM中只有一个对象
public enum Singleton {
    INSTANCE;
    public String error(){
        return "error";
    }
}

单例模式的破坏与防御

反射

对于枚举类，该破解方法不适用。

import java.lang.reflect.Constructor;
public class TestCase {
    public void testBreak() throws Exception {
        Class<Singleton> clazz = (Class<Singleton>) Class.forName("Singleton");
        Constructor<Singleton> constructor = clazz.getDeclaredConstructor();
        constructor.setAccessible(true);
        Singleton instance1 = constructor.newInstance();
        Singleton instance2 = constructor.newInstance();
        System.out.println("singleton? " + (instance1 == instance2));
    }
    public static void main(String[] args) throws Exception{
        new TestCase().testBreak();
    }
}

序列化

对于枚举类，该破解方法不适用。

该测试首先需要声明Singleton为实现了可序列化接口public class Singleton implements Serializable

public class TestCase {
    private static final String SYSTEM_FILE = "save.txt";
    public void testBreak() throws Exception {
        Singleton instance1 = Singleton.getInstance();
        ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream(SYSTEM_FILE));
        oos.writeObject(instance1);
        ObjectInputStream ois = new ObjectInputStream(new FileInputStream(SYSTEM_FILE));
        Singleton instance2 = (Singleton) ois.readObject();
        System.out.println("singleton? " + (instance1 == instance2));
    }
    public static void main(String[] args) throws Exception{
        new TestCase().testBreak();
    }
}

ClassLoader

JVM中存在两种ClassLoader，启动内装载器(bootstrap)和用户自定义装载器(user-defined class loader)，在一个JVM中可能存在多个ClassLoader，每个ClassLoader拥有自己的NameSpace。一个ClassLoader只能拥有一个class对象类型的实例，但是不同的ClassLoader可能拥有相同的class对象实例，这时可能产生致命的问题。

防御

对于序列化与反序列化，我们需要添加一个自定义的反序列化方法，使其不再创建对象而是直接返回已有实例，就可以保证单例模式。

我们再次用下面的类进行测试，就发现结果为true。

public final class Singleton {
    private Singleton() {
    }
    private static final Singleton INSTANCE = new Singleton();
    public static Singleton getInstance() {
        return INSTANCE;
    }
    private Object readResolve() throws ObjectStreamException {
        // instead of the object we‘re on,
        // return the class variable INSTANCE
        return INSTANCE;
    }
public class TestCase {
    private static final String SYSTEM_FILE = "save.txt";
    public void testBreak() throws Exception {
        Singleton instance1 = Singleton.getInstance();
        ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream(SYSTEM_FILE));
        oos.writeObject(instance1);
        ObjectInputStream ois = new ObjectInputStream(new FileInputStream(SYSTEM_FILE));
        Singleton instance2 = (Singleton) ois.readObject();
        System.out.println("singleton? " + (instance1 == instance2));
    }
    public static void main(String[] args) throws Exception {
        new TestCase().testBreak();
    }
}
}

单例模式性能总结

方式 优点 缺点
饿汉式 线程安全, 调用效率高 不能延迟加载
懒汉式 线程安全, 可以延迟加载 调用效率不高
双重检测锁式 线程安全, 调用效率高, 可以延迟加载 -
静态内部类式 线程安全, 调用效率高, 可以延迟加载 -
枚举单例 线程安全, 调用效率高 不能延迟加载

单例性能测试

测试结果：

  1. HungerSingleton 共耗时: 30 毫秒
  2. LazySingleton 共耗时: 48 毫秒
  3. DoubleCheckSingleton 共耗时: 25 毫秒
  4. StaticInnerSingleton 共耗时: 16 毫秒
  5. EnumSingleton 共耗时: 6 毫秒

在不考虑延迟加载的情况下，枚举类型获得了最好的效率，懒汉模式由于每次方法都需要获取锁，所以效率最低，静态内部类与双重检查的效果类似。考虑到枚举可以轻松有效的避免序列化与反射，所以枚举是较好实现单例模式的方法。

public class TestCase {
    private static final String SYSTEM_FILE = "save.txt";
    private static final int THREAD_COUNT = 10;
    private static final int CIRCLE_COUNT = 100000;
    public void testSingletonPerformance() throws IOException, InterruptedException {
        final CountDownLatch latch = new CountDownLatch(THREAD_COUNT);
        FileWriter writer = new FileWriter(new File(SYSTEM_FILE), true);
        long start = System.currentTimeMillis();
        for (int i = 0; i < THREAD_COUNT; ++i) {
            new Thread(new Runnable() {
                @Override
                public void run() {
                    for (int i = 0; i < CIRCLE_COUNT; ++i) {
                        Object instance = Singleton.getInstance();
                    }
                    latch.countDown();
                }
            }).start();
        }
        latch.await();
        long end = System.currentTimeMillis();
        writer.append("Singleton 共耗时: " + (end - start) + " 毫秒\n");
        writer.close();
    }
    public static void main(String[] args) throws Exception{
        new TestCase().testSingletonPerformance();
    }
}

补充知识

类加载机制

static关键字的作用是把类的成员变成类相关,而不是实例相关，static块会在类首次被用到的时候进行加载，不是对象创建时，所以static块具有线程安全性

- 普通初始化块

当Java创建一个对象时, 系统先为对象的所有实例变量分配内存(前提是该类已经被加载过了), 然后开始对这些实例变量进行初始化, 顺序是: 先执行初始化块或声明实例变量时指定的初始值(这两处执行的顺序与他们在源代码中排列顺序相同), 再执行构造器里指定的初始值.

  • 静态初始化块

    又名类初始化块(普通初始化块负责对象初始化, 类初始化块负责对类进行初始化). 静态初始化块是类相关的, 系统将在类初始化阶段静态初始化, 而不是在创建对象时才执行. 因此静态初始化块总是先于普通初始化块执行.

  • 执行顺序

    系统在类初始化以及对象初始化时, 不仅会执行本类的初始化块[static/non-static], 而且还会一直上溯到java.lang.Object类, 先执行Object类中的初始化块[static/non-static], 然后执行其父类的, 最后是自己.

    顶层类(初始化块, 构造器) -> … -> 父类(初始化块, 构造器) -> 本类(初始化块, 构造器)

  • 小结

    static{} 静态初始化块会在类加载过程中执行;

    {} 则只是在对象初始化过程中执行, 但先于构造器;

内部类

  • 内部类访问权限

    1. Java 外部类只有两种访问权限:public/default, 而内部类则有四种访问权限:private/default/protected/public. 而且内部类还可以使用static修饰;内部类可以拥有private访问权限、protected访问权限、public访问权限及包访问权限。如果成员内部类Inner用private修饰，则只能在外部类的内部访问，如果用public修饰，则任何地方都能访问；如果用protected修饰，则只能在同一个包下或者继承外部类的情况下访问；如果是默认访问权限，则只能在同一个包下访问。这一点和外部类有一点不一样，外部类只能被public和包访问两种权限修饰。成员内部类可以看做是外部类的一个成员，所以可以像类的成员一样拥有多种权限修饰。
    2. 内部类分为成员内部类与局部内部类, 相对来说成员内部类用途更广泛, 局部内部类用的较少(匿名内部类除外), 成员内部类又分为静态(static)内部类与非静态内部类, 这两种成员内部类同样要遵守static与非static的约束(如static内部类不能访问外部类的非静态成员等)
  • 非静态内部类
    1. 非静态内部类在外部类内使用时, 与平时使用的普通类没有太大区别;
    2. Java不允许在非static内部类中定义static成员，除非是static final的常量类型
    3. 如果外部类成员变量, 内部类成员变量与内部类中的方法里面的局部变量有重名, 则可通过this, 外部类名.this加以区分.
    4. 非静态内部类的成员可以访问外部类的private成员, 但反之不成立, 内部类的成员不被外部类所感知. 如果外部类需要访问内部类中的private成员, 必须显示创建内部类实例, 而且内部类的private权限对外部类也是不起作用的:
  • 静态内部类
    1. 使用static修饰内部类, 则该内部类隶属于该外部类本身, 而不属于外部类的某个对象.
    2. 由于static的作用, 静态内部类不能访问外部类的实例成员, 而反之不然;
  • 匿名内部类

    如果(方法)局部变量需要被匿名内部类访问, 那么该局部变量需要使用final修饰.

枚举

  1. 枚举类继承了java.lang.Enum, 而不是Object, 因此枚举不能显示继承其他类; 其中Enum实现了Serializable和Comparable接口(implements Comparable, Serializable);
  2. 非抽象的枚举类默认使用final修饰,因此枚举类不能派生子类;
  3. 枚举类的所有实例必须在枚举类的第一行显示列出(枚举类不能通过new来创建对象); 并且这些实例默认/且只能是public static final的;
  4. 枚举类的构造器默认/且只能是private;
  5. 枚举类通常应该设计成不可变类, 因此建议成员变量都用private final修饰;
  6. 枚举类不能使用abstract关键字将枚举类声明成抽象类(因为枚举类不允许有子类), 但如果枚举类里面有抽象方法, 或者枚举类实现了某个接口, 则定义每个枚举值时必须为抽象方法提供实现,
时间： 2024-10-22 17:01:09

java单例模式深度解析的相关文章

单例模式深度解析

http://www.cnblogs.com/hxsyl/archive/2013/03/19/2969489.html http://devbean.blog.51cto.com/448512/203501/

java线程深度解析（三）——并发模型（Future）

 多核CPU充分利用CPU性能,就需要使用多线程并行挖掘CPU的潜力,并行程序设计对常用的多线程结构进行抽象,总结出几种典型多线程开发设计模式. 一.future 模式--精彩无需等待 当程序提交一个请求,服务器对这个请求的处理可能很慢,在传统串行程序中,函数调用时同步的,也就是说程序必须等着服务器返回结果才会进行下一步处理.而Future 模式采用异步调用,充分利用等待的时间段,执行其他业务逻辑处理,最后再执行返回较慢的Future 数据,从而提高系统的响应速度. 1.Future 的核心

java内存分配和String类型的深度解析（转）

一.引题 在java语言的所有数据类型中,String类型是比较特殊的一种类型,同时也是面试的时候经常被问到的一个知识点,本文结合java内存分配深度分析 关于String的许多令人迷惑的问题.下面是本文将要涉及到的一些问题,如果读者对这些问题都了如指掌,则可忽略此文. 1.java内存具体指哪块内存?这块内存区域为什么要进行划分?是如何划分的?划分之后每块区域的作用是什么?如何设置各个区域的大小? 2.String类型在执行连接操作时,效率为什么会比StringBuffer或者StringBu

【转】java内存分配和String类型的深度解析

一.引题 在java语言的所有数据类型中,String类型是比较特殊的一种类型,同时也是面试的时候经常被问到的一个知识点,本文结合java内存分配深度分析关于String的许多令人迷惑的问题.下面是本文将要涉及到的一些问题,如果读者对这些问题都了如指掌,则可忽略此文. 1.java内存具体指哪块内存?这块内存区域为什么要进行划分?是如何划分的?划分之后每块区域的作用是什么?如何设置各个区域的大小? 2.String类型在执行连接操作时,效率为什么会比StringBuffer或者StringBui

Java内存分配和String类型的深度解析

一.引题 在java语言的所有数据类型中,String类型是比较特殊的一种类型,同时也是面试的时候经常被问到的一个知识点,本文结合java内存分配深度分析关于String的许多令人迷惑的问题.下面是本文将要涉及到的一些问题,如果读者对这些问题都了如指掌,则可忽略此文. 1.java内存具体指哪块内存?这块内存区域为什么要进行划分?是如何划分的?划分之后每块区域的作用是什么?如何设置各个区域的大小? 2.String类型在执行连接操作时,效率为什么会比StringBuffer或者StringBui

深度解析Java 8：JDK1.8 AbstractQueuedSynchronizer的实现分析

深度解析Java 8:JDK1.8 AbstractQueuedSynchronizer的实现分析(上) 深度解析Java 8:AbstractQueuedSynchronizer的实现分析(下) AbstractQueuedSynchronizer的介绍和原理分析 原文地址:https://www.cnblogs.com/gotodsp/p/8830995.html

JAVA框架底层源码剖析系列Spring，Mybatis，Springboot，Netty源码深度解析

<Spring源码深度解析>从核心实现和企业应用两个方面,由浅入深.由易到难地对Spring源码展开了系统的讲解,包括Spring的设计理念和整体架构.容器的基本实现.默认标签的解析.自定义标签的解析.bean的加载.容器的功能扩展.AOP.数据库连接JDBC.整合MyBatis.事务.SpringMVC.远程服务.Spring消息服务等内容. <Spring源码深度解析>不仅介绍了使用Spring框架开发项目必须掌握的核心概念,还指导读者如何使用Spring框架编写企业级应用,并

Java并发之synchronized关键字深度解析（二）

前言 本文继续[Java并发之synchronized关键字深度解析(一)]一文而来,着重介绍synchronized几种锁的特性. 一.对象头结构及锁状态标识 synchronized关键字是如何实现的给对象加锁?首先我们要了解一下java中对象的组成.java中的对象由3部分组成,第一部分是对象头,第二部分是实例数据,第三部分是对齐填充. 对齐填充:jvm规定对象的起始内存地址必须是8字节的整数倍,如果不够的话就用占位符来填充,此部分占位符就是对齐填充: 实例数据:实例数据是对象存储的真正有

Java 面试知识点解析(二)——高并发编程篇

前言: 在遨游了一番 Java Web 的世界之后,发现了自己的一些缺失,所以就着一篇深度好文:知名互联网公司校招 Java 开发岗面试知识点解析 ,来好好的对 Java 知识点进行复习和学习一番,大部分内容参照自这一篇文章,有一些自己补充的,也算是重新学习一下 Java 吧. 前序文章链接: Java 面试知识点解析(一)--基础知识篇 (一)高并发编程基础知识 这里涉及到一些基础的概念,我重新捧起了一下<实战 Java 高并发程序设计>这一本书,感觉到心潮澎湃,这或许就是笔者叙述功底扎实的