共计 1602 个字符，预计需要花费 5 分钟才能阅读完成。
面试官 ： 我看你的简历写着相熟常见的设计模式，要不你来简略聊聊你相熟哪几个吧？
候选者：常见的工厂模式、代理模式、模板办法模式、责任链模式、单例模式、包装设计模式、策略模式等都是有所理解的
候选者：我的项目手写代码用得比拟多的，个别就模板办法模式、责任链模式、策略模式、单例模式吧
候选者：像工厂模式、代理模式这种，手写倒是不多，但毕竟 Java 后端个别环境下都用 Spring 嘛，所以还是比拟相熟的。
面试官 ： 要不你来手写下单例模式呗？
候选者：单例模式个别会有好几种写法
候选者：饿汉式、简略懒汉式（在办法申明时加锁）、DCL 双重测验加锁（进阶懒汉式）、动态外部类（优雅懒汉式）、枚举
候选者：所谓「饿汉式」指的就是还没被用到，就间接初始化了对象。所谓「懒汉式」指的就是等用到的时候，才进行初始化
候选者：那我就都写写吧，反正就那些代码
面试官：那你们用的哪种比拟多？
候选者：个别咱们我的项目里用动态外部类的形式实现单例会比拟多（如果没有 Spring 的环境下），代码简洁易读
候选者：如果有 Spring 环境，那还是间接交由 Spring 容器治理会比拟不便（Spring 默认就是单例的）
候选者：枚举个别咱们就用它来做「标识」吧，而 DCL 这种形式也有同学会在我的项目里写（在一些源码里也能看到其身影），但总体太不利于浏览和了解（：
候选者：总的来说，用哪一种都能够的，要害我感觉要看团队的代码格调吧（保持一致就行），即使都用「饿汉式」也没啥大的问题（当初内存也没那么稀缺，我认为可读性比拟重要）
面试官：嗯…
面试官 ： 我看你在 DCL 的单例代码上，写了 volatile 润饰嘛？为什么呢？
候选者：你不记得咱们已经聊过 volatile 的了嘛？指令是有可能乱序执行的（编译器优化导致乱序、CPU 缓存架构导致乱序、CPU 原生重排导致乱序）
候选者：在代码 new Object 的时候，不是一条原子的指令，它会由几个步骤组成，在这过程中，就可能会产生指令重排的问题，而 volatile 这个关键字就能够防止指令重排的产生。
面试官 ： 那你说下你在我的项目里用到的设计模式吧？
候选者：嗯，比如说，我这边在解决申请的时候，会用到责任链模式进行解决（减免 if else 并且让我的项目构造更加清晰）
候选者：在解决公共逻辑时，会应用模板办法模式进行形象，具体不同的逻辑会由不同的实现类解决（每种音讯发送前都须要通过文案校验，所以能够把文案校验的逻辑写在抽象类上）
候选者：代理模式手写的机会比拟少（因为我的项目个别有 Spring 环境，间接用 Spring 的 AOP 代理就好了）
候选者：我之前应用过 AOP 把「监控客户端」封装以「注解」的形式进行应用（不用以硬编码的形式来进行监控，只有有注解就行了）
面试官 ： 那你能聊聊 Spring 常见的设计模式嘛？
候选者：比方，Spring IOC 容器能够了解为利用了「工厂模式」（通过 ApplicationContext 或者 BeanFactory 去获取对象）
候选者：Spring 的对象默认都是单例的，所以必定是用了「单例模式」（源码里对单例的实现是用的 DCL 来实现单例）
候选者：Spring AOP 的底层原理就是用了「代理模式」，实现可能是 JDK 动静代理，也可能是 CGLIB 动静代理
候选者：Spring 有很多中央都用了「模板办法模式」，比方事务管理器（AbstractPlatformTransactionManager），getTransaction 定义了框架，其中很多都由子类实现
候选者：Spring 的事件驱动模型用了「观察者模式」，具体实现就是 ApplicationContextEvent、ApplicationListener
面试官：嗯，理解…
欢送关注我的微信公众号【Java3y】来聊聊 Java 面试，对线面试官系列继续更新中！
【对线面试官 - 挪动端】系列 一周两篇继续更新中！
【对线面试官 - 电脑端】系列 一周两篇继续更新中！
原创不易！！求三连！！
