单例模式完全剖析

概要
单例模式是最简单的设计模式之一，但是对于Java的开发者来说，它却有很多缺陷。在本月的专栏中，David Geary探讨了单例模式以及在面对多线程（multithreading)、类装载器（classloaders）和序列化(serialization)时如何处理这些缺陷。

单例模式适合于一个类只有一个实例的情况，比如窗口管理器，打印缓冲池和文件系统，它们都是原型的例子。典型的情况是，那些对象的类型被遍及一个软件系统的不同对象访问，因此需要一个全局的访问指针，这便是众所周知的单例模式的应用。当然这只有在你确信你不再需要任何多于一个的实例的情况下。
单例模式的用意在于前一段中所关心的。通过单例模式你可以：

在不影响单例类的客户端的情况下允许将来有多个实例

尽管单例设计模式如在下面的图中的所显示的一样是最简单的设计模式，但对于粗心的Java开发者来说却呈现出许多缺陷。这篇文章讨论了单例模式并揭示了那些缺陷。
注意：你可以从Resources下载这篇文章的源代码。

单例模式

在《设计模式》一书中，作者这样来叙述单例模式的：确保一个类只有一个实例并提供一个对它的全局访问指针。
下图说明了单例模式的类图。
（图1）

单例模式的类图

正如你在上图中所看到的，这不是单例模式的完整部分。此图中单例类保持了一个对唯一的单例实例的静态引用，并且会从静态getInstance()方法中返回对那个实例的引用。
例1显示了一个经典的单例模式的实现。
例1.经典的单例模式

1. public class ClassicSingleton {
2.    private static ClassicSingleton instance = null;
4.    protected ClassicSingleton() {
5.       // Exists only to defeat instantiation.
6.    }
7.    public static ClassicSingleton getInstance() {
8.       if(instance == null) {
9.          instance = new ClassicSingleton();
10.       }
11.       return instance;
12.    }
13. }

在例1中的单例模式的实现很容易理解。ClassicSingleton类保持了一个对单独的单例实例的静态引用，并且从静态方法getInstance()中返回那个引用。
关于ClassicSingleton类，有几个让我们感兴趣的地方。首先，ClassicSingleton使用了一个众所周知的懒汉式实例化去创建那个单例类的引用;结果，这个单例类的实例直到getInstance()方法被第一次调用时才被创建。这种技巧可以确保单例类的实例只有在需要时才被建立出来。其次，注意ClassicSingleton实现了一个protected的构造方法，这样客户端不能直接实例化一个ClassicSingleton类的实例。然而，你会惊奇的发现下面的代码完全合法：

1. public class SingletonInstantiator { 
2.   public SingletonInstantiator() { 
3.    ClassicSingleton instance = ClassicSingleton.getInstance();
4. ClassicSingleton anotherInstance =
5. new ClassicSingleton();
6.        ... 
7.   } 
8. }

前面这个代码片段为何能在没有继承ClassicSingleton并且ClassicSingleton类的构造方法是protected的情况下创建其实例？答案是protected的构造方法可以被其子类以及在同一个包中的其它类调用。因为ClassicSingleton和SingletonInstantiator位于相同的包（缺省的包），所以SingletonInstantiator方法能创建ClasicSingleton的实例。
这种情况下有两种解决方案：一是你可以使ClassicSingleton的构造方法变化私有的（private）这样只有ClassicSingleton的方法能调用它;然而这也意味着ClassicSingleton不能有子类。有时这是一种很合意的解决方法，如果确实如此，那声明你的单例类为final是一个好主意，这样意图明确，并且让编译器去使用一些性能优化选项。另一种解决方法是把你的单例类放到一个外在的包中，以便在其它包中的类（包括缺省的包）无法实例化一个单例类。
关于ClassicSingleton的第三点感兴趣的地方是，如果单例由不同的类装载器装入，那便有可能存在多个单例类的实例。假定不是远端存取，例如一些servlet容器对每个servlet使用完全不同的类装载器，这样的话如果有两个servlet访问一个单例类，它们就都会有各自的实例。
第四点，如果ClasicSingleton实现了java.io.Serializable接口，那么这个类的实例就可能被序列化和复原。不管怎样，如果你序列化一个单例类的对象，接下来复原多个那个对象，那你就会有多个单例类的实例。
最后也许是最重要的一点，就是例1中的ClassicSingleton类不是线程安全的。如果两个线程，我们称它们为线程1和线程2，在同一时间调用ClassicSingleton.getInstance()方法，如果线程1先进入if块，然后线程2进行控制，那么就会有ClassicSingleton的两个的实例被创建。

