《实战 Java 高并发程序设计》笔记——第5章 并行模式与算法

声明：

本博客是本人在学习《实战 Java 高并发程序设计》后整理的笔记，旨在方便复习和回顾，并非用作商业用途。

本博客已标明出处，如有侵权请告知，马上删除。

由于并行程序设计比串行程序复杂得多。因此，我强烈建议大家可以熟悉和了解一些常见的设计方法。就好像练习武术一样，一招一式都是要经过学习的。如果自己胡乱打一气，效果不见得好。前人会总结一些武术套路，对于初学者来说，不需要发挥自己的想象力，只要按照武术套路出拳就可以了。等到练到了一定的高度，就可以以无招胜有招了，而不必拘泥于套路。这些武术套路和招数，对应到软件开发中来，就是设计模式。在这一章中，我将重点向大家介绍一些有关并行的设计模式以及算法。这些都是前人的经验总结和智慧的结晶。大家可以在熟知其思想和原理的基础之上，再根据自己的需求进行扩展，可能会达到更好的效果。

5.1 探讨单例模式

单例模式是设计模式中使用最为普遍的模式之一。它是一种对象创建模式，用于产生一个对象的具体实例，它可以确保系统中一个类只产生一个实例。

在 Java 中，这样的行为能带来两大好处：

• 对于频繁使用的对象，可以省略 new 操作花费的时间，这对于那些重量级对象而言，是非常可观的一笔系统开销；
• 由于 new 操作的次数减少，因而对系统内存的使用频率也会降低，这将减轻 GC 压力，缩短 GC 停顿时间。

严格来说，单例模式与并行没有直接的关系。这里我希望讨论这个模式，是因为它实在是太常见了。并且，我们不可避免的，会在多线程环境中使用它们。并且，系统中使用单例的地方可能非常频繁，因此，我们非常迫切需要一种高效的单例实现。

下面给出了一个单例的实现，这个实现是非常简单的，但无疑是一个正确并且良好的实现。

使用以上方式创建单例有几点必须特别注意。

• 第一点，因为我们要保证系统中不会有人意外创建多余的实例，因此，我们把 Singleton 的构造函数设置为 private。这点非常重要，这就警告所有的开发人员，不能随便创建这个类的实例，从而有效避免该类被错误的创建。
• 第二点，instance 对象必须是 private 并且 static 的。如果不是 private，那么 instance 的安全性无法得到保证。一个小小的意外就可能使得 instance 变成 null。其次，因为工厂方法 getInstance() 必须是 static 的，因此对应的 instance 也必须是 static。

这个单例的性能是非常好的，因为 getInstance() 方法只是简单地返回 instance，并没有任何锁操作，因此它在并行程序中，会有良好的表现。

但是这种方式有一点明显不足，就是 Singleton 构造函数，或者说 Singleton 实例在什么时候创建是不受控制的。对于静态成员 instance，它会在类第一次初始化的时候被创建。这个时刻并不一定是 getInstance() 方法第一次被调用的时候。

比如，如果你的单例像是这样的：

注意，这个单例还包含一个表示状态的静态成员 STATUS。此时，在相同任何地方引用这个 STATUS 都会导致 instance 实例被创建（任何对 Singleton 方法或者字段的引用，都会导致类初始化，并创建 instance 实例，但是类初始化只有一次，因此 instance 实例永远只会被创建一次）。比如：

上述 println 会打印出：

可以看到，即使系统没有要求创建单例，new Singleton() 也会被调用。

如果大家觉得这个小小的不足并不重要，我认为这种单例模式是一种不错的选择。它容易实现，代码易读而且性能优越。

但如果你想精确控制 instance 的创建时间，那么这种方式就不太友善了。我们需要寻找一种新的方法，一种支持延迟加载的策略，它只会在 instance 被第一次使用时，创建对象。具体实现如下：

这个 LazySingleton 的核心思想如下：最初，我们并不需要实例化 instance，而当 getInstance() 方法被第一次调用时，创建单例对象。为了防止对象被多次创建，我们不得不使用 synchronized 进行方法同步。这种实现的好处是，充分利用了延迟加载，只在真正需要时创建对象。但坏处也很明显，并发环境下加锁，竞争激烈的场合对性能可能产生一定的影响。但总体上，这是一个非常易于实现和理解