深入 Spring 源码，剖析设计模式的落地实践

写在文章开头阅读源码是理解框架最有效的方式之一，Spring源码中蕴含了大量设计模式的经典应用。本文将从源码层面深入剖析这些设计模式，带你理解框架设计精髓，掌握在实际项目中灵活运用的能力。你好，我是SharkChili，Java Guide 核心维护者之一，对 Redis、Nightingale 等知名开源项目有深度源码研究经验。熟悉 Java、Go、C 等多语言技术栈，现任某知名黑厂高级开发工程师，专注于高并发系统架构设计与性能优化。🌟 开源项目贡献mini-redis：教学级 Redis 精简实现，助力分布式缓存原理学习🔗 https://github.com/shark-ctrl/mini-redis（欢迎 Star Contribute）📚 公众号价值分享企业级架构设计、性能优化、源码解析等核心技术干货，涵盖分布式系统、微服务治理、大数据处理等实战领域，并探索面向AI的vibe coding等现代开发范式。👥 加入技术社群关注公众号，回复【加群】获取联系方式，与众多技术爱好者交流分布式架构、微服务等前沿技术！设计模式的七大原则我们先来简单回顾一下设计模式的七大原则：1. 开闭原则对扩展开放，对修改关闭。即在不修改现有代码的前提下，通过扩展来增加新功能。反例：假如有一个图形绘制功能，最初只支持圆形，我们可能会这样写：publicclassGraphicEditor{publicvoiddrawShape(StringshapeType){if("circle".equals(shapeType)){System.out.println("绘制圆形");}elseif("rectangle".equals(shapeType)){System.out.println("绘制矩形");}}}这种方式每新增一种图形，都需要修改drawShape方法，违反了开闭原则。正例：使用接口抽象，遵循开闭原则：// 定义抽象接口publicinterfaceShape{voiddraw();}// 新增圆形，无需修改现有代码publicclassCircleimplementsShape{@Overridepublicvoiddraw(){System.out.println("绘制圆形");}}// 新增矩形，只需扩展，无需修改Shape接口或其他实现类publicclassRectangleimplementsShape{@Overridepublicvoiddraw(){System.out.println("绘制矩形");}}2. 里氏转换原则子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法，确保父类出现的地方子类都能正确替换。反例：将"鸟"作为父类，让会飞的企鹅也继承它：// 父类：鸟publicclassBird{publicvoidfly(){System.out.println("鸟在飞");}}// 企鹅不会飞，重写fly()抛异常，违反里氏转换publicclassPenguinextendsBird{@Overridepublicvoidfly(){thrownewUnsupportedOperationException("企鹅不会飞");}}// 使用时Birdbird=newPenguin();bird.fly();// 运行时抛出异常！这种方式的问题在于：企鹅 is-a 鸟，但企鹅不会飞，导致父类出现的地方子类无法正确替换。正例：引入更抽象的父类，正确建模：// 更抽象的父类：动物publicclassAnimal{}// 会飞的动物publicclassFlyingBirdextendsAnimal{publicvoidfly(){System.out.println("鸟在飞");}}// 麻雀继承会飞的鸟publicclassSparrowextendsFlyingBird{// 直接继承fly()方法}// 企鹅继承动物，但不会飞publicclassPenguinextendsAnimal{// 不会继承fly()方法}这样每个子类都能正确替换其父类，符合里氏转换原则。这种问题的根源在于：fly()方法并不适用于所有"鸟"子类。正确做法：当父类的方法在某些子类中不适用时，应该抽象出更细粒度的父类，让有共同行为的子类继承它，而不是强行让所有子类都继承父类所有方法。类图如下：Animal（抽象） / \ FlyingBird Penguin | Sparrow3. 依赖倒置原则高层模块不应该依赖底层模块，两者都应该依赖其抽象。其中"抽象"指接口或抽象类，"细节"指具体实现类。高层模块通常是业务逻辑层（如 UserService），底层模块是数据访问层（如 MySQLUserDao）。如下图，实现者MySQLUserDao依赖抽象接口UserDao限定自己的行为规范实现基于id的查询，高层UserService依赖抽象接口将接口实现类UserDao聚合，抽象不应依赖细节，细节应依赖抽象对应代码示例：// 错误：高层类直接依赖底层实现publicclassUserService{privateMySQLUserDaouserDao=newMySQLUserDao();// 直接依赖具体实现}// 正确：高层类依赖抽象接口publicclassUserService{privateUserDaouserDao;// 依赖抽象publicUserService(UserDaouserDao){this.userDao=userDao;// 通过构造器注入}}publicinterfaceUserDao{UserfindById(Longid);}// 底层实现依赖抽象publicclassMySQLUserDaoimplementsUserDao{@OverridepublicUserfindById(Longid){// MySQL 具体查询逻辑returnjdbcTemplate.queryForObject("SELECT * FROM user WHERE id = ?",id);}}4. 合成复用原则通过继承关系实现软件复用会使得子类被迫继承父类所有方法，即使不需要也要全部接受，可控性较差。尽量使用对象组合/聚合，按需实现委托代码：反例的问题：UserService extends LoggerService会让 UserService 被迫继承 LoggerService 的所有 public/protected 方法，即使 UserService 根本不需要这些功能。这会导致：类膨胀：继承了不需要的方法行为污染：客户端可能误调用不该暴露的方法// 日志接口publicinterfaceLogger{voidlog(Stringmessage);}// 日志实现类publicclassLoggerServiceimplementsLogger{@Overridepublicvoidlog(Stringmessage){System.out.println(message);}}// 错误：通过继承复用Logger功能publicclassUserServiceextendsLoggerService{publicvoiddoSomething(){log("操作日志");// 继承得到的方法}}// 正确：通过组合复用Logger功能publicclassUserService{privateLoggerlogger;// 组合publicUserService(Loggerlogger){this.logger=logger;}publicvoiddoSomething(){logger.log("操作日志");}}5. 单一职责原则一个类应该只有一个引起它变化的原因，即一个类只负责一项职责。// 错误：一个类承担多个职责publicclassUserManager{publicvoidaddUser(Useruser){/* 用户管理 */}publicvoidsendEmail(Stringmsg){/* 邮件发送 */}publicvoidgenerateReport(){/* 报表生成 */}}// 正确：职责分离publicclassUserManager{publicvoidaddUser(Useruser){/* 仅用户管理 */}}publicclassEmailService{publicvoidsendEmail(Stringmsg){/* 仅邮件发送 */}}publicclassReportService{publicvoidgenerateReport(){/* 仅报表生成 */}}6. 接口隔离原则用多个专门的接口，而不是单一的总接口，客户端不应该依赖它不需要的接口。// 错误：一个臃肿的总接口publicinterfaceIAnimal{voideat();voidfly();voidswim();}// 正确：接口隔离，按能力拆分publicinterfaceIEat{voideat();}publicinterfaceIFly{voidfly();}publicinterfaceISwim{voidswim();}// 狗只会吃和游泳publicclassDogimplementsIEat,ISwim{@Overridepublicvoideat(){}@Overridepublicvoidswim(){}}// 鸟会吃和飞publicclassBirdimplementsIEat,IFly{@Overridepublicvoideat(){}@Overridepublicvoidfly(){}}7. 迪米特法则最少知道原则，一个类应该尽可能减少对其他类的了解，只与直接的朋友（成员变量、方法参数、方法返回值）通信// 错误：Teacher直接访问Student的Course内部细节publicclassTeacher{publicvoidcheckCourse(Studentstudent){ListCoursecourses=student.getCourses();// 知道了Student内部有Course列表for(Coursecourse:courses){System.out.println(course.getName());}}}// 正确：Teacher只与Student交互，不关心其内部细节publicclassTeacher{publicvoidcheckCourse(Studentstudent){student.showCourseInfo();// 让Student自己暴露需要的信息}}publicclassStudent{privateListCoursecourses;publicvoidshowCourseInfo(){for(Coursecourse:courses){System.out.println(course.getName());}}}设计模式分类概览创建型模式创建型模式主要用于创建对象，对应的设计模式有：1. 单例模式确保类有且只有一个对象被创建，全局单例。DCL双重锁校验模式（JDK 1.5前主流写法，现已过时）：publicclassSingleton{privatestaticvolatileSingletoninstance;privateSingleton(){}publicstaticSingletongetInstance(){if(instance==null){synchronized(Singleton.class){if(instance==null){instance=newSingleton();}}}returninstance;}}DCL在JDK 1.5之后才真正安全有效，之前因instance = new Singleton()指令重排存在漏洞。主流推荐：通过JVM类加载机制安全发布// 饿汉式：类加载时立即初始化，JVM保证线程安全publicclassSingleton{privatestaticfinalSingletonINSTANCE=newSingleton();privateSingleton(){}publicstaticSingletongetInstance(){returnINSTANCE;}}// Holder模式：延迟加载 + JVM线程安全（推荐）publicclassSingleton{privateSingleton(){}privatestaticclassHolder{privatestaticfinalSingletonINSTANCE=newSingleton();}publicstaticSingletongetInstance(){returnHolder.INSTANCE;}}// 枚举单例：最简洁安全，JVM天然保证唯一性（最佳实践）publicenumSingleton{INSTANCE;publicvoiddoSomething(){}}