设计模式是基于面向对象原则的可复用结构，非Java语法特性；其实现依赖interface、abstract class等机制；写错修饰符或初始化时机将导致模式失效。
Java 中设计模式不是语法特性，而是基于面向对象原则（封装、继承、多态、抽象）的可复用结构。它没有专属“语法”，但实现依赖 interface、abstract class、final、private 构造器、静态内部类等语言机制。写错访问修饰符或初始化时机，模式就失效。
单例模式：为什么双重检查锁要加 volatile
不加 volatile 会导致指令重排序，其他线程可能看到未初始化完成的实例。JDK 1.5+ 才保证 volatile 的禁止重排序语义。
-
instance字段必须用volatile修饰 - 两次
if (instance == null)缺一不可：第一次避免同步开销，第二次防止重复初始化 - 构造器必须是
private，否则可通过new绕过控制
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;
}
}
工厂模式：简单工厂 vs 工厂方法 vs 抽象工厂的区别在哪
关键不在“怎么写”，而在“谁负责扩展”。简单工厂把所有创建逻辑集中在一个类里，违反开闭原则；工厂方法用子类决定实例类型；抽象工厂则管理**一族相关对象**的创建。
- 简单工厂：用
static方法 +if-else或switch，适合产品种类少且稳定 - 工厂方法：定义
createProduct()抽象方法，由子类实现，新增产品只需加子类 - 抽象工厂：定义多个创建方法（如
createButton()、createCheckbox()），适用于跨平台 UI 组件等场景
观察者模式：Java 9 之后为什么不再推荐用 java.util.Observable
因为 Observable 是类而非接口，强制继承，破坏组合优先原则；且其 setChanged() 和 notifyObservers() 非原子，线程不安全；JDK 官方已标记为 @Deprecated。
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
立即学习“Java免费学习笔记（深入）”；
- 推荐用
java.util.Observer接口配合自定义事件分发器，或直接使用java.util.concurrent.CopyOnWriteArrayList存储观察者 - 通知逻辑应避免在持有锁时调用观察者回调，防止阻塞和死锁
- 注意内存泄漏：观察者若持有对被观察者的强引用，且未显式注销，GC 无法回收
代理模式：动态代理的 InvocationHandler 怎么避免无限递归
在 invoke() 中调用 proxy 对象的任意方法，都会再次进入 invoke()，形成死循环。常见于日志、权限校验等切面逻辑中误代理了 toString()、hashCode() 等基础方法。
- 务必判断
method.getName()，对Object自带方法（如"toString"、"equals"、"hashCode"）直接委托给目标对象或返回默认值 - 不要在
invoke()中再次调用proxy的同名方法 - JDK 动态代理只能代理接口，CGLIB 可代理类，但需注意
final类/方法无法被增强
public class LoggingHandler implements InvocationHandler {
private final Object target;
public LoggingHandler(Object target) { this.target = target; }
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
if (method.getDeclaringClass() == Object.class) {
return method.invoke(target, args); // 直接调用，不代理
}
System.out.println("Before " + method.getName());
Object result = method.invoke(target, args);
System.out.println("After " + method.getName());
return result;
}
}
真正难的不是写出某个模式的代码，而是判断当前问题是否真需要该模式——比如用策略模式解决 if-else，前提是策略行为确实会频繁增删或运行时切换；否则只是过度设计。很多“模式失效”，本质是没想清楚职责边界和变化点。
