Java设计模式中的反模式与性能陷阱

设计模式是Java开发中的利器，但错误的使用方式反而会导致代码质量下降甚至系统崩溃。本文将深入分析几种常见的反模式使用场景和性能陷阱，帮助开发者规避这些问题。

一、常见误用场景

1. 单例模式导致内存泄漏

问题现象：单例对象持有外部资源（如数据库连接）或大对象，导致无法被GC回收。

public class LeakySingleton {
    private static LeakySingleton instance;
    private List<BigObject> cache = new ArrayList<>(); // 持有大对象
    
    private LeakySingleton() {}
    
    public static LeakySingleton getInstance() {
        if (instance == null) {
            synchronized (LeakySingleton.class) {
                if (instance == null) {
                    instance = new LeakySingleton();
                }
            }
        }
        return instance;
    }
    
    public void addToCache(BigObject obj) {
        cache.add(obj); // 不断增长无法释放
    }
}

解决方案：

• 使用WeakReference持有资源
• 定期清理缓存
• 考虑改用依赖注入框架管理生命周期

public class SafeSingleton {
    private static SafeSingleton instance;
    private Map<Key, WeakReference<BigObject>> cache = new WeakHashMap<>();
    
    // ... 单例实现
    
    public void addToCache(Key key, BigObject obj) {
        cache.put(key, new WeakReference<>(obj));
    }
}

2. 过度使用工厂方法

问题现象：为每个简单对象创建工厂类，导致代码复杂度陡增。

// 反例：过度设计的工厂
public interface UserFactory {
    User createUser();
}

public class AdminUserFactory implements UserFactory {
    @Override public User createUser() { return new AdminUser(); }
}

public class GuestUserFactory implements UserFactory {
    @Override public User createUser() { return new GuestUser(); }
}

// 使用时需要维护大量工厂类

解决方案：

• 简单对象直接使用构造函数

• 只在以下场景使用工厂：

  • 对象创建过程复杂
  • 需要统一创建逻辑
  • 需要隐藏实现细节

// 正例：合理使用静态工厂方法
public class User {
    public static User createAdmin() {
        return new AdminUser();
    }
    
    public static User createGuest() {
        return new GuestUser();
    }
}

3. 观察者模式循环触发

问题现象：观察者A的通知触发观察者B，B又触发A，形成死循环。

sequenceDiagram
    participant A as ObserverA
    participant S as Subject
    participant B as ObserverB
    
    S->>A: 状态更新通知
    A->>S: 修改状态
    S->>B: 状态更新通知
    B->>S: 修改状态
    S->>A: 状态更新通知
    loop 死循环
        A->S->B->S...
    end

解决方案：

• 引入变更标记，避免重复通知
• 使用异步消息队列解耦
• 设置最大通知深度

public class SafeSubject {
    private List<Observer> observers = new ArrayList<>();
    private boolean notifying = false;
    
    public void notifyObservers() {
        if (notifying) return;
        
        try {
            notifying = true;
            for (Observer o : observers) {
                o.update(this);
            }
        } finally {
            notifying = false;
        }
    }
}

二、性能陷阱

1. 动态代理生成开销

性能数据：

优化建议：

• 缓存代理对象
• 对性能敏感路径避免使用代理
• 考虑使用编译时生成方案（如Java Annotation Processing）

// 代理对象缓存示例
public class ProxyCache {
    private static final Map<Class<?>, Object> proxyCache = new ConcurrentHashMap<>();
    
    public static <T> T getProxy(Class<T> interfaceType) {
        return (T) proxyCache.computeIfAbsent(interfaceType, 
            k -> Proxy.newProxyInstance(...));
    }
}

2. 享元模式对象池大小设置

错误配置：

• 池过小：频繁创建/销毁对象
• 池过大：内存浪费

最佳实践：

• 根据实际负载动态调整
• 使用JMH进行性能测试确定最优值
• 考虑使用成熟池化库（如Apache Commons Pool）

public class OptimalFlyweightPool {
    private static final int MIN_SIZE = Runtime.getRuntime().availableProcessors();
    private static final int MAX_SIZE = MIN_SIZE * 4;
    private LinkedBlockingQueue<Flyweight> pool = new LinkedBlockingQueue<>(MAX_SIZE);
    
    public Flyweight get() {
        Flyweight obj = pool.poll();
        return obj != null ? obj : createFlyweight();
    }
    
    public void release(Flyweight obj) {
        if (pool.size() < MAX_SIZE) {
            pool.offer(obj.reset());
        }
    }
}

三、实践建议

1. 模式选择原则：

   • 先验证必要性再应用模式
   • 保持简单优于复杂设计
   • 定期审查模式使用效果

2. 性能优化检查表：

   • [ ] 单例对象是否持有不必要的大对象
   • [ ] 工厂类是否真的简化了代码
   • [ ] 观察者是否可能形成循环
   • [ ] 代理创建开销是否可接受
   • [ ] 对象池大小是否经过测试验证

3. 监控指标：

   • 模式相关对象的创建频率
   • 内存中模式对象的数量
   • 模式相关方法的执行时间

记住：设计模式是工具而非目标，合理使用才能发挥最大价值。