GoF是 “Gang of Four”（四人帮）的简称，它们是指4位著名的计算机科学家：Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides。他们合作编写了一本非常著名的关于设计模式的书籍《Design Patterns: Elements of Reusable Object-Oriented Software》（设计模式：可复用的面向对象软件元素）。这本书在软件开发领域具有里程碑式的地位，对面向对象设计产生了深远影响。

        GoF提出了23种设计模式，将它们分为三大类：
1、创建型模式（Creational Patterns）：这类模式主要关注对象的创建过程。它们分别是：

• 单例模式（Singleton）
• 工厂方法模式（Factory Method）
• 抽象工厂模式（Abstract Factory）
• 建造者模式（Builder）
• 原型模式（Prototype）

2、结构型模式（Structural Patterns）：这类模式主要关注类和对象之间的组合。分别是：

• 适配器模式（Adapter）
• 桥接模式（Bridge）
• 组合模式（Composite）
• 装饰模式（Decorator）
• 外观模式（Facade）
• 享元模式（Flyweight）
• 代理模式（Proxy）

3、行为型模式（Behavior Patterns）：这类模式主要关注对象之间的通信。它们分别是：

• 职责链模式（Chain of Responsibility）
• 命令模式（Command）
• 解释器模式（Interpreter）
• 迭代器模式（Iterator）
• 中介者模式（Mediator）
• 备忘录模式（Memento）
• 观察者模式（Observer）
• 状态模式（State）
• 策略模式（Strategy）
• 模板方法模式（Template Method）
• 访问者模式（Visitor）

        这些设计模式为面向对象软件设计提供了一套可复用的解决方案。掌握和理解这些模式有助于提高软件开发人员的编程技巧和设计能力。