正如你从前面的讨论中所看到的，尽管单例模式是最简单的设计模式之一，在Java中实现它也是决非想象的那么简单。这篇文章接下来会揭示Java规范对单例模式进行的考虑，但是首先让我们近水楼台的看看你如何才能测试你的单例类。
 

测试单例模式

接下来，我使用与log4j相对应的JUnit来测试单例类，它会贯穿在这篇文章余下的部分。如果你对JUnit或log4j不很熟悉，请参考相关资源。

例2是一个用JUnit测试例1的单例模式的案例：
例2.一个单例模式的案例

1. import org.apache.log4j.Logger;
2. import junit.framework.Assert;
3. import junit.framework.TestCase;
5. public class SingletonTest extends TestCase {
6.    private ClassicSingleton sone = null, stwo = null;
7.    private static Logger logger = Logger.getRootLogger();
9.    public SingletonTest(String name) {
10.       super(name);
11.    }
12.    public void setUp() {
13.       logger.info("getting singleton...");
14.       sone = ClassicSingleton.getInstance();
15.       logger.info("...got singleton: " + sone);
17.       logger.info("getting singleton...");
18.       stwo = ClassicSingleton.getInstance();
19.       logger.info("...got singleton: " + stwo);
20.    }
21.    public void testUnique() {
22.       logger.info("checking singletons for equality");
23.       Assert.assertEquals(true, sone == stwo);
24.    }
25. }

例2两次调用ClassicSingleton.getInstance()，并且把返回的引用存储在成员变量中。方法testUnique()会检查这些引用看它们是否相同。例3是这个测试案例的输出：
例3.是这个测试案例的输出

1. Buildfile: build.xml
3. init:
4.      [echo] Build 20030414 (14-04-2003 03:08)
6. compile:
8. run-test-text:
9.      [java] .INFO main: [b]getting singleton...[/b]
10.      [java] INFO main: [b]created singleton:[/b] Singleton@e86f41
11.      [java] INFO main: ...got singleton: Singleton@e86f41
12.      [java] INFO main: [b]getting singleton...[/b]
13.      [java] INFO main: ...got singleton: Singleton@e86f41
14.      [java] INFO main: checking singletons for equality
16.      [java] Time: 0.032
18.      [java] OK (1 test)

正如前面的清单所示，例2的简单测试顺利通过----通过ClassicSingleton.getInstance()获得的两个单例类的引用确实相同;然而，你要知道这些引用是在单线程中得到的。下面的部分着重于用多线程测试单例类。

多线程因素的考虑

在例1中的ClassicSingleton.getInstance()方法由于下面的代码而不是线程安全的：

1. 1: if(instance == null) {
2. 2:    instance = new Singleton();
3. 3: }

如果一个线程在第二行的赋值语句发生之前切换，那么成员变量instance仍然是null，然后另一个线程可能接下来进入到if块中。在这种情况下，两个不同的单例类实例就被创建。不幸的是这种假定很少发生，这样这种假定也很难在测试期间出现（译注：在这可能是作者对很少出现这种情况而导致无法测试从而使人们放松警惕而感到叹惜）。为了演示这个线程轮换，我得重新实现例1中的那个类。例4就是修订后的单例类：
例4.人为安排的方式

1. import org.apache.log4j.Logger;
3. public class Singleton {
4.   private static Singleton singleton = null;
5.   private static Logger logger = Logger.getRootLogger();
6.   private static boolean firstThread = true;
8.   protected Singleton() {
9.     // Exists only to defeat instantiation.
10.   }
11.   public static Singleton getInstance() {
12.      if(singleton == null) {
13.         simulateRandomActivity();
14.         singleton = new Singleton();
15.      }
16.      logger.info("created singleton: " + singleton);
17.      return singleton;
18.   }
19.   private static void simulateRandomActivity() {
20.      try {
21.         if(firstThread) {
22.            firstThread = false;
23.            logger.info("sleeping...");
25.            // This nap should give the second thread enough time
26.            // to get by the first thread.
27.              Thread.currentThread().sleep(50);
28.        }
29.      }
30.      catch(InterruptedException ex) {
31.         logger.warn("Sleep interrupted");
32.      }
33.   }
34. }

