第7章 单态模式.pptVIP

由于只有第一次调用执行了//2 处的代码，而只有此行代码需要同步，因此就无需对后续调用使用同步。所有其他调用用于决定 instance 是非 null 的，并将其返回。多线程能够安全并发地执行除第一次调用外的所有调用。 尽管如此，由于该方法是 synchronized 的，需要为该方法的每一次调用都付出同步的代价，即使只有第一次调用需要同步。 为使此方法更为有效，一个被称为双重检查锁定的习语就应运而生了。这个想法是为了避免对除第一次调用外的所有调用都实行同步的昂贵代价。同步的代价在不同的 JVM 间是不同的。在早期，代价相当高。随着更高级的 JVM 的出现，同步的代价降低了，但出入 synchronized 方法或块仍然有性能损失。不考虑 JVM 技术的进步，程序员们绝不想不必要地浪费处理时间。 因为只有上页清单 2 中的 //2 行需要同步，我们可以只将其包装到一个同步块中，如清单3 所示： 单例创建模式是一个通用的编程习语。和多线程一起使用时，必需使用某种类型的同步。 在努力创建更有效的代码时，Java 程序员们创建了双重检查锁定名称，将其和单例创建模式一起使用，从而限制同步代码量 * 当 instance 为 null 时，两个线程可以并发地进入 if 语句内部。然后，一个线程进入 synchronized 块来初始化 instance，而另一个线程则被阻断。当第一个线程退出 synchronized 块时，等待着的线程进入并创建另一个 Singleton 对象。 当第二个线程进入 synchronized 块时，它并没有检查 instance 是否非 null。 /*当第二个线程进入 synchronized时，它并没有检查 instance 是否非 null*/ * Double-Checked Locking 双重检查锁定背后的理论是：在 //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 平台内存模型。内存模型允许所谓的“无序写入”，这也是这些习语失败的一个主要原因。 解决无序写入问题的尝试public static Singleton getInstance() { if (instance == null) { synchronized(Singleton.class) { //1 Singleton inst = instance; //2 if (inst == null) { synchronized(Singleton.class) { //3 inst = new Singleton(); //4 } instance = inst; //5 } } } return instance; } * 虽然可以使用双重加锁机制来实现线程安全的单例，但并不建议大量采用，根据情况来选用吧。 * （1）每台计算机可以有若干个打印机，但只能有一个Printer Spooler，避免两个打印作业同时输出到打印机。 * （1）每台计算机可以有若干个打印机，但只能有一个Printer Spooler，避免两个打印作业同时输出到打印机。 * struts1中过度的依赖servlet容器 * spring IOC容器(Inversion of Control container) * 单例模式的优点 提供