设计模式-java实现.zip

单例模式分类 ------------- * 懒汉式单例 * 饿汉式单例 * 登记式单例 单例模式特点 --------- * 单例类只能有一个实例 * 单例类必须自己创建自己的唯一实例 >如果别人创建的话，可以多次创建 * 单例类必须给所有其他对象提供这一实例 单例模式错误 --------- ### 无锁 class Singleton { private static Singleton instance; private Singleton() { } public static Singleton getInstance() { if (instance == null) //1 instance = new Singleton(); //2 return instance; //3 } } > 此类的设计确保只创建一个 Singleton 对象。构造函数被声明为 private ，getInstance() 方法只创建一个对象。这个实现适合于单线程程序。然而，当引入多线程时，就必须通过同步来保护 getInstance() 方法。如果不保护 getInstance() 方法，则可能返回 Singleton 对象的两个不同的实例。 假设两个线程并发调用getInstance() 方法并且按以下顺序执行调用： 1. 线程 1 调用 getInstance() 方法并判断 instance 在 //1 处为 null 。 2. 线程 1 进入 if 代码块，但在执行 //2 处的代码行时被线程 2 预占。 3. 线程 2 调用 getInstance() 方法并在 //1 处判断 instance 为 null 。 4. 线程 2 进入 if 代码块并创建一个新的 Singleton 对象并在 //2 处将变量 instance 分配给这个新对象。 5. 线程 2 在 //3 处返回 Singleton 对象引用。 6. 线程 2 被线程 1 预占。 7. 线程 1 在它停止的地方启动，并执行 //2 代码行，这导致创建另一个 Singleton 对象。 8. 线程 1 在 //3 处返回这个对象。 ### 结果是 getInstance() 方法创建了两个 Singleton 对象，而它本该只创建一个对象。通过同步getInstance() 方法从而在同一时间只允许一个线程执行代码，这个问题得以改正，如清单 2 所示： ### 单锁 public static synchronized Singleton getInstance() { if (instance == null) //1 instance = new Singleton(); //2 return instance; //3 } 中的代码针对多线程访问 getInstance() 方法运行得很好。然而，当分析这段代码时，您会意识到只有在第一次调用方法时才需要同步。由于只有第一次调用执行了 //2 处的代码，而只有此行代码需要同步，因此就无需对后续调用使用同步。所有其他调用用于决定 instance 是非 null 的，并将其返回。多线程能够安全并发地执行除第一次调用外的所有调用。尽管如此，由于该方法是 synchronized 的，需要为该方法的每一次调用付出同步的代价，即使只有第一次调用需要同步。 为使此方法更为有效，一个被称为双重检查锁定的习语就应运而生了。这个想法是为了避免对除第一次调用外的所有调用都实行同步的昂贵代价。同步的代价在不同的 JVM 间是不同的。在早期，代价相当高。随着更高级的 JVM 的出现，同步的代价降低了，但出入 synchronized 方法或块仍然有性能损失。不考虑 JVM 技术的进步，程序员们绝不想不必要地浪费处理时间。 因为只有清单 2 中的 //2 行需要同步，我们可以只将其包装到一个同步块中，如清单 3 所示： Java代码 public static Singleton getInstance() { if (instance == null) { synchronized(Singleton.class) { instance = new Singleton(); } } return instance; } 清单 3 中的代码展示了用多线程加以说明的和清单 1 相同的问题。当 instance 为 null 时，两个线程可以并发地进入 if 语句内部。然后，一个线程进入 synchronized 块来初始化 instance ，而另一个线程则被阻断。当第一个线程退出 synchronized 块时，等待着的线程进入并创建另一个 Singleton 对象。注意：当第二个线程进入 synchronized 块时，它并没有检查 instance 是否非 null 。 双重检查锁定 为处理清单 3 中的问题，我们需要对 instance 进行第二次检查。这就是“双重检查锁定”名称的由来。将双重检查锁定习语应用到清单 3 的结果就是清单 4 。 清单 4. 双重检查锁定示例 Java代码 public static Singleton getInstance() { if (instance == null) { synchronized(Singleton.class) { //1 if (instance == null) //2 instance = new Singleton(); //3 } } return instance; } 双重检查锁定背后的理论是：在 //2 处的第二次检查使（如清单 3 中那样）创建两个不同的 Singleton 对象成为不可能。假设有下列事件序列： 线程 1 进入 getInstance() 方法。 由于 instance 为 null ，线程 1 在 //1 处进入 synchronized 块。 线程 1 被线程 2 预占。 线程 2 进入 getInstance() 方法。 由于 instance 仍旧为 null ，线程 2 试图获取 //1 处的锁。然而，由于线程 1 持有该锁，线程 2 在 //1 处阻塞。 线程 2 被线程 1 预占。 线程 1 执行，由于在 //2 处实例仍旧为 null ，线程 1 还创建一个 Singleton 对象并将其引用赋值给instance 。 线程 1 退出 synchronized 块并从 getInstance() 方法返回实例。 线程 1 被线程 2 预占。 线程 2 获取 //1 处的锁并检查 instance 是否为 null 。 由于 instance 是非 null 的，并没有创建第二个 Singleton 对象，由线程 1 创建的对象被返回。 双重检查锁定背后的理论是完美的。不幸地是，现实完全不同。双重检查锁定的问题是：并不能保证它会在单处理器或多处理器计算机上顺利运行。 双重检查锁定失败的问题并不归咎于 JVM 中的实现 bug，而是归咎于 Java 平台内存模型。内存模型允许所谓的“无序写入”，这也是这些习语失败的一个主要原因。 无序写入 为解释该问题，需要重新考察上述清单 4 中的 //3 行。此行代码创建了一个 Singleton 对象并初始化变量instance 来引用此对象。这行代码的问题是：在 Singleton 构造函数体执行之前，变量 instance 可能成为非null 的。 什么？这一说法可能让您始料未及，但事实确实如此。在解释这个现象如何发生前，请先暂时接受这一事实，我们先来考察一下双重检查锁定是如何被破坏的。假设清单 4 中代码执行以下事件序列： 线程 1 进入 getInstance() 方法。 由于 instance 为 null ，线程 1 在 //1 处进入 synchronized 块。 线程 1 前进到 //3 处，但在构造函数执行之前 ，使实例成为非 null 。 线程 1 被线程 2 预占。 线程 2 检查实例是否为 null 。因为实例不为 null，线程 2 将 instance 引用返回给一个构造完整但部分初始化了的 Singleton 对象。 线程 2 被线程 1 预占。 线程 1 通过运行 Singleton 对象的构造函数并将引用返回给它，来完成对该对象的初始化。 此事件序列发生在线程 2 返回一个尚未执行构造函数的对象的时候。 为展示此事件的发生情况，假设为代码行 instance =new Singleton(); 执行了下列伪代码：instance =new Singleton(); Java代码 mem = allocate(); //Allocate memory for Singleton object. instance = mem; //Note that instance is now non-null, but //has not been initialized. ctorSingleton(instance); //Invoke constructor for Singleton passing //instance. 这段伪代码不仅是可能的，而且是一些 JIT 编译器上真实发生的。执行的顺序是颠倒的，但鉴于当前的内存模型，这也是允许发生的。JIT 编译器的这一行为使双重检查锁定的问题只不过是