万字速通单例模式
单例模式
-
- 一、前言
- 二、几种实现方式的详解
-
- 2.1 懒汉式
- 2.2 双检锁/双重校验锁
- 2.3 红路灯双检锁
- 2.4 静态内部类
- 2.5 使用容器实现单例模式
- 2.6 枚举实现单例
- 三、枚举类不能反射的论证
- 四、负载均衡器的设计
-
- 4.1 背景
- 4.2 结构图
- 4.3 代码实现
- 五、结束语
一、前言
谈起单例模式，想必大家都不陌生，不仅在各种大厂的面试中频频出现，在实际的开发中，也应用广泛，如何设计一个优雅的单例模式，成为了重头戏。
1.1 概念
单例模式（Singleton Pattern）是 Java 中最简单也最复杂的设计模式。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。这种模式涉及到一个单一的类，该类负责创建自己的对象，同时确保只有单个对象被创建。这个类提供了一种访问其唯一的对象的方式，可以直接访问，不需要实例化该类的对象。
根据其概念，我们可以总结出如下三点
- 单例类只能有一个实例。
- 单例类必须自己创建自己的唯一实例。
- 单例类必须给所有其他对象提供这一实例。
1.2 意义
单例模式在内存里只有一个实例，减少了内存的开销，尤其是频繁的创建和销毁实例（比如管理学院首页页面缓存），避免对资源的多重占用（比如写文件操作）。但是单例模式也有一个弊端，没有接口，不能继承，与单一职责原则冲突，一个类应该只关心内部逻辑，而不关心外面怎么样来实例化。
1.3 实现
我们要保证一个类仅有一个实例，并提供一个访问它的全局访问点，并判断系统是否已经有这个单例，如果有则返回，如果没有则创建。
关键代码：构造函数是私有的。
我们将创建一个 SingleObject 类。SingleObject 类有它的私有构造函数和本身的一个静态实例。
SingleObject 类提供了一个静态方法，供外界获取它的静态实例。SingletonPatternDemo 类使用 SingleObject 类来获取 SingleObject 对象。
首先创建一个类----SingleObject.java
public class SingleObject {
//创建 SingleObject 的一个对象
private static SingleObject instance = new SingleObject();
//让构造函数为 private，这样该类就不会被实例化
//防止外部重新构建类的实例
private SingleObject(){}
//获取唯一可用的对象
public static SingleObject getInstance(){
return instance;
}
public void showMessage(){
System.out.println("Hello World!");
}
public static void main(String[] args) {
//不合法的构造函数
//编译时错误：构造函数 SingleObject() 是不可见的
//SingleObject object = new SingleObject();
//获取唯一可用的对象
SingleObject object = SingleObject.getInstance();
//显示消息
object.showMessage();
}
}
执行main方法，输出结果：Hello world！
如上，就是最简单的单例模式的构建，也被称作饿汉式单例模式。
饿汉式：
是否 Lazy 初始化：否
是否多线程安全：是
实现难度：易
描述：这种方式比较常用，但容易产生垃圾对象。 优点：没有加锁，执行效率会提高。 缺点：类加载时就初始化，浪费内存。 它基于classloader 机制避免了多线程的同步问题，不过，instance 在类装载时就实例化，虽然导致类装载的原因有很多种，在单例模式中大多数都是调用 getInstance 方法，但是也不能确定有其他的方式（或者其他的静态方法）导致类装载，这时候初始化 instance 显然没有达到 lazy loading 的效果。
二、几种实现方式的详解
2.1 懒汉式
是否 Lazy 初始化：是
是否多线程安全：是
实现难度：易
描述：这种方式具备很好的 lazy loading，能够在多线程中很好的工作，但是，效率很低，99% 情况下不需要同步。
优点：第一次调用才初始化，避免内存浪费。 缺点：必须加锁 synchronized 才能保证单例，但加锁会影响效率。getInstance() 的性能对应用程序不是很关键（该方法使用不太频繁）。
实现代码
public class Singleton {
private static Singleton instance;
private Singleton (){}
public static synchronized Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
当然，这种方式虽然线程安全，但是对多线程有了解的同学不难看出，这种形式很容易被破坏，在后续笔者会专门写一篇文章来介绍jvm的文章，尽情期待。
对此，对如上的代码做出如下优化：
2.2 双检锁/双重校验锁
双检锁/双重校验锁（DCL，即 double-checked locking）
JDK 版本：JDK1.5 起
是否 Lazy 初始化：是
是否多线程安全：是
实现难度：较复杂
描述：这种方式采用双锁机制，安全且在多线程情况下能保持高性能。 getInstance() 的性能对应用程序很关键。
代码实现：
public class Singleton {
//volatile关键字，防止指令重排，避免在多线程创建对象的时候，被破坏
private volatile static Singleton singleton;
private Singleton (){}
public static Singleton getSingleton() {
//双检锁有效的避免了多线程的侵入
if (singleton == null) {
synchronized (Singleton.class) {
if (singleton == null) {
singleton = new Singleton();
}
}
}
return singleton;
}
}
虽然这样可以避免在多线程的情况下，保证对象唯一，但是如果对反射有所研究的同学，不难发现，这种方式很容易被反射破坏。
对此，我们仍然可以做进一步优化，如下：
2.3 红路灯双检锁
JDK 版本：JDK1.5 起
是否 Lazy 初始化：是
是否多线程安全：是
实现难度：较复杂
描述：这种方式采用红绿灯的思想加双锁机制，安全且在多线程情况下能保持高性能。
public class Singleton {
//volatile关键字，防止指令重排，避免在多线程创建对象的时候，被破坏
private volatile static Singleton singleton;
//红绿灯的标识
private boolean mark = true;
private Singleton (){
synchronized(Singleton.class){
if(mark == true){
mark = false;
}else{
throw new RuntimeException("不能通过反射创建对象");
}
}
}
public static Singleton getSingleton() {
//双检锁有效的避免了多线程的侵入
if (singleton == null) {
synchronized (Singleton.class) {
if (singleton == null) {
singleton = new Singleton();
}
}
}
return singleton;
}
}
增加了红绿灯的思想，极大的增加了安全的机制，只要保护好红绿灯标识，就可以有效的避免反射带来的破坏。
如何保护？我提供两种方法：
- 变量名传入密钥
- 使用String替换boolean，对字段进行加密
2.4 静态内部类
是否 Lazy 初始化：是
是否多线程安全：是
实现难度：一般
描述：这种方式能达到双检锁方式一样的功效，但实现更简单。对静态域使用延迟初始化，应使用这种方式而不是双检锁方式。这种方式只适用于静态域的情况，双检锁方式可在实例域需要延迟初始化时使用。
代码实现：
public class Singleton {
private static class SingletonHolder {
private static final Singleton INSTANCE = new Singleton();
}
private Singleton (){}
public static final Singleton getInstance() {
return SingletonHolder.INSTANCE;
}
}
2.5 使用容器实现单例模式
JDK 版本：JDK1.5 起
是否 Lazy 初始化：否
是否多线程安全：是
实现难度：易
描述： 用SingletonManager 将多种的单例类统一管理，在使用时根据key获取对象对应类型的对象。这种方式使得我们可以管理多种类型的单例，并且在使用时可以通过统一的接口进行获取操作，降低了用户的使用成本，也对用户隐藏了具体实现，降低了耦合度。
public class SingletonManager {
private static Map<String, Object> objMap = new HashMap<String,Object>();
private Singleton() {
}
public static void registerService(String key, Objectinstance) {
if (!objMap.containsKey(key) ) {
objMap.put(key, instance) ;
}
}
public static ObjectgetService(String key) {
return objMap.get(key) ;
}
}
2.6 枚举实现单例
JDK 版本：JDK1.5 起
是否 Lazy 初始化：否
是否多线程安全：是
实现难度：易
描述：这种实现方式还没有被广泛采用，但这是实现单例模式的最佳方法。它更简洁，自动支持序列化机制，绝对防止多次实例化。
这种方式是 Effective Java 作者 Josh Bloch 提倡的方式，它不仅能避免多线程同步问题，而且还自动支持序列化机制，防止反序列化重新创建新的对象，绝对防止多次实例化。不过，由于 JDK1.5 之后才加入 enum 特性，用这种方式写不免让人感觉生疏，在实际工作中，也很少用。
不能通过 reflection attack 来调用私有构造方法。
代码实现：
public enum Singleton {
INSTANCE;
public void whateverMethod() {
}
}
三、枚举类不能反射的论证
通过枚举来创建对象已经被很多人都推崇，那么为什么枚举不可以通过反射来创建对象呢？让我们看看源码是怎么说的。
哦，原来在源码里，就声明了，不能通过反射来创建对象，如果通过反射来创建对象，那么就会抛出异常。
虽然源码里是这么说的，但是我们如何让代码抛出这个异常成为了关键。
我们可以尝试通过反射来创建一个新的对象，那么总会抛出找不到构造方法的异常，却没有抛出"Cannot reflectively create enum objects"
我们查看枚举类的源码，发现其只是一个普通类继承了枚举关键字，拥有一个无参的构造方法，那么我们通过反射来船舰枚举类的对象，为什么没有找到相应的构造方法呢？难道它是有参数的构造方法？难道是代码欺骗了我们？
我们通过IDEA的反编译插件，发现其构造方法还是无参的，最后通过第三方反编译工具jad，发现了端倪。
我们通过第三方反编译工具jad，发现枚举类的构造参数有两个参数，一个是String类型，一个是int类型。
为此，我们在通过反射获取构造器的时候，加上String.class和int.class，就可以得到如下的异常：
"Cannot reflectively create enum objects"
四、负载均衡器的设计
4.1 背景
Sunny软件公司承接了一个服务器负载均衡(Load Balance)软件的开发工作，该软件运行在一台负载均衡服务器上，可以将并发访问和数据流量分发到服务器集群中的多台设备上进行并发处理，提高系统的整体处理能力，缩短响应时间。由于集群中的服务器需要动态删减，且客户端请求需要统一分发，因此需要确保负载均衡器的唯一性，只能有一个负载均衡器来负责服务器的管理和请求的分发，否则将会带来服务器状态的不一致以及请求分配冲突等问题。如何确保负载均衡器的唯一性是该软件成功的关键。
4.2 结构图
Sunny公司开发人员通过分析和权衡，决定使用单例模式来设计该负载均衡器，结构图如图所示：
4.3 代码实现
我们将负载均衡器LoadBalancer设计为单例类，其中包含一个存储服务器信息的集合serverList，每次在serverList中随机选择一台服务器来响应客户端的请求，实现代码如下所示：
import java.util.*;
//负载均衡器LoadBalancer：单例类，真实环境下该类将非常复杂，包括大量初始化的工作和业务方法，考虑到代码的可读性和易理解性，只列出部分与模式相关的核心代码
class LoadBalancer {
//私有静态成员变量，存储唯一实例
private static LoadBalancer instance = null;
//服务器集合
private List serverList = null;
//私有构造函数
private LoadBalancer() {
serverList = new ArrayList();
}
//公有静态成员方法，返回唯一实例
public static LoadBalancer getLoadBalancer() {
if (instance == null) {
instance = new LoadBalancer();
}
return instance;
}
//增加服务器
public void addServer(String server) {
serverList.add(server);
}
//删除服务器
public void removeServer(String server) {
serverList.remove(server);
}
//使用Random类随机获取服务器
public String getServer() {
Random random = new Random();
int i = random.nextInt(serverList.size());
return (String)serverList.get(i);
}
}
客户端测试代码：
class Client {
public static void main(String args[]) {
//创建四个LoadBalancer对象
LoadBalancer balancer1,balancer2,balancer3,balancer4;
balancer1 = LoadBalancer.getLoadBalancer();
balancer2 = LoadBalancer.getLoadBalancer();
balancer3 = LoadBalancer.getLoadBalancer();
balancer4 = LoadBalancer.getLoadBalancer();
//判断服务器负载均衡器是否相同
if (balancer1 == balancer2 && balancer2 == balancer3 && balancer3 == balancer4) {
System.out.println("服务器负载均衡器具有唯一性！");
}
//增加服务器
balancer1.addServer("Server 1");
balancer1.addServer("Server 2");
balancer1.addServer("Server 3");
balancer1.addServer("Server 4");
//模拟客户端请求的分发
for (int i = 0; i < 10; i++) {
String server = balancer1.getServer();
System.out.println("分发请求至服务器： " + server);
}
}
}
编译并运行程序，输出结果如下：
服务器负载均衡器具有唯一性！
分发请求至服务器： Server 1
分发请求至服务器： Server 3
分发请求至服务器： Server 4
分发请求至服务器： Server 2
分发请求至服务器： Server 3
分发请求至服务器： Server 2
分发请求至服务器： Server 3
分发请求至服务器： Server 4
分发请求至服务器： Server 4
分发请求至服务器： Server 1
五、结束语
单例模式作为一种目标明确、结构简单的设计模式，在软件开发中使用频率相当高，在我们常见的软件和框架中都得以广泛应用。
1.主要优点
单例模式的主要优点如下：
(1) 单例模式提供了对唯一实例的受控访问。因为单例类封装了它的唯一实例，所以它可以严格控制客户怎样以及何时访问它。
(2) 由于在系统内存中只存在一个对象，因此可以节约系统资源，对于一些需要频繁创建和销毁的对象单例模式无疑可以提高系统的性能。
(3) 允许可变数目的实例。基于单例模式我们可以进行扩展，使用与单例控制相似的方法来获得指定个数的对象实例，既节省系统资源，又解决了单例单例对象共享过多有损性能的问题。
2.主要缺点
单例模式的主要缺点如下：
(1) 由于单例模式中没有抽象层，因此单例类的扩展有很大的困难。
(2) 单例类的职责过重，在一定程度上违背了“单一职责原则”。因为单例类既充当了工厂角色，提供了工厂方法，同时又充当了产品角色，包含一些业务方法，将产品的创建和产品的本身的功能融合到一起。
(3) 现在很多面向对象语言(如Java、C#)的运行环境都提供了自动垃圾回收的技术，因此，如果实例化的共享对象长时间不被利用，系统会认为它是垃圾，会自动销毁并回收资源，下次利用时又将重新实例化，这将导致共享的单例对象状态的丢失。
3.适用场景
在以下情况下可以考虑使用单例模式：
(1) 系统只需要一个实例对象，如系统要求提供一个唯一的序列号生成器或资源管理器，或者需要考虑资源消耗太大而只允许创建一个对象。
(2) 客户调用类的单个实例只允许使用一个公共访问点，除了该公共访问点，不能通过其他途径访问该实例。
4.思考
如何对单例模式进行改造，使得系统中某个类的对象可以存在有限多个，例如两例或三例？【注：改造之后的类可称之为多例类。】