聊到Java设计模式我见过太多人走两个极端。一种是面试前疯狂背概念结果工作三五年连策略模式和状态模式都分不清到底该用哪个另一种是觉得设计模式就是“过度设计”写业务代码时从不刻意用等代码膨胀到没人敢改的时候才后悔。我自己大概是在工作到第三年的时候才真正把设计模式这件事想明白。它不是什么高深理论也不是拿来应付面试的八股文而是前辈们把大量项目里的通用问题提炼成的一套“标准解法”。你提前知道这些解法写代码时就能少走弯路你在别人写的代码里认出这些模式就能很快读懂架构意图。这篇文章打算做一次系统性的梳理覆盖创建型、结构型、行为型三大类中Java开发最常碰到的十几个模式。每个模式我都会给出核心思想、可以直接落地的代码骨架以及实际项目里最典型的使用场景。不管你是准备面试、复习期末还是想在项目里开始有意识地运用设计模式这篇内容都会比纯看概念舒服很多。1. 先建立全局认知设计模式到底在解决什么问题在逐个看模式之前我强烈建议先把整体地图挂在脑子里。否则你看完二十多个模式唯一的感受就是“每个都见过每个都用不上”。1.1 设计模式本质上是一套“面向变化”的解法Gof那本经典书里有句被说烂的话找到变化封装变化。这句话才是一切设计模式的核心。代码里不变的部分好办难的是那些会变化的部分。设计模式做的就是两件事把会变的部分隔离出来让变化发生时不影响稳定部分。举个例子你写了一个消息推送服务原来的需求只支持短信。后来产品说还要支持邮件再过几个月又要支持App推送。如果代码里到处是if (type.equals(sms))这种判断每次加一个渠道都要把所有相关类改一遍。可如果你一开始就用策略模式或者工厂模式把“推送渠道”这个变化点封装起来那么新增渠道只需要增加一个实现类老代码一行都不用动。我在团队里带新人时经常说一句话写代码前先问自己这个模块里什么是稳定的什么是可能变的把可能变的用接口圈出来这就是设计模式发挥作用的第一步。1.2 六大原则所有设计模式背后的“裁判规则”学习设计模式离不开SOLID原则但很多人不知道的是这六个原则不仅是理论更是你判断“这个模式该不该用”的裁判。遇到不确定的情况回到原则上来问自己答案往往就清晰了。单一职责原则一个类只做一件事。这是最容易理解、也最容易被忽略的原则。开闭原则对扩展开放对修改关闭。这是所有设计模式的核心目标。里氏替换原则子类必须能替换父类并且行为不变。它约束的是继承的使用边界。接口隔离原则客户端不应该依赖它不需要的接口。用多个专门接口优于一个臃肿接口。依赖倒置原则依赖抽象不依赖具体实现。这是Spring IOC的底层哲学。迪米特法则又叫最少知识原则一个对象应该尽量少了解其他对象。这些原则和设计模式的关系有点类似于物理定律和工程机械的关系。物理定律给定了边界工程机械在边界内做最优解。设计模式就是在六大原则边界内经过验证的通用机械结构。1.3 三大分类和它们的分工Gof把23种模式按目的分成三类这个分类本身也有逻辑分类解决什么问题核心思想典型代表创建型对象的创建逻辑过于复杂或耦合把“创建”和使用解耦单例、工厂、建造者结构型类或对象组合后结构不灵活用组合/继承让结构更清晰代理、装饰器、适配器行为型对象协作时的职责分配不清晰把对象间的交互方式规范化策略、观察者、模板方法理解这个分类能帮你快速定位问题。当你发现代码里new对象到处都是优先考虑创建型当你的类之间继承关系混乱、改动牵一发动全身优先考虑结构型当你的业务流程里充满了复杂的条件分支、对象之间互相通知优先考虑行为型。2. 创建型模式怎么优雅地把对象“生”出来创建型模式是我觉得日常开发中用得最多、也最容易被滥用的类型。Java里new一个对象太简单了以至于很多人根本没想过“创建”这件事本身会带来麻烦。但当你遇到构造参数特别多、对象创建逻辑很重、或者创建过程要求全局唯一的时候问题就来了。2.1 单例模式别只会写懒汉式和饿汉式单例模式的意图是保证一个类全局只有一个实例并提供一个全局访问点。典型场景包括线程池、配置中心、数据库连接池等。但网上讲单例的代码五花八门面试时让人手写最能看出功底的是你对并发和序列化的理解。先看最基础的饿汉式。类加载时就创建实例写法简单线程安全缺点是即使没用到也会占用内存public class EagerSingleton { private static final EagerSingleton INSTANCE new EagerSingleton(); private EagerSingleton() {} public static EagerSingleton getInstance() { return INSTANCE; } }懒汉式是懒加载但直接加synchronized会导致每次获取实例都有性能损耗。所以业界更推荐双重检查锁DCL加volatilepublic class DclSingleton { private static volatile DclSingleton instance; private DclSingleton() {} public static DclSingleton getInstance() { if (instance null) { synchronized (DclSingleton.class) { if (instance null) { instance new DclSingleton(); } } } return instance; } }这里volatile是必须的因为new并不是原子操作它包含分配内存、初始化对象、设置引用三步。如果没有volatileJVM指令重排可能导致另一个线程拿到一个未初始化完成的对象。我个人的偏好是除非确实需要懒加载否则优先用枚举单例。Joshua Bloch在Effective Java里也推荐这种方式因为它天然线程安全、能防反射攻击和序列化破坏public enum EnumSingleton { INSTANCE; public void doSomething() { // 业务方法 } }注意枚举单例在大多数场景下都够用但它不能继承其他类枚举默认继承Enum如果遇到需要继承的场景就退回DCL方案。2.2 工厂模式简单工厂、工厂方法、抽象工厂怎么选工厂模式的核心是封装创建逻辑让调用方不直接依赖具体类。很多新手分不清三种工厂模式的区别我用自己的话梳理一下简单工厂一个工厂类里放一个静态方法通过参数返回不同产品。严格说它不是Gof定义的正式模式更像是一种编码习惯。工厂方法定义一个创建对象的接口让子类决定实例化哪个类。把“创建”这件事延迟到子类。抽象工厂围绕一个超级工厂创建其他工厂用来创建一组相关对象。实际业务里简单工厂是最实用的。比如你做一个支付渠道工厂根据支付方式返回对应的支付实现类public class PayFactory { public static PayService getPayService(String channel) { switch (channel) { case alipay: return new AlipayService(); case wechat: return new WechatPayService(); default: throw new IllegalArgumentException(不支持的支付渠道: channel); } } }但这里有个坑一旦渠道多了switch分支会越来越长。我处理这个问题的经验是把渠道名注册到Spring容器里用BeanName直接获取。Spring的IOC容器本身就承担了工厂的职责我们在项目里手动写工厂类时往往是在重复造轮子。正确姿势是先扫描容器里所有PayService类型的Bean用注解上的渠道标识做映射这样加新渠道真的可以零修改。2.3 建造者模式与原型模式复杂对象和对象拷贝的实用场景建造者模式解决的问题是当一个对象的构造参数特别多或者对象内部有复杂的组装过程时直接写构造函数会又长又容易传错。经典的例子是StringBuilder、Lombok的Builder注解。使用建造者模式的类通常长这样public class User { private String name; private int age; private String email; private String address; private User(Builder builder) { this.name builder.name; this.age builder.age; this.email builder.email; this.address builder.address; } public static class Builder { private String name; private int age; private String email; private String address; public Builder name(String name) { this.name name; return this; } public Builder age(int age) { this.age age; return this; } public Builder email(String email) { this.email email; return this; } public Builder address(String address) { this.address address; return this; } public User build() { return new User(this); } } }原型模式用clone()复制对象适合创建成本很高的对象。但Java的clone()浅拷贝是个巨坑。如果对象里有可变引用类型字段浅拷贝会让两个对象共享同一个内部对象改一个另一个也跟着变。所以实现Cloneable时必须谨慎必要时转为深拷贝先序列化再反序列化或者手动new一个新的内部对象复制字段。3. 结构型模式把类和对象组合得更漂亮结构型模式关注的是类和对象的组合方式。我自己的体会是结构型模式比创建型模式更容易理解因为它们更贴近“代码组织”这件事本身。你在重构代码、整理类关系的时候脑子里有这些模式思路会清晰很多。3.1 适配器模式接口不兼容时的“转接头”适配器模式就像手机充电器的转接头把一个接口转成客户端期望的另一个接口。我遇到过最典型的场景是接入第三方SDK。第三方的接口返回的数据结构和我们内部定义的不一致直接改业务代码到处都是这时候包一层适配器把第三方结构转成内部结构业务代码完全无感。实际写一个简洁版本// 目标接口 public interface NewInterface { void request(); } // 老接口 public class OldService { public void oldRequest() { System.out.println(老接口逻辑); } } // 适配器把老接口转成新接口 public class Adapter implements NewInterface { private OldService oldService; public Adapter(OldService oldService) { this.oldService oldService; } Override public void request() { oldService.oldRequest(); } }适配器模式的关键不是代码多复杂而是你要有“不直接改别人的代码而是包一层”的意识。这种意识在和老系统、第三方系统对接时能救你无数次。3.2 装饰器模式不修改原有类就增强功能装饰器模式最经典的应用就是Java的IO流。BufferedInputStream包装FileInputStream给原来的字节输入流增加了缓冲功能。它的思想是用一层一层包装来增强对象而不是靠继承去扩展。我一直觉得装饰器模式和代理模式在代码形态上很像都是从持有一个原始对象开始在方法调用前后加逻辑。区别在于意图代理模式强调的是控制访问装饰器模式强调的是增强功能。举一个实际例子你想给接口加一个耗时统计功能用装饰器包装就很干净public class TimingDecorator implements DataService { private final DataService delegate; public TimingDecorator(DataService delegate) { this.delegate delegate; } Override public String getData() { long start System.currentTimeMillis(); try { return delegate.getData(); } finally { System.out.println(耗时: (System.currentTimeMillis() - start) ms); } } }3.3 代理模式静态代理、JDK动态代理、CGLIB的取舍代理模式在Java生态里的地位不用多说Spring AOP底层就是动态代理。面试时被问到动态代理至少要把JDK动态代理和CGLIB的区别说清楚。JDK动态代理要求目标类实现接口它基于接口生成代理类。CGLIB不需要接口它通过继承目标类生成子类来实现代理。所以如果目标类没有实现接口就不能用JDK动态代理得用CGLIB。一个简单的JDK动态代理示例public class LogProxyHandler implements InvocationHandler { private final Object target; public LogProxyHandler(Object target) { this.target target; } Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { System.out.println(调用前); Object result method.invoke(target, args); System.out.println(调用后); return result; } public static T T createProxy(T target, ClassT interfaceType) { return (T) Proxy.newProxyInstance( target.getClass().getClassLoader(), new Class[]{interfaceType}, new LogProxyHandler(target)); } }实际项目中我们很少自己写动态代理而是直接用Spring的Aspect注解声明切面。但理解底层原理非常重要。我见过不少人在排查问题时搞不懂为什么Spring里一个Bean调自己的方法时事务注解不生效根源就在动态代理上。类内部的this调用不会经过代理对象所以Transactional注解会失效。这个问题几乎每个做Java后端的人都会遇到理解了JDK动态代理的机制解决起来就会非常轻松。4. 行为型模式把对象之间的交互理顺行为型模式关注对象之间的职责分配和通信方式。这组模式我认为最贴近真实业务因为它们处理的往往是“流程”本身。写业务代码时if else太多、流程不清晰、对象之间耦合严重都能从这组模式里找到答案。4.1 策略模式一堆if else的终结者策略模式几乎是业务开发中最值得掌握的一个模式。它的定义是把一组可互相替换的算法封装起来使它们可以独立于客户端变化。我在项目中见过很多这段代码if (discount.equals(type)) { // 折扣计算 } else if (fullReduction.equals(type)) { // 满减计算 } else if (gift.equals(type)) { // 赠品计算 }这种写法在活动类型少的时候还行一旦运营不断加新玩法方法体就变成了一个巨大的分支堆。用策略模式改造后定义策略接口public interface DiscountStrategy { BigDecimal calculate(BigDecimal amount); String getType(); }每种活动是一种策略Component public class DiscountStrategyImpl implements DiscountStrategy { Override public BigDecimal calculate(BigDecimal amount) { // 折扣逻辑 return amount.multiply(new BigDecimal(0.8)); } Override public String getType() { return discount; } }然后在Spring启动时把这些策略收集进Map类型作为key策略作为value。请求进来时直接从Map里拿没有匹配的就走默认策略。这样一来新增活动类型只需要新增一个类老代码完全不动。4.2 观察者模式事件驱动架构的根基观察者模式定义对象间一对多的依赖关系当一个对象状态改变时所有依赖它的对象都会收到通知。Spring的事件机制、消息队列的发布订阅模式底层思维都离不开它。Java原生的Observable类和Observer接口在新版本里已经废弃了更推荐自己定义事件和监听器或者直接用Spring的ApplicationEvent。实际开发里我用过一组电商订单状态流转的场景订单支付完成后需要发短信、发邮件、赠送积分、通知仓库备货。如果直接在支付成功的方法里挨个写调用代码就会很僵硬。改成事件发布// 发布事件 applicationEventPublisher.publishEvent(new OrderPaidEvent(order)); // 监听器 EventListener public void onOrderPaid(OrderPaidEvent event) { // 发短信 } EventListener public void onOrderPaid(OrderPaidEvent event) { // 赠送积分 }用观察者模式之后新增一个“支付后通知用户”的功能只加一个监听器类就行完全不碰原有代码。这种扩展性在业务快速变化的背景下极其重要。4.3 模板方法模式与责任链模式流程和审批场景的最佳选择模板方法模式的思想是把一个业务步骤的骨架定下来把其中某些步骤延迟到子类实现。比如数据迁移流程固定的步骤是“读取数据 - 转换数据 - 写入数据”。读取和写入的框架一样但每种数据源的转换逻辑不同这时候父类把转换步骤抽象出来子类自己去实现。这种模式是“继承”最值得使用的场景之一。责任链模式则适合审批流、日志过滤等场景。多个处理器串成一条链每个处理器决定是否处理、是否传给下一个。我处理过一个外部接口对接的案例同一个接口有多个渠道每个渠道的报文格式不同。传统写法是收到请求后在入口处写一堆if判断走哪个渠道的解析器。后来改成责任链模式每个渠道一个处理器处理器内部判断报文是否归自己处理处理不了就传给下一个。这样加渠道、改渠道逻辑互不影响代码维护起来省心太多。这里想多说一句责任链模式在Java世界里最经典的实现是Servlet的Filter链和Spring MVC的HandlerInterceptor。如果你用过Spring Security其实整个认证授权流程也是一条责任链。理解了模式再去读框架源码你会发现很多看不懂的机制一下子就能看通了。5. 从写得出到用得上日常项目里的落地经验理论说完我相信很多人还是会有同一个疑问道理都懂但项目里到底该不该用、什么时候用这一章我结合自己的项目经验聊聊怎么把设计模式真正落地。5.1 识别变化点是使用设计模式的第一步我不建议为了用模式而用模式。一个很简单的方法当你在写代码时连续加第二个if判断某个类型或某个条件时停下来想一想这里有可能会经常增加新分支吗如果答案是“会”那就该用策略模式或者工厂模式如果你不确定就先写正常的if等第三次改动出现时再去重构。设计模式不是越早用越好而是要在合适的时机出现。太早使用会增加代码复杂度让刚接手的人看不懂太晚使用会导致代码难以维护。我的经验是一个变化点至少出现两次才值得抽象。这个经验来自多次实践提前抽象设计往往猜不准未来的变化方向最后反而写出了过度设计。5.2 结合Spring Boot看设计模式的天然落地很多人在学Spring Boot时没有意识到框架本身大量运用了设计模式。文件上传用策略模式管理不同的存储方式、RestTemplate和JdbcTemplate使用模板方法模式封装固定流程、AOP使用动态代理、事件机制使用观察者模式。所以与其到处找设计模式的练习题不如多读一读Spring Boot相关的源码在你熟悉的框架里找模式的影子理解速度会快很多。我个人的学习路径是先看一个设计模式的定义然后去Spring源码里找对应的类最后自己写一个小Demo模拟。三个步骤走完这个模式基本上就忘不了。5.3 用UML类图辅助理解但别被UML劝退学习设计模式时很多人提到UML就头疼。我的建议是不用把UML学得很深只要能看懂类图中的几种基本关系就够了继承实线空心三角、实现虚线空心三角、组合实心菱形、聚合空心菱形、关联直线、依赖虚线箭头。看懂了这几种关系看设计模式的类图就跟看地图一样。更重要的是画类图能帮你审视自己的代码结构。我习惯在设计一个模块之前先在草稿纸上画一下类之间的关系画完基本就知道应该用什么模式了。6. 常见问题与避坑实录最后这部分我想分享一些实际踩过的坑。这些坑很多人都会遇到但很少写在教科书里。6.1 单例模式在Spring里其实不用手动写不少初学者在写Spring项目时还手动写单例模式其实这是多余的。Spring容器管理的Bean默认就是单例的。你在类上加了Component或者ServiceSpring容器默认只会创建一个实例。手动写单例可能会导致重复创建实例反而破坏了Spring容器的统一管理。6.2 动态代理 final类会直接报错如果你给一个final类配置了CGLIB代理启动时就会报错。CGLIB的原理是生成目标类的子类final类无法被继承。JDK动态代理则是基于接口。Spring在决定用哪种代理方式时会先看目标类有没有接口有则JDK代理没有则CGLIB。如果类既没有接口又是final启动时就会异常。解决方式一般是把类改成非final或者显式把代理方式改为强制的某一种。6.3 策略模式滥用会导致类爆炸策略模式很好用但不是所有if else都应该用策略模式。如果一个分支只出现一次且未来几乎不会扩展用策略模式反而割裂了代码。我曾经在一个项目里见过有人把所有校验逻辑拆成了十几个策略类每个类就三五行业务代码结果找一个校验规则要翻十几个文件。这就属于过度设计直接写if反而更清楚。判断的尺度和加抽象时一样变化点至少要出现两次才值得做策略化。6.4 观察者模式要注意监听器异常使用Spring事件机制时有几个点容易忽略。第一默认情况下监听器是同步执行的如果某个监听器抛异常发布事件的线程会中断影响主流程。要避免这种情况可以在监听器内部捕获所有异常或者使用Async把它变成异步。第二Async注解需要配合EnableAsync开启并且异步方法不能被同类其他方法调用否则代理失效异步就不会生效。6.5 面试时最常追问的几个设计模式问题把面试官常问的问题列一张速查表给大家复习时参考问题回答思路单例模式的线程安全怎么保证饿汉式天然安全DCLvolatile枚举方式JDK动态代理和CGLIB的区别JDK基于接口CGLIB基于继承目标类无接口用CGLIBSpring中哪个注解用到了代理模式AOP、Transactional、Async策略模式和状态模式的区别策略模式是客户端选择算法状态模式是状态驱动行为切换观察者模式和发布订阅的区别观察者是直接依赖发布订阅通过事件总线解耦能说说模板方法在哪用到吗JdbcTemplate、RestTemplate固定流程子类实现步骤7. 最后再分享一点我的个人体会写了这么多年Java我的感受是设计模式不是看会的是写会的。刚开始接触的时候你可能会觉得抽象、记不住、用不上。这都很正常。真正的转折点是你开始在一个真实项目里发现代码越来越难维护然后尝试用一个模式去重构改完发现世界清爽了——从那以后设计模式就不再是知识而是你的直觉了。建议你从今天开始挑一个快要失控的模块试着用这篇文章里讲到的思路去梳理一下找到变化点抽象接口用工厂或者策略把分支收拢。不用贪多一次只改一个模式。每走完一步你都会对设计模式多一分理解。这条路走起来比背十遍面试题都管用。