Java面试——常见的设计模式及其实战应用

单例模式中饿汉式线程安全但可能浪费资源，懒汉式需双重检查锁+volatile防止重排序；工厂模式按复杂度递进选择，观察者模式应弃用Java内置类而用自定义事件总线。

单例模式：饿汉式 vs 懒汉式，线程安全怎么选

单例不是写个 static final 就完事。饿汉式在类加载时就初始化实例，天然线程安全，但可能浪费资源；懒汉式延迟加载，但不加同步会出问题——new Singleton() 不是原子操作，可能返回半初始化对象。

推荐用双重检查锁（DCL），但必须给实例字段加 volatile，否则 JVM 指令重排序会导致其他线程看到未构造完成的对象：

public class Singleton {
    private static volatile Singleton instance;
    private Singleton() {}
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton(); // volatile 禁止此处重排序
                }
            }
        }
        return instance;
    }
}

• 别用 Runtime.getRuntime() 或 System.getSecurityManager() 这类“伪单例”，它们不是你控制的生命周期
• Spring 的 @Scope("singleton") 是容器级单例，和 JVM 级单例不是一回事，别混为一谈
• 测试时如果单例依赖了外部状态（如数据库连接），记得在 @AfterEach 清理或用 reset() 方法，否则测试间会污染

工厂模式：简单工厂、工厂方法、抽象工厂，什么时候该升级

简单工厂（一个静态方法返回不同子类）适合产品种类少、不常变的场景，比如日志类型：LoggerFactory.getLogger("file")。但它违反开闭原则——新增日志类型就得改工厂类。

工厂方法把创建逻辑下放到子类，比如 PaymentService 接口有 createProcessor()，支付宝实现返回 AlipayProcessor，微信实现返回 WechatProcessor。这样新增支付渠道只需加新子类，不用动原有代码。

立即学习“Java免费学习笔记（深入）”；

抽象工厂用于“产品族”场景，比如跨平台 UI 组件：Windows 工厂返回 WinButton + WinCheckbox，Mac 工厂返回 MacButton + MacCheckbox。一旦开始支持深色模式、无障碍组件，抽象工厂结构更容易扩展。

Shoping购物网源码

该系统采用多层模式开发，这个网站主要展示女装的经营，更易于网站的扩展和后期的维护，同时也根据常用的SQL注入手段做出相应的防御以提高网站的安全性，本网站实现了购物车,产品订单管理，产品展示，等等，后台实现了动态权限的管理，客户管理，订单管理以及商品管理等等，前台页面设计精致，后台便于操作等。实现了无限子类的添加，实现了动态权限的管理，支持一下一个人做的辛苦

下载

• 别为了模式而模式。如果只有两个实现且长期稳定，直接用策略模式 + Map 更轻量
• Spring 的 BeanFactory 是抽象工厂的典型应用，但你写的业务工厂类不需要继承 FactoryBean，除非要干预 Bean 实例化过程
• 工厂类里别做复杂逻辑（比如读配置、连 DB），应只负责“new”和参数组装；重活交给 Builder 或 Service

观察者模式：Java 内置 Observer 已废弃，现在怎么写

java.util.Observer 和 Observable 在 JDK 9 就标记为 @Deprecated，因为设计僵硬：被观察者必须继承 Observable，无法组合复用，且通知顺序不可控、异常会中断后续监听。

现代写法是自定义接口 + 显式注册管理，核心是解耦和可控性：

public interface EventListener {
    void onEvent(T event);
}
public class EventBus {
    private final Map, List>> listeners = new ConcurrentHashMap<>();
    public  void register(Class eventType, EventListener listener) {
        listeners.computeIfAbsent(eventType, k -> new CopyOnWriteArrayList<>()).add(listener);
    }
    public  void post(T event) {
        List> list = listeners.get(event.getClass());
        if (list != null) {
            list.forEach(l -> ((EventListener) l).onEvent(event));
        }
    }
}

• 别用 ArrayList 存监听器列表——并发修改会抛 ConcurrentModificationException，CopyOnWriteArrayList 更稳妥
• 事件对象建议用不可变类（final 字段 + 无 setter），避免监听器中途篡改影响其他监听器
• 如果事件需要异步处理（如发短信、写日志），别在 post() 里直接线程池提交，应由监听器自己决定同步/异步，否则难以测试和调试

装饰器模式：IO 流是经典，但 Spring AOP 其实也是它

BufferedInputStream 包一层 FileInputStream，GZIPInputStream 再包一层，这就是装饰器：不改变原始对象，通过组合动态添加行为。关键点是装饰器和被装饰对象实现同一接口（InputStream）。

Spring 的 @Transactional、@Cacheable 表面看是代理，底层本质也是装饰器思想——生成一个代理对象，在调用目标方法前后插入事务开启/提交、缓存读写等逻辑，而业务 Service 类完全 unaware。

• 装饰器类名别叫 XXXDecorator，容易和 GUI 装饰混淆；用 Buffering、Retrying、Logging 这类动名词更直观
• 避免嵌套过深。三层以上装饰（如 Logging(Retrying(Buffering(FileInputStream)))）会让堆栈难读、性能下降，可考虑用 Builder 组装或配置化开关
• 如果装饰逻辑涉及状态（如重试次数、缓冲区大小），确保每个装饰器实例是独立的，别用 static 变量共享状态，否则多线程下会串数据

模式本身不难，难的是判断“这里到底需不需要模式”。过度设计比不用模式更危险——比如一个只有两个分支的 if 判断，硬套策略模式反而让代码更绕。真正该花时间的，是识别出那些未来大概率会变、且变化方向明确的点，再决定引入哪层抽象。