设计模式-单例模式

最新推荐文章于 2024-09-09 22:12:12 发布

「已注销」

最新推荐文章于 2024-09-09 22:12:12 发布

阅读量405

点赞数

分类专栏：设计模式笔记文章标签：设计模式

本文链接：https://blog.csdn.net/BlogRecord/article/details/47193055

版权

设计模式笔记专栏收录该内容

6 篇文章 0 订阅

订阅专栏

概述：

保证一个类仅有一个实例，并提供一个访问它的全局访问点。

特点：

单例类确保自己只有一个实例。
单例类必须自己创建自己的实例。
单例类必须为其他对象提供唯一的实例。

实现方式：

分两种形式：懒汉单例类和饿汉单例类

懒汉式单例类：它在需要对象的时候，才判断是否已有对象，如果没有就立即创建一个对象，然后返回，如果已有对象就不再创建，立即返回

饿汉单例类：它在类加载的时候就立即创建对象

// 懒汉式
public class Singleton {

    private Singleton(){};
    private static Singleton instance = null;

    // 在需要的时候才判断对象是否为null
    public static synchronized Singleton getInstance() {
        if (instance == null)
            instance = new Singleton();
        return instance;
    }
}

// 饿汉式
public class Singleton {

    private Singleton() {};
    private static Singleton instance = new Singleton();

    // 在类加载的时候就创建了对象
    public static Singleton getInstance() {
        return instance;
    }
}

调用： Singleton.getInstance();

懒汉模式和饿汉模式的优缺点：

懒汉模式：它的特点是运行时获得对象的速度比较慢，但加载类的时候比较快。它在整个应用的生命周期只有一部分时间在占用资源。

饿汉模式：它的特点是加载类的时候比较慢，但运行时获得对象的速度比较快。它从加载到应用结束会一直占用资源。

比较：这两种模式对于初始化较快，占用资源少的轻量级对象来说，没有多大的性能差异，选择懒汉式还是饿汉式都没有问题。但是对于初始化慢，占用资源多的重量级对象来说，就会有比较明显的差别了。所以，对重量级对象应用饿汉模式，类加载时速度慢，但运行时速度快；懒汉模式则与之相反，类加载时速度快，但运行时第一次获得对象的速度慢。

从用户体验的角度来说，我们应该首选饿汉模式。我们愿意等待某个程序花较长的时间初始化，却不喜欢在程序运行时等待太久，给人一种反应迟钝的感觉，所以对于有重量级对象参与的单例模式，我们推荐使用饿汉模式。

而对于初始化较快的轻量级对象来说，选用哪种方法都可以。如果一个应用中使用了大量单例模式，我们就应该权衡两种方法了。轻量级对象的单例采用懒汉模式，减轻加载时的负担，缩短加载时间，提高加载效率；同时由于是轻量级对象，把这些对象的创建放在使用时进行，实际就是把创建单例对象所消耗的时间分摊到整个应用中去了，对于整个应用的运行效率没有太大影响。

模式总结：

优点
- 在内存中只有一个对象，节省内存空间。
- 避免频繁的创建销毁对象，可以提高性能。
- 避免对共享资源的多重占用。
- 可以全局访问。
注意事项
- 只能使用单例类提供的方法得到单例对象，不要使用反射，否则将会实例化一个新对象。
- 不要做断开单例类对象与类中静态引用的危险操作。
- 多线程使用单例使用共享资源时，注意线程安全问题。
适用场景
- 需要频繁实例化然后销毁的对象。
- 创建对象时耗时过多或者耗资源过多，但又经常用到的对象。
- 有状态的工具类对象。
- 频繁访问数据库或文件的对象。
- 以及其他我没用过的所有要求只有一个对象的场景。

单例模式争议

单例模式的对象长时间不用会被jvm垃圾收集器收集吗？

不少资料中说：如果一个单例对象在内存中长久不用，会被jvm认为是一个垃圾，在执行垃圾收集的时候会被清理掉。对此这个说法，观点是：在hotspot虚拟机1.6版本中，除非人为地断开单例中静态引用到单例对象的联接，否则jvm垃圾收集器是不会回收单例对象的。
单例模式讨论篇：单例模式与垃圾收集
在一个jvm中会出现多个单例吗?

在分布式系统、多个类加载器、以及序列化的的情况下，会产生多个单例，这一点是无庸置疑的。那么在同一个jvm中，会不会产生单例呢？使用单例提供的getInstance()方法只能得到同一个单例，除非是使用反射方式，将会得到新的单例。

Class c = Class.forName(Singleton.class.getName());
Constructor ct = c.getDeclaredConstructor();
ct.setAccessible(true);

