单例模式中饿汉式线程安全但可能浪费资源，懒汉式需双重检查锁+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。一旦开始支持深色模式、无障碍组件，抽象工厂结构更容易扩展。
- 别为了模式而模式。如果只有两个实现且长期稳定，直接用策略模式 +
Map<string strategy></string>更轻量 - Spring 的
BeanFactory是抽象工厂的典型应用，但你写的业务工厂类不需要继承FactoryBean，除非要干预 Bean 实例化过程 - 工厂类里别做复杂逻辑（比如读配置、连 DB），应只负责“new”和参数组装；重活交给 Builder 或 Service
观察者模式：Java 内置 Observer 已废弃，现在怎么写
java.util.Observer 和 Observable 在 JDK 9 就标记为 @Deprecated，因为设计僵硬：被观察者必须继承 Observable，无法组合复用，且通知顺序不可控、异常会中断后续监听。
现代写法是自定义接口 + 显式注册管理，核心是解耦和可控性：
public interface EventListener<T> {
void onEvent(T event);
}
public class EventBus {
private final Map<Class<?>, List<EventListener<?>>> listeners = new ConcurrentHashMap<>();
public <T> void register(Class<T> eventType, EventListener<T> listener) {
listeners.computeIfAbsent(eventType, k -> new CopyOnWriteArrayList<>()).add(listener);
}
public <T> void post(T event) {
List<EventListener<?>> list = listeners.get(event.getClass());
if (list != null) {
list.forEach(l -> ((EventListener<T>) 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 判断，硬套策略模式反而让代码更绕。真正该花时间的，是识别出那些未来大概率会变、且变化方向明确的点，再决定引入哪层抽象。