一、单例设计模式

       单例设计模式（Singleton Design Pattern）理解起来非常简单。一个类只允许创建一个对象（或者实例），那这个类就是单例类，这种设计模式就叫单例设计模式，简称单例模式。

        1、为什么要使用单例

        1.1 表示全局唯一 
        如果有些数据在系统种应该且有只能保存一份，那就应该设计为单例类。如：
        配置类：在系统中，我们只有一个配置文件，当配置文件被加载到内存之后，应该被映射为一个唯一的【配置实例】，此时就可以使用单例，当然也可以不用。
        全局计数器：我们使用一个全局的计数器进行数据统计、生成全局递增ID等功能。若计数器不唯一，很有可能产生统计无效，ID重复等。

    public class GlobalCounter {private AtomicLong atomicLong = new AtomicLong(0);private static final GlobalCounter instance = new GlobalCounter();// 私有化无参构造器private GlobalCounter() {}public static GlobalCounter getInstance() {return instance;}public long getId() {return atomicLong.incrementAndGet();}}// 查看当前的统计数量long courrentNumber = GlobalCounter.getInstance().getId();

        以上代码也可以实现全局ID生成器的代码。

        1.2 处理资源访问冲突

        如果让我们设计一个日志输出的功能。如下：

    public class Logger {private String basePath = "D://info.log";private FileWriter writer;public Logger() {File file = new File(basePath);try {writer = new FileWriter(file, true); //true表示追加写入} catch (IOException e) {throw new RuntimeException(e);}}public void log(String message) {try {writer.write(message);} catch (IOException e) {throw new RuntimeException(e);}}public void setBasePath(String basePath) {this.basePath = basePath;}}

        我们可能会这样使用：

    @RestController("user")public class UserController {public Result login(){
// 登录成功Logger logger = new Logger();logger.log("tom logged in successfully.");
// ...return new Result();}}

        这样写会产生如下的问题：多个logger实例，在多个线程中，同时操作同一个文件。就可能产生相互覆盖的问题。因为tomcat处理每一个请求都会使用一个新的线程。此时日志文件就成了一个共享资源，但凡是多线程访问共享资源，我们都要考虑并发修改产生的问题。

        时间处理的方法有很多，其中之一就是可以加锁：

• 如果使用单个实例输出日志，锁【this】即可。
• 如果要保证JVM级别防止日志文件访问冲突，锁【class】即可。
• 如果要保证集群服务级别的防止日志文件访问冲突，加分布式锁即可。

        如果我们是一个简单工程，对日志输入要求不高。单例模式的解决思路就十分合适，既然同一个Logger无法并行输出到一个文件中，那么针对这个日志文件创建多个logger实例也就失去了意义，如果工程要求我们所有的日志输出到同一个日志文件中，这样其实并不需要创建大量的Logger实例，这样的好处有：

• 一方面节省内存空间。
• 另一方面节省系统文件句柄（对于操作系统来说，文件句柄也是一种资源，不能随便浪费）。

         按照这个设计思路，实现Logger单例类。具体代码如下所示：

    public class Logger {private String basePath = "D://log/";private static Logger instance = new Logger();private FileWriter writer;private Logger() {File file = new File(basePath);try {writer = new FileWriter(file, true); //true表示追加写入} catch (IOException e) {throw new RuntimeException(e);}}public static Logger getInstance(){return instance;}public void log(String message) {try {writer.write(message);} catch (IOException e) {throw new RuntimeException(e);}}public void setBasePath(String basePath) {this.basePath = basePath;}}

        除此之外，并发队列（比如Java中的BlockingQueue）也可以解决这个问题：多个线程同时往并发队列里写日志，一个单独的线程负责将并发队列中的数据写入到日志文件。这种方式实现起来也稍微有点复杂。当然，我们还可将其延申至消息队列处理分布式系统的日志。

       2、如何实现一个单例

        常见的单例设计模式，有如下五种写法，在编写单例代码的时候要注意以下几点：
        1）构造器需要私有化。
        2）暴露一个公共的获取单例对象的接口
        3）是否支持懒加载（延迟加载）
        4）是否线程安全

        2.1 饿汉式

        饿汉式的实现方式比较简单。在类加载的时候，在instance 静态实例就已经创建并初始化好了，所以，instance实例的创建过程是线程安全的。从名字中我们也可以看出这一点。具体的代码如下所示：

    public class EagerSingleton {private static Singleton instance = new Singleton();private Singleton (){}public static Singleton getInstance() {return instance;}}

        事实上，饿汉式的写法在工作上反而应该被提倡，面试中不问，只是因为它简单。很多人觉得饿汉式不能支持懒加载，即使不使用也会浪费资源，一方面是内存资源，一方面会增加初始化的开销。
        1、现代计算机不缺这一个对象的内存
        2、如果一个实例初始化的过程复杂那更加应该放在启动时处理，避免卡顿或者构造问题发生在运行时，满足fail-fast 的设计原则。

        2.2 懒汉式

        有饿汉式，对应的，就有懒汉式。懒汉式相对于饿汉式的优势是支持延迟加载，具体的代码实现如下所示：

    public class LazySingleton {private static Singleton instance;private Singleton (){}public static Singleton getInstance() {if (instance == null) {instance = new Singleton();}return instance;}}

        以上的写法本质上是有问题，当面对大量并发请求时，其实是无法保证其单例的特点的，很有可能会超过一个线程同时执行了 new Singleton();
        当然解决它的方案也很简单，加锁呗：

    public class Singleton {private static Singleton instance;private Singleton (){}public synchronized static Singleton getInstance() {if (instance == null) {instance = new Singleton();}return instance;}}

        以上的写法确实可以保证jvm中有且仅有一个单例实例存在，但是方法上加锁会极大的降低获取单例对象的并发度。同一时间只有一个线程可以获取单例对象，为了解决以上的方案就有第三种写法。

        2.3 双重检查锁

        饿汉式不支持延迟加载，懒汉式有性能问题，不支持高并发。那我们再来看一种既支持延迟加载、又支持高并发的单例实现方式，也就是双重检测实现方式：

        在这种实现方式中，只要instance被创建之后，即便再调用 getInstance() 函数也不会再进入到加锁逻辑中了。所以，这种实现方式解决了懒汉式并发度低的问题。具体的代码实现如下所示：

    public class DclSingleton {// volatile如果不加可能会出现半初始化的对象// 现在用的高版本的 Java 已经在 JDK 内部实现中解决了这个问题（解决的方法很简单，只要把对象 new 操作和初始化操作设计为原子操作，就自然能禁止重排序）,为了兼容性我们加上private volatile static Singleton singleton;private Singleton (){}public static Singleton getInstance() {if (singleton == null) {synchronized (Singleton.class) {if (singleton == null) {singleton = new Singleton();}}}return singleton;}}

        2.4 静态内部类

        我们再来看一种比双重检测更加简单的实现方法，那就是利用Java的静态内部类。它们有点类似饿汉式，但又能做到了延迟加载。代码实现：

    public class InnerSingleton {/** 私有化构造器 */private Singleton() {}/** 对外提供公共的访问方法 */public static Singleton getInstance() {return SingletonHolder.INSTANCE;}/** 写一个静态内部类，里面实例化外部类 */private static class SingletonHolder {private static final Singleton INSTANCE = new Singleton();}}

        SingletonHolder 是一个静态内部类，当外部为Singleton 被加载的时候，并不会创建SingletonHolder 实例对象。只有当调用 getInstance() 方法时，SingleHolder 才会被加载，这个时候才会创建 instance 。insance 唯一性、创建过程的线程安全性，都有jvm来保证。所以，这种实现方法既保证了线程安全，又能做到延迟加载。
        
        

        2.5 枚举

        最后介绍一种最简单的实现方式，基于枚举类型的单例实现。这种实现方式通过java枚举类型本身的特性，保证了实例创建的线程安全性和实例的唯一性。具体的代码如下所示：
        这是最简单的实现，因为枚举类中，每一额枚举项本身就是一个单例的：

    public enum EnumSingleton {INSTANCE；}

        更通用的写法如下：

    public class EnumSingleton {private Singleton(){}public static enum SingletonEnum {EnumSingleton;private EnumSingleton instance = null;private SingletonEnum(){instance = new Singleton();}public EnumSingleton getInstance(){return instance;}}}

        事实上我们还可以将单例项作为枚举的成员变量，我们的累加器可以这样编写：

    public enum GlobalCounter {INSTANCE;private AtomicLong atomicLong = new AtomicLong(0);public long getNumber() {return atomicLong.incrementAndGet();}}

        这种写法是Head-first 中推荐的写法，他除了可以和其他的方式一样实现单例，他还能有效的防止反射入侵。

        2.6 反射入侵

        事实上，想要阻止其他人构造实例仅仅私有化构造器还是不够的，因为我们还可以使用反射获取私有构造器进行构造，当然使用枚举的方式是可以解决这个问题的，对于其他的书写方案，我们通过下边的方式解决：

    public class Singleton {private volatile static Singleton singleton;private Singleton (){if(singleton != null)throw new RuntimeException("实例：【"+ this.getClass().getName() + "】已经存在，该实例只允许实例化一次");}public static Singleton getInstance() {if (singleton == null) {synchronized (Singleton.class) {if (singleton == null) {singleton = new Singleton();}}}return singleton;}}

        此时方法如下：

    @Testpublic void testReflect() throws NoSuchMethodException,InvocationTargetException, InstantiationException, IllegalAccessException {Class<DclSingleton> clazz = DclSingleton.class;Constructor<DclSingleton> constructor = clazz.getDeclaredConstructor();constructor.setAccessible(true);boolean flag = DclSingleton.getInstance() == constructor.newInstance();log.info("flag -> {}",flag);}

        结果如下：

        2.7 序列化与反序列化安全

        事实上，到目前为止，我们的单例依然是由漏洞的，看如下代码：

    @Testpublic void testSerialize() throws IllegalAccessException,NoSuchMethodException, IOException, ClassNotFoundException {// 获取单例并序列化Singleton singleton = Singleton.getInstance();FileOutputStream fout = new FileOutputStream("D://singleton.txt");ObjectOutputStream out = new ObjectOutputStream(fout);out.writeObject(singleton);// 将实例反序列化出来FileInputStream fin = new FileInputStream("D://singleton.txt");ObjectInputStream in = new ObjectInputStream(fin);Object o = in.readObject();log.info("他们是同一个实例吗？{}",o == singleton);}

        我们发现，即使我们废了九牛二虎之力还是没能阻止他返回false，结果如下：

         readResolve()方法可以用于替换从流中读取的对象，在进行反序列化时，会尝试执行readResolve()方法，并将返回值作为反序列化的结果，而不会克隆一个新的实例，保证jvm中仅仅有一个实例存在：

    public class Singleton implements Serializable {// 省略其他的内容public static Singleton getInstance() {}// 需要加这么一个方法public Object readResolve(){return singleton;}}

        3、源码应用 

        事实上、我们在JDK或者其他的通用框架中很少能看到标准的单例设计模式，这也就意味着他确实很经典，但严格的单例设计模式确实有它的问题和局限性，我们先看看在源码中的一些案例。

        3.1 jdk中的单例

        jdk中有一个类是一个标准单例模式 -> Runtime类，该类封装了运行时的环境，每个Java应用程序都有一个Runtime类实例，使应用程序能够与其运行的环境相连接。一般不能实例化一个Runtime 对象，应用程序也不能创建自己的Runtime 类实例。但可以通过getRuntime 方法获取当前Runtime 运行时对象的引用。

    public class Runtime {// 典型的饿汉式private static final Runtime currentRuntime = new Runtime();private static Version version;public static Runtime getRuntime() {return currentRuntime;}/** Don't let anyone else instantiate this class */private Runtime() {}public void exit(int status) {@SuppressWarnings("removal")SecurityManager security = System.getSecurityManager();if (security != null) {security.checkExit(status);}Shutdown.exit(status);}public Process exec(String command) throws IOException {return exec(command, null, null);}public native long freeMemory();public native long maxMemory();public native void gc();}

        测试用例：

    @Testpublic void testRunTime() throws IOException {Runtime runtime = Runtime.getRuntime();Process exec = runtime.exec("ping 127.0.0.1");InputStream inputStream = exec.getInputStream();byte[] buffer = new byte[1024];int len;while ((len = inputStream.read(buffer)) > 0 ){System.out.println(new String(buffer,0,len, Charset.forName("GBK")));}long maxMemory = runtime.maxMemory();log.info("maxMemory-->{}", maxMemory);}

       3.2 Mybatis 中的单例

        Mybatis 中的org.apache.ibatis.io.VFS  使用到了单例模式。VFS就是Virtual File System的意思，mybatis 通过VFS来查找指定路径下的资源。查看VFS一级它的实现类，不难发现，VFS的角色就是对更“底层”的查找指定资源的方法的封装，将复杂的“底层”操作封装到易于使用的高层模块中，方便使用者使用。

        省略了和单例无关的其他代码，并思考它使用了哪一种形式的单例：

    public class public abstract class VFS {// 使用了内部类private static class VFSHolder {static final VFS INSTANCE = createVFS();@SuppressWarnings("unchecked")static VFS createVFS() {
// ...省略创建过程return vfs;}}public static VFS getInstance() {return VFSHolder.INSTANCE;}}

    @Testpublic void testVfs() throws IOException {DefaultVFS defaultVFS = new DefaultVFS();
// 1、加载classpath下的文件List<String> list = defaultVFS.list("com/ydlclass");log.info("list --> {}" ,list);
// 2、加载jar包中的资源list = defaultVFS.list(new URL("file://D:/software/repository/com/mysql/mysqlconnector-j/8.0.32/mysql-connector-j-8.0.32.jar"),"com/mysql/cj/jdbc" );log.info("list --> {}" ,list);}

        4、单例存在的问题

        尽管单例是一个很经典的设计模式，但在实际的开发中，我们也很少按照严格的定义去使用它，以上的知识大多似乎为了理解个面试而使用和学习，有些人甚至认为单例是一种反模式（ant-pattern），压阵就不推荐使用。

        大部分情况下，我们在项目中使用单例，都是用它来表示一些全局唯一类，比如配置信息类、连接池类、ID生成器类。单例模式书写简洁、使用方便，在代码中，我们不需要创建对象。但是，这种使用方法有点类似硬编码（hard code）,会带来诸多问题，所以我们一般会使用spring的单例容器作为替代方案。那单例究竟存在哪些问题呢?

        4.1 无法支持面向对象编程

        OOP的三大特性是封装、继承、多态。单例将构造私有化，直接导致的结果就是无法成为其他类的父类，这就相当于直接放弃了继承和多态的特性，相当于损失了可以应对未来需求变化的扩展性，以后一旦有扩展需求，比如写一个类似的具有绝大部分相同功能的单例，我们不得不新建一个雷同的单例。

        4.2 极难的横向扩展

        单例类只能有一个对象实例。如果未来某一天，一个实例无法满足现在的需求，当需要创建多个实例时，就必须对源代码进行修改，无法友好的扩展。
        例如，在系统设计初期，我们觉得应该有一个数据库连接池，这样能方便我们控制对数据库连接资源的消耗，所以我们把数据库连接池类设置成了单例类。但之后我们发现，系统中有些sql运行得非常慢。这些sql语句在执行得时候，长时间占用数据库连接池连接资源，导致其他sql请求无法响应。为了解决这个问题，我们希望将慢sql与其他sql隔离开来执行。为了实现这样的目的，我们可以在系统中创建两个数据库连接池，慢sql独享一个数据库连接池，其他sql独享另外一个数据库连接池，这样就能避免慢sql影响到其他sql的执行。
        如果我们将数据库连接池设计成单例类，显然就无法适应这样的需求变更，也就是说，单例类在某些情况下会影响代码的扩展性、灵活性。所以，数据库连接池、线程池这类的资源池，最好还是不要设计成单例类。实际上，一些开源的数据库连接池、线程池也确实没有设计成单例类。

        5、不同作用范围的单例

        首先看一下单例的定义：“一个类只允许创建唯一一个对象（或者实例），那这个类就是一个单例类，这种设计模式就叫做单例设计模式，简称单例模式”。

        定义中提到，“一个类只允许创建唯一 一个对象”。那对象的唯一性的作用范围是什么呢？在标准的单例设计模式中，其单例是进程唯一的，也就意味着一个项目启动，在其整个运行环境中只能有一个实例。

        事实上，在实际的工作当中，我们能够看到极多（只有一个实例的情况），但是大多并不是标准的单例设计模式，如：
        1）使用ThreadLocal 实现的线程级别的单一实例
        2）使用spring实现的容器级别的单一是实例。
        3）使用分布式锁实现的集群状态的唯一实例。

        以上的情况都不是标准的单例设计模式，但我们可以将其看做单例设计模式的扩展，我们以前两种情况为例进行介绍。

        5.1 线程级别的单例

        刚才说了单例类对象是进程唯一的，一个进程只能有一个单例对象。如何实现一个线程唯一的单例呢?
        如果在不允许使用ThreadLocal 的时候我们可能想到如下的解决方案，定义一个全局的线程安全的ConcurrentHashMap，以线程id为key，以实例为value,每个线程的存取都从共享的map中进行操作，代码如下：

    public class Connection {private static final ConcurrentHashMap<Long, Connection> instances= new ConcurrentHashMap<>();private Connection() {}public static Connection getInstance() {Long currentThreadId = Thread.currentThread().getId();instances.putIfAbsent(currentThreadId, new Connection());return instances.get(currentThreadId);}}

        事实上ThreadLocal的原理也大致如此：
        项目中的ThreadLocal的使用场景：
        1）在spring使用ThreadLcoal对当前线程和一个连接资源进行绑定，实现事务管理：

    public abstract class TransactionSynchronizationManager {// 本地线程中保存了当前的连接资源，key(datasource)--> value(connection)private static final ThreadLocal<Map<Object, Object>> resources =new NamedThreadLocal<>("Transactional resources");// 保存了当前线程的事务同步器private static final ThreadLocal<Set<TransactionSynchronization>>synchronizations = new NamedThreadLocal<>("Transaction synchronizations");// 保存了当前线程的事务名称private static final ThreadLocal<String> currentTransactionName =new NamedThreadLocal<>("Current transaction name");// 保存了当前线程的事务是否只读private static final ThreadLocal<Boolean> currentTransactionReadOnly =new NamedThreadLocal<>("Current transaction read-only status");// 保存了当前线程的事务隔离级别private static final ThreadLocal<Integer> currentTransactionIsolationLevel =new NamedThreadLocal<>("Current transaction isolation level");// 保存了当前线程的事务的活跃状态private static final ThreadLocal<Boolean> actualTransactionActive =new NamedThreadLocal<>("Actual transaction active");}

        2）在spring中使用RequestContextHolder ，可以再一个线程中轻松的获取request、response和session。如果将我们在静态方法，切面中想获取一个request 对象就可以使用这个类。

    public abstract class RequestContextHolder {private static final ThreadLocal<RequestAttributes> requestAttributesHolder =new NamedThreadLocal("Request attributes");private static final ThreadLocal<RequestAttributes>inheritableRequestAttributesHolder = newNamedInheritableThreadLocal("Request context");@Nullablepublic static RequestAttributes getRequestAttributes() {RequestAttributes attributes =(RequestAttributes)requestAttributesHolder.get();if (attributes == null) {attributes = (RequestAttributes)inheritableRequestAttributesHolder.get();}return attributes;}}

        ServletRequestAttributes：

    public class ServletRequestAttributes extends AbstractRequestAttributes {public static final String DESTRUCTION_CALLBACK_NAME_PREFIX =ServletRequestAttributes.class.getName() + ".DESTRUCTION_CALLBACK.";protected static final Set<Class<?>> immutableValueTypes = new HashSet(16);private final HttpServletRequest request;@Nullableprivate HttpServletResponse response;@Nullableprivate volatile HttpSession session;private final Map<String, Object> sessionAttributesToUpdate;}

    public abstract class PageMethod {protected static final ThreadLocal<Page> LOCAL_PAGE = new ThreadLocal<Page>();protected static boolean DEFAULT_COUNT = true;}

    @Testpublic void testLogger(){Logger ydl = LoggerFactory.getLogger("ydl");Logger ydl2 = LoggerFactory.getLogger("ydl");Logger ydlclass = LoggerFactory.getLogger("ydlclass");log.info("ydl == ydl2 -->{}", ydl == ydl2);log.info("ydl == ydlclass --> {}", ydl == ydlclass);}

        我们发现，如果我们使用相同的名字，它会返回同一个实例，否则就是另一个实例，这其实就是一个多例，一个类可以创建多个对象，但是个数是有限制的，他可是是具体约定好的个数，比如5，也可以按照类型的个数创建。

        这种多例模式有点类似工厂模式。它跟工厂模式的不同之处是，多例模式创建的对象都是同一个类的对象，而工厂模式创建的是不同子类的对象。实际上，它还有点类似享元模式，两者的区别等到我们讲到享元模式的时候再来分析。除此之外，实际上，枚举类型也相当于多例模式，一个类型只能对应一个对象，一个类可以创建多个对象。

二、工厂设计模式

        一般情况下，工厂模式分为三种更加细分的类型：简单工厂、工厂方法和抽象工厂。
        在GoF的《设计模式》一书中，它将简单工厂模式看作是工厂方法模式的一种特例，所以工厂模式只被分成了工厂方法和抽象工厂两类。实际上，前面一种分类方法更加常见。
        在这三种细分的工厂模式中，简单工厂、工厂方法原理比较简单，在实际的项目中也比较常用。而抽象工厂的原理稍微复杂点，在实际的项目中相对也不常用。