除了在这个清单中的单例类强制使用了一个多线程错误处理，例4类似于例1中的单例类。在getInstance()方法第一次被调用时，调用这个方法的线程会休眠50毫秒以便另外的线程也有时间调用getInstance()并创建一个新的单例类实例。当休眠的线程觉醒时，它也会创建一个新的单例类实例，这样我们就有两个单例类实例。尽管例4是人为如此的，但它却模拟了第一个线程调用了getInstance()并在没有完成时被切换的真实情形。
例5测试了例4的单例类：
例5.失败的测试

1. import org.apache.log4j.Logger;
2. import junit.framework.Assert;
3. import junit.framework.TestCase;
5. public class SingletonTest extends TestCase {
6.    private static Logger logger = Logger.getRootLogger();
7.    private static Singleton singleton = null;
9.    public SingletonTest(String name) {
10.       super(name);
11.    }
12.    public void setUp() {
13.       singleton = null;
14.    }
15.    public void testUnique() throws InterruptedException {
16.       // Both threads call Singleton.getInstance().
17.       Thread threadOne = new Thread(new SingletonTestRunnable()),
18.              threadTwo = new Thread(new SingletonTestRunnable());
20.       threadOne.start();
21.       threadTwo.start();
23.       threadOne.join();
24.       threadTwo.join();
25.    }
26.    private static class SingletonTestRunnable implements Runnable {
27.       public void run() {
28.          // Get a reference to the singleton.
29.          Singleton s = Singleton.getInstance();
31.          // Protect singleton member variable from
32.          // multithreaded access.
33.          synchronized(SingletonTest.class) {
34.             if(singleton == null) // If local reference is null...
35.                singleton = s;     // ...set it to the singleton
36.          }
37.          // Local reference must be equal to the one and
38.          // only instance of Singleton; otherwise, we have two
39.                   // Singleton instances.
40.          Assert.assertEquals(true, s == singleton);
41.       }
42.    }
43. }

例5的测试案例创建两个线程，然后各自启动，等待完成。这个案例保持了一个对单例类的静态引用，每个线程都会调用Singleton.getInstance()。如果这个静态成员变量没有被设置，那么第一个线程就会将它设为通过调用getInstance()而得到的引用，然后这个静态变量会与一个局部变量比较是否相等。
在这个测试案例运行时会发生一系列的事情：第一个线程调用getInstance()，进入if块，然后休眠;接着，第二个线程也调用getInstance()并且创建了一个单例类的实例。第二个线程会设置这个静态成员变量为它所创建的引用。第二个线程检查这个静态成员变量与一个局部备份的相等性。然后测试通过。当第一个线程觉醒时，它也会创建一个单例类的实例，并且它不会设置那个静态成员变量（因为第二个线程已经设置过了），所以那个静态变量与那个局部变量脱离同步，相等性测试即告失败。例6列出了例5的输出：
例6.例5的输出

1. Buildfile: build.xml
2. init:
3.      [echo] Build 20030414 (14-04-2003 03:06)
4. compile:
5. run-test-text:
6. INFO Thread-1: sleeping...
7. INFO Thread-2: created singleton: Singleton@7e5cbd
8. INFO Thread-1: created singleton: Singleton@704ebb
9. junit.framework.AssertionFailedError: expected: but was:
10.    at junit.framework.Assert.fail(Assert.java:47)
11.    at junit.framework.Assert.failNotEquals(Assert.java:282)
12.    at junit.framework.Assert.assertEquals(Assert.java:64)
13.    at junit.framework.Assert.assertEquals(Assert.java:149)
14.    at junit.framework.Assert.assertEquals(Assert.java:155)
15.    at SingletonTest$SingletonTestRunnable.run(Unknown Source)
16.    at java.lang.Thread.run(Thread.java:554)
17.      [java] .
18.      [java] Time: 0.577
20.      [java] OK (1 test)

到现在为止我们已经知道例4不是线程安全的，那就让我们看看如何修正它。

同步

要使例4的单例类为线程安全的很容易----只要像下面一个同步化getInstance()方法：

