Spring用到了哪些设计模式？

最近遇到了这个问题，也借着记录这个问题的答案回顾一下常见的设计模式。所以问题的答案就在第一节且很短，大部分是在介绍常见的设计模式及其写法。

Spring 框架中⽤到了哪些设计模式？

• ⼯⼚设计模式 : Spring 使⽤⼯⼚模式通过BeanFactory 、ApplicationContext 创建 bean 对象。
• 单例设计模式 : Spring 中的 Bean 默认都是单例的(与传统的单例有所不同)。
• 代理设计模式 : Spring AOP 功能的实现。
• 模板⽅法模式 : Spring 中 jdbcTemplate 、hibernateTemplate 等以Template 结尾的对数据库操作的类，它们就使⽤到了模板模式。
• 包装器(装饰器)设计模式 : 我们的项⽬需要连接多个数据库，⽽且不同的客户在每次访问中根据需要会去访问不同的数据库。这种模式让我们可以根据客户的需求能够动态切换不同的数据源。
• 观察者模式: Spring 事件驱动模型就是观察者模式很经典的⼀个应⽤。
• 适配器模式 :Spring AOP 的增强或通知(Advice)使⽤到了适配器模式。spring MVC 中也是⽤到了适配器模式适配Controller 。
• 责任链模式：Spring MVC中的HandlerExecutionChain类，就使用到了责任链模式。
• 策略模式：Spring 中的 InstantiationStrategy 接口，根据创建对象情况的不同，提供了Spring Bean实例化的三种策略︰默认构造方法、指定构造方法或者工厂方法。这是一种典型的策略模式。

下面分别进行介绍

工厂模式

在java中，万物皆对象，如果创建的时候直接new该对象，就会对该对象耦合严重，假如要更换对象，所有new对象的地方都需要修改一遍，这显然违背了软件设计的开闭原则(对扩展开放，对修改关闭。为了使程序的扩展性好，易于维护和升级)。如果使用工厂来生产对象，就只和工厂打交道就可以了，彻底和对象解耦，如果要更换对象，直接在工厂里更换该对象即可，达到了与对象解耦的目的；所以说，工厂模式最大的优点就是：解耦。

