java中的单例模式-白红宇

java中的单例模式

阅读量：4052 次

发布时间：2019-05-25

本文共 6385 字，大约阅读时间需要 21 分钟。

一、定义

单例模式（Singleton pattern）:确保一个类只有一个实例，并提供一个全局的访问点。

这个定义包含两层意思：

第一：我们把某个类设计成自己管理的一个单独实例，同时也要避免其他类再自行产生实例。要想取得单个实例，通过单例类是唯一的途径。

第二：我们必需提供对这个实例的全局访问点：当你需要实例时，向类查询，它会给你返回单个实例。

注意：单例模式确保一个类只有一个实例，是指在特定系统范围内只能有一个实例。有时在某些情况下，使用Singleton并不能达到Singleton的目的，如有多个Singleton对象同时被不同的类装入器装载；在EJB这样的分布式系统中使用也要注意这种情况，因为EJB是跨服务器，跨JVM的。

1。某个框架容器内：如Spring IOC容器，可以通过配置保证实例在容器内的唯一性。

2。再如单一JVM中、单一类加载器加载类的情况可以保证实例的唯一性。

如果在两个类加载器或JVM中，可能他们有机会各自创建自己的单个实例，因为每个类加载器都定义了一个命名空间，如果有两个以上的类加载器，不同的类加载器可能会加载同一个类，从整个程序来看，同一个类会被加载多次。如果这样的事情发生在单例上，就会产后多个Singleton并存的怪异现象。所以如果你的程序有多个类加载,同时你又使用了单例模式，请一定要小心。有一个解决办法是，自行给单例类指定类加载器（指定同一个类加载器）。

二、用处

有一些对象其实我们完全只需要一个即可，如：线程池（threadpool）、缓存（cache）、注册表（registry)的对象、设备的驱动程序的对象等等。事实上，这些类的对象只能有一个实例，如果制造出多个实例，就会导致许多问题的产生，例如：程序的行为异常、资源的过量使用、产生不一致的结果等等。Java Singleton模式就为我们提供了这样实现的可能。使用Singleton的好处还在于可以节省内存，因为它限制了实例的个数，有利于Java垃圾回收（garbage collection）。我们常常看到工厂模式中类装入器(class loader)中也用Singleton模式实现的,因为被装入的类实际也属于资源。

三、Java Singleton模式常见的几种形式

一）。使用立即创建实例，而不用延迟实例化的做法

1。使用全局变量

Java代码

//Singleton with final field

public class Singleton {

public static final Singleton uniqueInstance = new Singleton();

private Singleton(){

}

//...Remainder omitted

}

在这种方法中，公有静态成员是一个final域（保证了总是包含相同的对象引用）。私有构造函数仅被调用一次，用来实例化公有的静态final域 Singleton.uniqueInstace。由于缺少公有的或者受保护的构造函数，所有保证了Singleton的全局唯一性：一旦 Singleton类被实例化之后，只有一个Singleton实例存在——不多也不少。使用此Singleton类的程序员的任何行为都不能改变这一点。

2。使用公有的静态工厂方法

Java代码

