Java设计模式核心概念与常见模式

P粉602998670 2026-01-09 00:00:00 次阅读

Java设计模式是应对对象职责划分、依赖变化等共性问题的可复用结构方案，非语法糖或强制模板；误用比不用更危险，需结合Java运行机制（如ClassLoader、final限制、JVM内存模型）审慎落地。

Java设计模式不是语法糖，也不是必须套用的模板；它是在长期面对**对象职责划分、依赖变化、行为扩展**等共性问题时沉淀下来的**可复用结构方案**。用错模式比不用更危险——比如在单线程简单工具类里硬套 Observer，反而让逻辑变晦涩。

为什么不能直接照搬 UML 类图写代码？

UML 图描述的是理想协作关系，但 Java 实际运行受制于：final 字段初始化时机、ClassLoader 可见性、子类重写对 template method 流程的破坏。例如 AbstractFactory 模式中，若具体工厂类被不同 ClassLoader 加载，即使类名相同，instanceof 也会返回 false。

画图时假设“所有类都可自由继承”，但生产代码常有 final class 或 private 构造器（如 java.time.LocalDate）
Strategy 接口若定义了默认方法，JDK 8+ 才能编译通过，老项目可能卡在接口升级上
Proxy 模式用 java.lang.reflect.Proxy 时，目标类必须实现接口；想代理普通类得切到 CGLIB，但会触发 net.sf.cglib.core.CodeGenerationException

`Singleton` 的双重检查锁为什么需要 `volatile`？

不加 volatile 时，JVM 可能将 new Singleton() 拆成三步：分配内存 → 初始化对象 → 将引用赋值给静态变量。线程 A 执行到第三步前被调度，线程 B 看到非 null 引用但对象尚未初始化，调用方法会触发 NullPointerException 或未定义行为。

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(); // 这行必须保证原子可见
                }
            }
        }
        return instance;
    }
}