这样，每次运行都会产生新的单例对象。所以运用单例模式时，一定注意不要使用反射产生新的单例对象。
懒汉式单例线程安全吗

主要是网上的一些说法，懒汉式的单例模式是线程不安全的，即使是在实例化对象的方法上加synchronized关键字，也依然是危险的，但是经过编码测试，发现加synchronized关键字修饰后，虽然对性能有部分影响，但是却是线程安全的，并不会产生实例化多个对象的情况。
单例模式只有饿汉式和懒汉式两种吗?

饿汉式单例和懒汉式单例只是两种比较主流和常用的单例模式方法，从理论上讲，任何可以实现一个类只有一个实例的设计模式，都可以称为单例模式。
单例类可以被继承吗?

饿汉式单例和懒汉式单例由于构造方法是private的，所以他们都是不可继承的，但是其他很多单例模式是可以继承的，例如登记式单例。
饿汉式单例好还是懒汉式单例好?

在java中，饿汉式单例要优于懒汉式单例。C++中则一般使用懒汉式单例。
如果单例由不同的类装载器装入，那便有可能存在多个单例类的实例。假定不是远端存取，例如一些servlet容器对每个servlet使用完全不同的类装载器，这样的话如果有两个servlet访问一个单例类，它们就都会有各自的实例。

public class Singleton{

    private static Class getClass(String classname) throws ClassNotFoundException {
        ClassLoader classLoader = Thread.currentThread().getContextClassLoader();

        if (classLoader == null)
            classLoader = Singleton.class.getClassLoader();

        return (classLoader.loadClass(classname));
    }
}

8.如果Singleton实现了java.io.Serializable接口，那么这个类的实例就可能被序列化和复原。不管怎样，如果你序列化一个单例类的对象，接下来复原多个那个对象，那你就会有多个单例类的实例。

public class Singleton implements java.io.Serializable {

    protected Singleton() {}
    public static Singleton INSTANCE = new Singleton();

    private Object readResolve() {
        return INSTANCE;
    }
}

什么是线程安全：

线程安全就是说多线程访问同一代码，不会产生不确定的结果。编写线程安全的代码是低依靠线程同步。

线程安全一般都涉及到synchronized 就是一段代码同时只能有一个线程来操作不然中间过程可能会产生不可预制的结果

优化(线程安全)与其他方式：

/**
 * 第一种（懒汉，线程不安全）：
 */
public class SingletonA {

    private SingletonA() {};
    private static SingletonA instance = null;

    public static SingletonA getInstance() {
        if (instance == null)
            instance = new SingletonA();
        return instance;
    }
}

Feature（特征）：延时加载、线程不安全、多线程下不能正常工作，需要额外的工作(Serializable、transient、readResolve())来实现序列化。

/**
 * 第二种（懒汉，线程安全）
 */
public class SingletonB {

    private SingletonB() {}
    private static SingletonB instance;

    public static synchronized SingletonB getInstance() {
        if (instance == null) {
            instance = new SingletonB();
        }
        return instance;
    }
}

这种写法能够在多线程中很好的工作，而且看起来它也具备很好的lazy loading，但是，遗憾的是，效率很低，99%情况下不需要同步。
Feature（特征）：线程安全、效率比较低，因为需要线程同步的时候比较少。

/**
 * 第三种（饿汉）(推荐)
 */
public class SingletonC {

    private SingletonC() {}
    private static SingletonC instance = new SingletonC();

    public static SingletonC getInstance() {
        return instance;
    }
}

这种方式基于classloder机制避免了多线程的同步问题，不过，instance在类装载时就实例化，虽然导致类装载的原因有很多种，在单例模式中大多数都是调用getInstance方法，但是也不能确定有其他的方式（或者其他的静态方法）导致类装载，这时候初始化instance显然没有达到lazy loading的效果。
Feature（特征）：可以通过反射机制攻击，线程安全[多个类加载器除外]。

/**
 * 第四种（饿汉，变种）
 */
public class SingletonD {

    private SingletonD() {}
    private static SingletonD instance = null;
    static {
        instance = new SingletonD();
    }

    public static SingletonD getInstance() {
        return instance;
    }
}

表面上看起来差别挺大，其实跟第三种方式差不多，都是在类初始化即实例化instance。

/**
 * 第五种（静态内部类）(推荐)
 */
public class SingletonE {

    private SingletonE() {}

    private static class SingletonHolder {
        private static final SingletonE INSTANCE = new SingletonE();
    }

    public static final SingletonE getInstance() {
        return SingletonHolder.INSTANCE;
    }
}