[code="java]

//Singleton with static factory

public class Singleton {

private static Singleton uniqueInstance = new Singleton();

private Singleton(){

}

public static Singleton getInSingleton(){

return uniqueInstance;

}

//...Remainder omitted

}

第二种方法提供了一个公有的静态工厂方法，而不是公有的静态final域。利用这个做法，我们依赖JVM在加载这个类时马上创建此类唯一的一个实例。JVM保证任何线程访问uniqueInstance静态变量之前，一定先创建此实例。

二）。使用延迟实例化的做法（使用公有的静态工厂方法）

1。非线程安全的

Java代码

public class Singleton {

private static Singleton uniqueInstance ;

private Singleton(){

}

public static Singleton getInSingleton(){

if(uniqueInstance == null){

uniqueInstance = new Singleton();

}

return uniqueInstance;

}

//...Remainder omitted

}

先利用一个静态变量uniqueInstance来记录Singleton类的唯一实例，当我们要使用它的实例时，如果它不存在，就利用私有的构造器产生一个Singleton类的实例并把它赋值到uniqueInstance静态变量中。而如果我们不需要使用这个实例，它就永远不会产生。这就是"延迟实例化(lazy instantiaze)"。但上面这段程序在多线程环境中是不能保证单个实例的。分析如下：

Java代码

时间点线程1 线程2 uniqueInstance的值

1 线程1,2同时访问Singleton.getInstance()方法

2 进入Singleton.getInstance()方法 null

3 进入Singleton.getInstance()方法 null

4 执行if(uniqueInstance == null)判断 null

5 执行if(uniqueInstance == null)判断 null

6 执行uniqueInstance = new Singleton() Singleton1

7 执行uniqueInstance = new Singleton() Singleton2

8 执行return uniqueInstance; Singleton1

9 执行return uniqueInstance; Singleton2

如上分析所示，它已产生了两个Singleton实例。

如上分析所示，它已产生了两个Singleton实例。

2。多线程安全的

Java代码

Java代码

public class Singleton {

private static Singleton uniqueInstance ;

private Singleton(){

}

public synchronized static Singleton getInSingleton(){

if(uniqueInstance == null){

uniqueInstance = new Singleton();

}

return uniqueInstance;

}

//...Remainder omitted

}

通过给getInstance()方法增加synchronized关键字，也就是给getInstance()方法线程加锁，迫使每次只能有一个线程在进入这个方法，这样就可以解决上面多线程产生的灾难了。但加锁的同步方法可能造成程序执行效率大幅度下降，如果你的程序对性能的要求很高，同时你的getInstance（）方法调用的很频繁，这时可能这种设计也不符合程序要求了。其实这种加锁同步的方法用在这确实有一定的问题存在，因为对 Singleton类来说，只有在第一次执行getInstance（）方法时，才真正的需要对方法进行加锁同步，因为一旦第一次设置好 uniqueInstance变量后，就不再需要同步这个方法了。之后每次调用这个方法，同步反而成了一种累赘。

3。用"双重检查加锁",在getInstance()方法中减少使用同步:

Java代码

public class Singleton

{

// volatile关键字确保当uniqueInstance变量被初始化成Singleton实例时,多个线程正确地处理uniqueInstance变量

private volatile static Singleton uniqueInstance;

private Singleton()

{

}

public static Singleton getInSingleton() {

if (uniqueInstance == null) {// 检查实例,如是不存在就进行同步代码区

synchronized (Singleton.class) {// 对其进行锁,防止两个线程同时进入同步代码区

if (uniqueInstance == null) {// 双重检查,非常重要,如果两个同时访问的线程,当第一线程访问完同步代码区后,生成一个实例;当第二个已进入getInstance方法等待的线程进入同步代码区时,也会产生一个新的实例

uniqueInstance = new Singleton();

}

}

}

return uniqueInstance;

}

// ...Remainder omitted

}

对于双重检查加锁（Double-Checked Locking）

有一篇文章解释的很深入：http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

Java 语言中的 volatile 变量可以被看作是一种 “程度较轻的 synchronized”；与 synchronized 块相比，volatile 变量所需的编码较少，并且运行时开销也较少，但是它所能实现的功能也仅是 synchronized 的一部分。

我们知道，在Java中设置变量值的操作，除了long和double类型的变量外都是原子操作，也就是说，对于变量值的简单读写操作没有必要进行同步。

这在JVM 1.2之前，Java的内存模型实现总是从主存读取变量，是不需要进行特别的注意的。而随着JVM的成熟和优化，现在在多线程环境下volatile关键字的使用变得非常重要。

在当前的Java内存模型下，线程可以把变量保存在本地内存（比如机器的寄存器）中，而不是直接在主存中进行读写。这就可能造成一个线程在主存中修改了一个变量的值，而另外一个线程还继续使用它在寄存器中的变量值的拷贝，造成数据的不一致。

要解决这个问题，只需要像在本程序中的这样，把该变量声明为volatile（不稳定的）即可，这就指示JVM，这个变量是不稳定的，每次使用它都到主存中进行读取。一般说来，多任务环境下各任务间共享的标志都应该加volatile修饰。

Volatile修饰的成员变量在每次被线程访问时，都强迫从共享内存中重读该成员变量的值。而且，当成员变量发生变化时，强迫线程将变化值回写到共享内存。这样在任何时刻，两个不同的线程总是看到某个成员变量的同一个值。

Java语言规范中指出：为了获得最佳速度，允许线程保存共享成员变量的私有拷贝，而且只当线程进入或者离开同步代码块时才与共享成员变量的原始值对比。

这样当多个线程同时与某个对象交互时，就必须要注意到要让线程及时的得到共享成员变量的变化。

而volatile关键字就是提示VM：对于这个成员变量不能保存它的私有拷贝，而应直接与共享成员变量交互。

使用建议：在两个或者更多的线程访问的成员变量上使用volatile。当要访问的变量已在synchronized代码块中，或者为常量时，不必使用。

由于使用屏蔽掉了VM中必要的代码优化，所以在效率上比较低，因此一定在必要时才使用此关键字。

三。Sington类的序列化

为了使Singleton类变成可序列化的(serializable)，仅仅实现Serializable接口是不够的。为了维护 Singleton的单例性，你必须给Singleton类提供一个readResolve方法，否则的话，一个序列化的实例，每次反序列化的时候都会产生一个新的实例。Singleton 也不会例外。

如下所示：

Java代码