工厂模式(Factory Patterm）封装了对象创建的过程，使用者不需要关心对象创建的细节。工厂模式分为三种:简单工厂模式、工厂方法模式和抽象工厂模式。在编码中该模式通常都是以*Factory 的形式呈现。

Spring 中的 BeanFactory就是简单工厂模式的体现，我们可以根据 beanName 在 BeanFactory中获取 bean对象;而Spring 中的FactoryBean就是工厂方法模式的体现，我们可以通过实现FactoryBean 接口并实现其getObject()方法来自定义bean对象。

单例模式

单例模式(Singleton Pattern)是最常使用的一种设计模式，它可以确保某一个类只有一个实例，构造⽅法必须是私有的、由⾃⼰创建⼀个静态变量存储实例，对外提供⼀个静态公有⽅法获取实例。在Spring 中，bean 的作用域默认就是单例的。它是通过单例池来确保在Spring容器中只会存在一个对象实例。

Spring的单例与传统单例还是不太一样，它这个单例模式的范围不是传统单例模式中JVM的范围中只有一个实例，而Spring容器在第一次请求该Bean时创建一个实例，并在之后的每次请求中返回同一个实例。这种单例模式与传统的单例模式有些许区别。比如一个UserServive，你还可以再声明几个，只要bean的名称不同就行了。

单例模式的常⻅写法有:

• 1.饿汉式，线程安全

• • 优点：线程安全，没有加锁，执⾏效率较⾼
    缺点：不是懒加载，类加载时就初始化，浪费内存空间

• 2.懒汉式，线程不安全

• • 优点：懒加载
    缺点：线程不安全

• 3.懒汉式，线程安全（使用synchronized）

• • 优点：懒加载，线程安全
    缺点：效率较低

• 4.双重检查锁（DCL， 即 double-checked locking）

• • 优点：懒加载，线程安全，效率较⾼
    缺点：实现较复杂

• 5.静态内部类(推荐)

• • 优点：懒加载，线程安全，效率较⾼，实现简单

• 6.枚举单例

• • 优点：简单，⾼效，线程安全，可以避免通过反射破坏枚举单例

下面对这些常见写法举例，首先是

1.饿汉式，线程安全

public class Singleton {
	// 1、私有化构造⽅法
	private Singleton(){}
	// 2、定义⼀个静态变量指向⾃⼰类型
	private final static Singleton instance = new Singleton();
	// 3、对外提供⼀个公共的⽅法获取实例
	public static Singleton getInstance() {
		return instance;
	}
}

优点：实现简单，不需要加锁，线程安全。
缺点：在类加载时就创建实例，可能造成资源浪费。

2.懒汉式，线程不安全

有多个线程同时调⽤时，导致⽣成多个实例

public class Singleton {
	// 1、私有化构造⽅法
	private Singleton(){ }
	// 2、定义⼀个静态变量指向⾃⼰类型
	private static Singleton instance;
	// 3、对外提供⼀个公共的⽅法获取实例
	public static Singleton getInstance() {
		// 判断为 null 的时候再创建对象
		if (instance == null) {
			instance = new Singleton();
		}
		return instance;
	}
}

public class Test {
	public static void main(String[] args) {
		for (int i = 0; i < 3; i++) {
			new Thread(() -> {
				System.out.println("多线程创建的单例：" + Singleton.getInstance());
			}).start();
		}
	}
}
/*
输出结果如下：
多线程创建的单例：
com.example.spring.demo.single.Singleton@18396bd5
多线程创建的单例：
com.example.spring.demo.single.Singleton@7f23db98
多线程创建的单例：
com.example.spring.demo.single.Singleton@5000d44
*/

3.懒汉式，线程安全

懒汉式单例如何保证线程安全呢？通过 synchronized 关键字加锁保证线程安全， synchronized 可以添加在⽅法上⾯，也可以添加在代码块上⾯，这⾥演示添加在⽅法上⾯，存在的问题是每⼀次调⽤ getInstance 获取实例时都需要加锁和释放锁，这样是⾮常影响性能的。

public class Singleton {
	// 1、私有化构造⽅法
	private Singleton(){ }
	// 2、定义⼀个静态变量指向⾃⼰类型
	private static Singleton instance;
	// 3、对外提供⼀个公共的⽅法获取实例
	public synchronized static Singleton getInstance() {
		// 判断为 null 的时候再创建对象
		if (instance == null) {
			instance = new Singleton();
		}
		return instance;
	}
}

优点：实现简单，支持延迟加载。
缺点：每次获取实例时都需要锁同步，性能开销大。

4.双重检查锁（DCL， 即 double-checked locking）

public class Singleton {
	// 1、私有化构造⽅法
	private Singleton() {
	}
	
	// 2、定义⼀个静态变量指向⾃⼰类型 注意这里使用了volatile关键字！
	private volatile static Singleton instance;
	
	// 3、对外提供⼀个公共的⽅法获取实例
	public static Singleton getInstance() {
		// 第⼀重检查是否为 null
		if (instance == null) {
			// 使⽤ synchronized 加锁
			synchronized (Singleton.class) {
				// 第⼆重检查是否为 null
				if (instance == null) {
					// new 关键字创建对象不是原⼦操作
					instance = new Singleton();
				}
			}
		}
		return instance;
	}
}

双重检查是指两次⾮空判断，锁指的是synchronized 加锁。为什么要进⾏双重判断，其实很简单，第⼀重判断，如果实例已经存在，那么就不再需要进⾏同步操作，⽽是直接返回这个实例。如果没有创建，才会进⼊同步块，同步块的⽬的与之前相同，⽬的是为了防⽌有多个线程同时调⽤时，导致⽣成多个实例，当第⼀个抢到锁的调⽤获取了实例之后，这个实例就会被创建，之后的所有调⽤都不会进⼊同步块，直接在第⼀重判断就返回了单例。

关于内部的第⼆重空判断的作⽤，当多个线程⼀起到达锁位置时，进⾏锁竞争，其中⼀个线程获取锁，如果是第⼀次进⼊则为 null，会进⾏单例对象的创建，完成后释放锁，其他线程获取锁后就会被空判断拦截，直接返回已创建的单例对象。

其中最关键的⼀个点就是 volatile 关键字的使用，关于这个关键字的介绍可以看这篇博客。

这⾥为什么要使⽤ volatile ？这是因为 new 关键字创建对象不是原⼦操作，创建⼀个对象会经历下⾯的步骤：

1. 在堆内存开辟内存空间
2. 调⽤构造⽅法，初始化对象
3. 引⽤变量指向堆内存空间

为了提⾼性能，编译器和处理器常常会对既定的代码执⾏顺序进⾏指令重排序。所以经过指令重排序之后，创建对象的执⾏顺序可能为 1 2 3 或者 1 3 2 ，因此当某个线程在乱序运⾏ 1 3 2 指令的时候，引⽤变量指向堆内存空间，这个对象不为 null，但是没有初始化，其他线程有可能这个时候进⼊了 getInstance 的第⼀个 if(instance == null) 判断不为 nulll ，导致错误使⽤了没有初始化的⾮ null 实例，这样的话就会出现异常，这个就是著名的DCL 失效问题。

当我们在引⽤变量上⾯添加 volatile 关键字以后，会通过在创建对象指令的前后添加内存屏障来禁⽌指令重排序，就可以避免这个问题，⽽且对volatile 修饰的变量的修改对其他任何线程都是可⻅的。

优点：支持延迟加载，减少同步开销。
缺点：代码复杂，容易出错，必须使用volatile关键字确保线程安全。

5.静态内部类

public class Singleton {
	// 1、私有化构造⽅法
	private Singleton() {
	}
	// 2、对外提供获取实例的公共⽅法
	public static Singleton getInstance() {
		return InnerClass.INSTANCE;
	}
	// 定义静态内部类
	private static class InnerClass{
		private final static Singleton INSTANCE = new Singleton();
	}
}

静态内部类单例是如何实现懒加载的呢？⾸先，我们先了解下类的加载时机。

虚拟机规范要求有且只有 5 种情况必须⽴即对类进⾏初始化（加载、验证、准备需要在此之前开始）：

1. 遇到 new 、getstatic 、putstatic 、invokestatic 这 4 条字节码指令时。⽣成这 4 条指令最常⻅的 Java 代码场景是：使⽤ new 关键字实例化对象的时候、读取或设置⼀个类的静态字段（final 修饰除外，被final 修饰的静态字段是常量，已在编译期把结果放⼊常量池）的时候，以及调⽤⼀个类的静态⽅法的时候。
2. 使⽤ java.lang.reflect 包⽅法对类进⾏反射调⽤的时候。
3. 当初始化⼀个类的时候，如果发现其⽗类还没有进⾏过初始化，则需要先触发其⽗类的初始化。
4. 当虚拟机启动时，⽤户需要指定⼀个要执⾏的主类（包含 main()的那个类），虚拟机会先初始化这个主类。
5. 当使⽤ JDK 1.7 的动态语⾔⽀持时，如果⼀个java.lang.invoke.MethodHandle 实例最后的解析结果是REF_getStatic 、REF_putStatic 、REF_invokeStatic 的⽅法句柄，则需要先触发这个⽅法句柄所对应的类的初始化。

这 5 种情况被称为是类的主动引⽤，那么，除此之外的所有引⽤类都不会对类进⾏初始化，称为被动引⽤。静态内部类就属于被动引⽤的情况。

当 getInstance()⽅法被调⽤时，InnerClass 才在 Singleton 的运⾏时常量池⾥，把符号引⽤替换为直接引⽤，这时静态对象 INSTANCE 也真正被创建，然后再被 getInstance()⽅法返回出去，这点同饿汉模式。那么 INSTANCE 在创建过程中⼜是如何保证线程安全的呢？

JVM虚拟机会保证⼀个类的<clinit/>⽅法在多线程环境中被正确地加锁、同步，如果多个线程同时去初始化⼀个类，那么只会有⼀个线程去执⾏这个类的<clinit>()⽅法，其他线程都需要阻塞等待，直到活动线程执⾏<clinit>() ⽅法完毕。如果在⼀个类的 <clinit>() ⽅法中有耗时很⻓的操作，就可能造成多个进程阻塞(需要注意的是，其他线程虽然会被阻塞，但如果执⾏<clinit>() ⽅法后，其他线程唤醒之后不会再次进⼊<clinit>() ⽅法。同⼀个加载器下，⼀个类型只会初始化⼀次。)，在实际应⽤中，这种阻塞往往是很隐蔽的。
从上⾯的分析可以看出 INSTANCE 在创建过程中是线程安全的，所以说静态内部类形式的单例可保证线程安全，也能保证单例的唯⼀性，同时也延迟了单例的实例化。

因为在初始化静态变量时，JVM会保证这个过程是不会被指令重排破坏的。因为在类初始化的过程中，JVM会加一个初始化锁，任何一个线程进入类的初始化时，其他线程都被阻塞，所以也不会出现指令重排的情况。

因此，静态内部类的单例实现不仅代码简洁，而且天然地避免了指令重排带来的线程安全问题，这是其成为推荐实现方式的主要原因之一。

优点：实现简单，支持延迟加载，线程安全，不需要同步。
缺点：无明显缺点，是一种非常推荐的单例实现方式。

6.枚举单例

public enum Singleton {
	INSTANCE;
	public void doSomething(String str) {
		System.out.println(str);
	}
}

//可以直接通过如下⽅式调⽤获取实例：
Singleton singleton = Singleton.INSTANCE;

枚举在 java 中与普通类⼀样，都能拥有字段与⽅法，⽽且枚举实例创建是线程安全的，在任何情况下，它都是⼀个单例。
从枚举的反编译结果可以看到，INSTANCE 被 static final 修饰，所以可以通过类名直接调⽤，并且创建对象的实例是在静态代码块中创建的，因为static 类型的属性会在类被加载之后被初始化，当⼀个 Java 类第⼀次被真正使⽤到的时候静态资源被初始化、Java 类的加载和初始化过程都是线程安全的，所以创建⼀个 enum 类型是线程安全的。

类加载的过程中，JVM会自动保证内存屏障，确保类加载和初始化的顺序。
枚举实例的创建是由JVM在类加载期间完成的，所以也不存在指令重排的可能性。

优点：实现简单，天然线程安全，防止反序列化和反射攻击。
缺点：没有延迟加载特性。

哪些情况下单例模式会被破坏？如何反破坏？

单例模式被破坏一共有五个场景，针对每个场景都有各自的解决办法。

1.多线程破坏单例
在多线程环境下线程的时间片是由 CPU 来自由分配的具有随机性，而单例对象作为共享资源的话可能会同时被多个线程同时操作，从而会导致同时创建多个对象，当然这种情况只会出现在懒汉式单例中，如果是饿汉式单例的话在线程启动前就已经被初始化了，所以就不存在线程再创建对象的情况。

解决方案：改为DCL双重检查锁写法或者静态内部类的写法

2.指令重排破坏单例

JVM指令重排可能导致懒汉式单例被破坏，因为一个简单的new语句，JVM内部会转为多条执行指令，分盘内存、初始化对象、赋值引用，经过指令重排序之后，创建对象的执⾏顺序可能为 1 2 3 或者 1 3 2 ，因此当某个线程在乱序运⾏ 1 3 2 指令的时候，引⽤变量指向堆内存空间，这个对象不为 null，但是没有初始化，其他线程有可能这个时候进⼊了 getInstance 的第⼀个 if(instance == null) 判断不为 nulll ，导致错误使⽤了没有初始化的⾮ null 实例，这样的话就会出现异常，这个就是著名的DCL 失效问题。

解决方案：成员变量前加一个volatile关键字

3.克隆破坏单例

Java中所有的类都是继承自Object，也就是说所有的类都实现了clone()方法，那如果是深clone()的话每次都会去重新创建新的实例，那如果我们定义的对象是单例对象，那如果我们定义的对象是单例对象，那不是也可以去调用clone()方法来反复创建新的实例。

那为了避免发生这样的结果我们可以在单例对象中重写clone()方法，将单例自身的引用作为返回值，这样的话就可以避免这种情况发生

4.反序列化破坏单例

我们Java对象反序列化以后,对象通常可能会被持久化到磁盘或者是到数据库，如果我们再次去加载到内存的时候我们就需要将持久化以后的内容反序列化成Java对象，而反序列化又是基于字节码来操作的，如果我们需要序列化以前的内容进行反序列化到内存的话就需要重新去分配内存空间，也就是说要重新去创建Java对象，那如果我们要反序列的对象它恰恰是单例对象就出现问题了。

解决方法也很简单，在反序列化时Java API里面会调用一个叫做readResolve()方法，可以通过去获取readResolve()方法的返回值来覆盖反序列化以后的创建的对象，那因此我们只需要重写readResolve()方法就可以了，将返回值设为已经存在的单例对象就可以去保证反序列化以后的对象是同一个了。之后呢再将反序列化以后的对象的所有属性克隆到单例对象中。

5.反射破坏单例

Java中的反射机制是可以拿到对象的私有的构造方法的，即反射可以任意调用私有的构造方法来创建新的单例对象，虽然很少有人会故意这样做，但是如果出现这样的意外情况的话怎么处理呢。

第一种解决方案是在所有的构造方法中的第一行代码就进行判断，检查单例对象是否被创建，那如果已经创建我们就抛出异常
第二种方案就是将单例的实现方式改为枚举式单例，因为在JDK源码里已经规定了不允许用反射来访问枚举。缺点是枚举单例没有延迟加载特性。

单例模式写法推荐

1.如果程序不是太复杂，单例对象又不多，推荐使用饿汉式单例
2.如果经常发生多线程并发情况，推荐使用静态内部类和枚举式单例

代理模式

代理模式(Proxy Pattern)主要是通过创建一个代理对象来实现对目标对象的访问，以达到保护和增强目标对象的目的。代理模式有两种具体的实现:静态代理和动态代理。Spring 中的AOP就是基于JDK和CGlib这两种动态代理实现的。

这里不展开讲，可以参考这篇文章。

模板模式

模板模式(Template Patterm）就是抽象父类提供一套定义好的方法供子类调用，而其中的某些方法子类会根据自己的情况而进行定制。就好像我们平时用模板写一些东西，但是内容却各不相同。在编码中该模式通常都是以*Template 的形式呈现。
Spring JDBC中的JdbcTemplate、Spring事务管理中的TransactionTemplate就是模板模式的体现。

包装器(装饰器)模式

装饰器模式(Decorator Patterm)允许我们向一个现有的对象添加新的功能，同时又不改变其现有的结构。当我们需要为一个类扩展功能时可以考虑使用装饰器模式，但是该模式的缺点就是需要增加额外的代码。
在Spring 中，装饰器模式在类名上有两种表现:一种是类名中含有Wrapper，另一种是类名中含有Decorator。

许多编程语⾔使⽤ final 最终关键字来限制对某个类的进⼀步扩展。 复⽤最终类已有⾏为的唯⼀⽅法是使⽤装饰模式： ⽤封装器对其进⾏封装。

当你需要在不改变现有对象结构的情况下动态地添加新功能时，装饰器模式就显得很有用了。想象一下你有一个基础的对象，你希望在其上添加一些额外的功能，但是你不想修改这个对象的代码或者继承它来创建一个新的子类。这时候装饰器模式就能派上用场。


比如，假设你有一个 Coffee 类表示一杯咖啡，它有一个方法 cost() 返回咖啡的价格。现在你想给这个咖啡添加额外的功能，比如加糖、加奶等，但是你不想修改 Coffee 类的代码。这时你可以创建装饰器类，比如 SugarDecorator 和 MilkDecorator，它们都实现了与 Coffee 类相同的接口。在这些装饰器类中，你可以修改 cost() 方法来添加额外的费用，并在其中调用原始对象的 cost() 方法。


通过装饰器模式，你可以轻松地在运行时动态地添加或移除功能，而不必改变原始对象的结构。这与代理模式或继承方式不同，因为代理模式是为了控制对对象的访问，而继承方式则是通过创建新的子类来扩展功能，但这两种方式都可能会改变对象的结构或者引入不必要的复杂性。而装饰器模式则保持了对象的简洁性和灵活性。

观察者模式

观察者模式(Observer Pattern)定义了一种一对多的依赖关系，当一个对象的状态发生改变时，其所有依赖者都会收到通知并自动更新。
Spring 中的事件监听机制是观察者模式典型的应用，如ApplicationListener。还有Netty中的基于Selector对象实现的I/O多路复用，通过Selector 一个线程可以监听多个连接的Channel事件。

优点：
被观察者和观察者之间是抽象耦合的；
耦合度较低，两者之间的关联仅仅在于消息的通知；
被观察者⽆需关⼼他的观察者；
⽀持⼴播通信；

缺点：
观察者只知道被观察对象发⽣了变化，但不知变化的过程和缘由；
观察者同时也可能是被观察者，消息传递的链路可能会过⻓，完成所有
通知花费时间较多；
如果观察者和被观察者之间产⽣循环依赖，或者消息传递链路形成闭环，会导致⽆限循环；

适配器模式

适配器模式(Adapter Pattern)可以作为两个不兼容的接口之间的桥梁，它可以使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。在编码中该模式通常都是以*Adapter的形式呈现。
Spring AOP中的 AdvisorAdapter类、Spring MVC中的HandlerAdapter接口，就是适配器模式的典型体现。

用一个简单的例子来说明适配器模式在 Java 中的应用。假设我们有一个旧的日志系统，它有一个名为 OldLogger 的类，但我们希望使用一个新的日志系统，它的接口为 Logger，而不想修改现有的代码。这时候就可以使用适配器模式。

// 目标接口
interface Logger {
    void log(String message);
}

// 被适配者
class OldLogger {
    void logMessage(String msg) {
        System.out.println("OldLogger: " + msg);
    }
}

// 适配器
class OldLoggerAdapter implements Logger {
    private OldLogger oldLogger;

    public OldLoggerAdapter(OldLogger oldLogger) {
        this.oldLogger = oldLogger;
    }

    @Override
    public void log(String message) {
        oldLogger.logMessage(message);
    }
}

// 客户端代码
public class Client {
    public static void main(String[] args) {
        // 创建旧日志系统的实例
        OldLogger oldLogger = new OldLogger();

        // 创建适配器，将旧日志系统适配成新接口
        Logger logger = new OldLoggerAdapter(oldLogger);

        // 使用新接口进行日志记录
        logger.log("This is a message.");
    }
}

责任链模式

责任链模式(Chain of Responsibility Pattern)为请求创建了一个接收者对象的链，在这种模式中，通常每个接收者都包含对另一个接收者的引用。如果一个对象不能处理该请求，那么它会把相同的请求传给下一个接收者，依此类推。在编码中该模式通常都是以*Chain的形式呈现。

责任链模式⾮常简单异常好理解，其应⽤也⼏乎⽆所不在，甚⾄可以这么说从你敲代码的第⼀天起你就不知不觉⽤过了它最原始的裸体结构： switch-case 语句。

责任链模式的应⽤场景:

• 讲讲责任链模式的应⽤场景当程序需要使⽤不同⽅式处理不同种类请求， ⽽且请求类型和顺序预先未知时， 可以使⽤责任链模式。该模式能将多个处理者连接成⼀条链。 接收到请求后， 它会 “询问” 每个处理者是否能够对其进⾏处理。这样所有处理者都有机会来处理请求。比较常见的springmvc中的拦截器，web开发中的filter过滤器
• 当必须按顺序执⾏多个处理者时， 可以使⽤该模式。 ⽆论你以何种顺序将处理者连接成⼀条链， 所有请求都会严格按照顺序通过链上的处理者。比如netty里的ChannelHandler被添加到ChannelPipeline 中，形成处理链。

策略模式

策略模式（Strategy Pattern）属于对象的⾏为模式。其⽤意是针对⼀组算法，将每⼀个算法封装到具有共同接⼝的独⽴的类中，从⽽使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发⽣变化。其主要⽬的是通过定义相似的算法，替换 if else 语句写法，并且可以随时相互替换。

举例： Java.util.List 就是定义了⼀个增（ add ）、删（ remove ）、改（ set ）、查（ indexOf ）策略，⾄于实现这个策略的ArrayList 、LinkedList 等类，只是在具体实现时采⽤了不同的算法。但因为它们策略⼀样，不考虑速度的情况下，使⽤时完全可以互相替换使⽤。