这种方式同样利用了classloder的机制来保证初始化instance时只有一个线程，它跟第三种和第四种方式不同的是（很细微的差别）：第三种和第四种方式是只要Singleton类被装载了，那么instance就会被实例化（没有达到lazy loading效果），而这种方式是Singleton类被装载了，instance不一定被初始化。因为SingletonHolder类没有被主动使用，只有显示通过调用getInstance方法时，才会显示装载SingletonHolder类，从而实例化instance。想象一下，如果实例化instance很消耗资源，我想让他延迟加载，另外一方面，我不希望在Singleton类加载时就实例化，因为我不能确保Singleton类还可能在其他的地方被主动使用从而被加载，那么这个时候实例化instance显然是不合适的。这个时候，这种方式相比第三和第四种方式就显得很合理。
Feature（特征）：线程安全、延迟加载。

/**
 * 第六种（枚举）(极推荐)
 */
public enum SingletonF {
    INSTANCE;

    // 需要调用的方法
    public void invokingMethod() {
    }

    // 调用:SingletonF.INSTANCE.invokingMethod();
}

这种方式是Effective Java作者Josh Bloch 提倡的方式，它不仅能避免多线程同步问题，而且还能防止反序列化重新创建新的对象，可谓是很坚强的壁垒啊，不过，个人认为由于1.5中才加入enum特性，用这种方式写不免让人感觉生疏，在实际工作中，我也很少看见有人这么写过。

Feature（特征）：写法简单，从Java1.5开始支持，无偿提供序列化机制，绝对防止多次实例化，即使在面对复杂的序列化或者反射攻击的时候。

/**
 * 第七种（双重校验锁）(不推荐)
 */
public class SingletonG {

    private SingletonG() {}
    private volatile static SingletonG instance;

    public static SingletonG getSingleton() {
        if (instance == null) {
            synchronized (SingletonG.class) {
                if (instance == null) {
                    instance = new SingletonG();
                }
            }
        }
        return instance;
    }
}

这个是第二种方式的升级版，俗称双重检查锁定
第二种方存在的问题：只有第一次执行此方法时，才真正需要同步。换句话说，一旦设置好instance 变量，就不再需要同步这个方法了。之后每次调用这个方法，同步都是一种浪费。

用“双重检查加锁”，在getSingleton()中减少使用同步
首先检查实例是否已经创建，如果尚未创建，才进行同步。这样一来，只有第一次会同步，这正是我们想要的。

volatile关键字确保：当instance 变量被初始化成Singleton实例时，多个线程正确地instance 变量。如果性能是你关心的重点，那么这个做法可以帮你大大地减少getSingleton()的时间耗费。

总结，五类：恶汉、懒汉、双重校验锁、静态内部类、枚举。

恶汉：因为加载类的时候就创建实例，所以线程安全(多个ClassLoader存在时例外)。缺点是不能延时加载。

懒汉：需要加锁才能实现多线程同步，但是效率会降低。优点是延时加载。

双重校验锁：麻烦，在当前Java内存模型中不一定都管用，某些平台和编译器甚至是错误的，因为instance = new MaYun()这种代码在不同编译器上的行为和实现方式不可预知。

静态内部类：延迟加载，减少内存开销。因为用到的时候才加载，避免了静态field在单例类加载时即进入到堆内存的permanent代而永远得不到回收的缺点(大多数垃圾回收算法是这样)。

枚举：很好，不仅能避免多线程同步问题，而且还能防止反序列化重新创建新的对象。但是失去了类的一些特性，没有延迟加载，用的人也太少了。

以后多推广推广单元素枚举这种更好的单例实现方式。在项目中的代码开始修改实施

选择：

第一种和第二种方式一般不用。
第三种和第五种方式，简单易懂，而且在JVM层实现了线程安全（如果不是多个类加载器环境），一般的情况下，会使用第三种方式，只有在要明确实现lazy loading效果时才会使用第五种方式。
另外，如果涉及到反序列化创建对象时，试着使用枚举的方式来实现单例。
如有其他特殊的需求，可能会使用第七种方式，毕竟，JDK1.5已经没有双重检查锁定的问题了。

	特征词	JDK版本要求	是否Lazy Initialization	是否多线程安全	实现难度	说明
第一种	classic(懒汉如上第一种)	无	是	否	易	不要求线程安全
第二种	use “synchronize”(懒汉+同步如上第二种) keyword	无	是	是	易	getInstance()的性能对应用程序不是很关键(比如该方法使用不太频繁)
第三种	eagerly create（恶汉）	无	否	是	易	创建该实例负担不太繁重；该实例被用到的可能性较大
第四种	双检锁 (double-checked locking)	1.5	是	是	较复杂	getInstance()的性能对应用程序很关键。
第五种	Class holder lazy initialization（静态内部类）	无	是	是	一般
第六种	Enum singleton（枚举）	1.5	否	是	易	自动支持序列化；不能通过reflection attack来调用私有构造方法