1. public synchronized static Singleton getInstance() {
2.    if(singleton == null) {
3.       simulateRandomActivity();
4.       singleton = new Singleton();
5.    }
6.    logger.info("created singleton: " + singleton);
7.    return singleton;
8. }

在同步化getInstance()方法后，我们就可以得到例5的测试案例返回的下面的结果：

2. Buildfile: build.xml
4. init:
5.      [echo] Build 20030414 (14-04-2003 03:15)
7. compile:
8.     [javac] Compiling 2 source files
10. run-test-text:
11. INFO Thread-1: sleeping...
12. INFO Thread-1: created singleton: Singleton@ef577d
13. INFO Thread-2: created singleton: Singleton@ef577d
14.      [java] .
15.      [java] Time: 0.513
17.      [java] OK (1 test)

这此，这个测试案例工作正常，并且多线程的烦恼也被解决;然而，机敏的读者可能会认识到getInstance()方法只需要在第一次被调用时同步。因为同步的性能开销很昂贵（同步方法比非同步方法能降低到100次左右），或许我们可以引入一种性能改进方法，它只同步单例类的getInstance()方法中的赋值语句。

一种性能改进的方法

寻找一种性能改进方法时，你可能会选择像下面这样重写getInstance()方法：

2. public static Singleton getInstance() {
3.    if(singleton == null) {
4.       synchronized(Singleton.class) { 
5.          singleton = new Singleton();
6.       }
7.    }
8.    return singleton;
9. }

这个代码片段只同步了关键的代码，而不是同步整个方法。然而这段代码却不是线程安全的。考虑一下下面的假定：线程1进入同步块，并且在它给singleton成员变量赋值之前线程1被切换。接着另一个线程进入if块。第二个线程将等待直到第一个线程完成，并且仍然会得到两个不同的单例类实例。有修复这个问题的方法吗？请读下去。

双重加锁检查

初看上去，双重加锁检查似乎是一种使懒汉式实例化为线程安全的技术。下面的代码片段展示了这种技术：

1. public static Singleton getInstance() {
2.   if(singleton == null) {
3.      synchronized(Singleton.class) {
4.        if(singleton == null) {
5.          singleton = new Singleton();
6.        }
7.     }
8.   }
9.   return singleton;
10. }

如果两个线程同时访问getInstance()方法会发生什么？想像一下线程1进行同步块马上又被切换。接着，第二个线程进入if 块。当线程1退出同步块时，线程2会重新检查看是否singleton实例仍然为null。因为线程1设置了singleton成员变量，所以线程2的第二次检查会失败，第二个单例类实例也就不会被创建。似乎就是如此。
不幸的是，双重加锁检查不会保证正常工作，因为编译器会在Singleton的构造方法被调用之前随意给singleton赋一个值。如果在singleton引用被赋值之后而被初始化之前线程1被切换，线程2就会被返回一个对未初始化的单例类实例的引用。

一个改进的线程安全的单例模式实现

例7列出了一个简单、快速而又是线程安全的单例模式实现：
例7.一个简单的单例类

1. public class Singleton {
2.    public final static Singleton INSTANCE = new Singleton();
3.    private Singleton() {
4.          // Exists only to defeat instantiation.
5.       }
6. }

这段代码是线程安全的是因为静态成员变量一定会在类被第一次访问时被创建。你得到了一个自动使用了懒汉式实例化的线程安全的实现;你应该这样使用它：

1.       Singleton singleton = Singleton.INSTANCE;
2.       singleton.dothis();
3.       singleton.dothat();
4.       ...

当然万事并不完美，前面的Singleton只是一个折衷的方案;如果你使用那个实现，你就无法改变它以便后来你可能想要允许多个单例类的实例。用一种更折哀的单例模式实现(通过一个getInstance()方法获得实例)你可以改变这个方法以便返回一个唯一的实例或者是数百个实例中的一个．你不能用一个公开且是静态的（public static)成员变量这样做．

你可以安全的使用例７的单例模式实现或者是例１的带一个同步的getInstance()方法的实现．然而，我们必须要研究另一个问题：你必须在编译期指定这个单例类，这样就不是很灵活．一个单例类的注册表会让我们在运行期指定一个单例类．
 

使用注册表

使用一个单例类注册表可以：

posted on 2006-11-27 14:05 零一的伟大 阅读(88) 评论(0)  编辑  收藏