static final 指向可变集合的设计模式

核心矛盾 ：static final 只锁引用、不锁内容------当一个 List 被声明为 static final，仍然可以往里面增删元素。那当需要一个内容可修改的全局列表（配置中心、缓存、动态注册表......），又希望控制修改风险时，该怎么设计？

本文给出 5 种递进式设计方案，从"最小暴露"到"完全封装"，按场景选型。

方案一：外部只读 + 受控修改

思路：底层列表 private 隐藏，对外暴露不可变视图，修改只能走专门的静态方法。

java 复制代码

public class Config {

    // ① 底层可变列表------private 隐藏，外部看不到
    private static final List<String> NAMES = new ArrayList<>();

    // ② 对外暴露不可修改视图------读可以，写不行
    public static final List<String> NAMES_VIEW =
            Collections.unmodifiableList(NAMES);

    // ③ 受控修改入口------可加校验、日志、并发控制
    public static void addName(String name) {
        Objects.requireNonNull(name, "name 不能为 null");
        NAMES.add(name);
    }

    public static boolean removeName(String name) {
        return NAMES.remove(name);
    }

    // ④ 批量替换（如有需要）
    public static void replaceAll(List<String> newNames) {
        NAMES.clear();
        NAMES.addAll(newNames);
    }
}

维度	说明
封装性	底层集合不可达，外部无法绕过修改方法
可扩展	修改方法内可随意添加校验、事件通知、线程同步
可读性	`NAMES_VIEW` 一看就知道是只读的
零误用	编译期就能阻止 `NAMES_VIEW.add(...)`

注意事项：Collections.unmodifiableList() 返回的是视图，不是副本------底层列表变了，视图也跟着变。如果需要快照语义，要用防御性复制（见方案四）。

方案二：线程安全集合------简单粗暴但安全

如果允许任何代码随意增删，至少要保证并发安全。

2a. `synchronizedList`------通用方案

java 复制代码

public static final List<String> NAMES =
        Collections.synchronizedList(new ArrayList<>());

遍历仍需手动加锁 ：synchronizedList 只保证单次操作原子性，遍历必须自己加锁：
java 复制代码
synchronized (NAMES) {
 for (String name : NAMES) {
     // ...
 }
}

2b. `CopyOnWriteArrayList`------读多写少场景

java 复制代码

public static final List<String> NAMES = new CopyOnWriteArrayList<>();

特性	`synchronizedList`	`CopyOnWriteArrayList`
读性能	加锁，中等	无锁，极快
写性能	加锁，较快	每次写都复制数组，慢
遍历安全	需手动加锁	迭代器使用快照，天然安全
适用场景	读写均衡	读远多于写

什么时候选方案二？

团队规模小，调用方可信
不需要修改时的附加逻辑（校验、通知等）
只需要"不崩"而非"不被乱改"

方案三：包内可改、包外只读------访问控制的艺术

利用 Java 的访问修饰符，把修改权限限制在同一个包内。

java 复制代码

// 包级私有------同包可访问，包外不可见
static final List<String> _NAMES = new ArrayList<>();

// 公共只读视图------所有人都能读
public static final List<String> NAMES =
        Collections.unmodifiableList(_NAMES);

// 包级私有的修改方法------只有同包的"内部人"能调用
static void registerName(String name) {
    _NAMES.add(name);
}

设计意图

复制代码

┌── com.myapp.config ──────────────────┐
│                                      │
│   _NAMES (可变)  ←── 包内代码自由读写  │
│       │                              │
│       ▼                              │
│   NAMES (只读视图) ←── 包外代码只能读  │
│                                      │
└──────────────────────────────────────┘

适用场景

模块化设计中，API 模块 对外暴露只读视图，内部实现模块负责维护
SPI/插件机制中，核心包注册实现，外部只能查询
不想写单例管理类，但又想有基本的访问控制

方案四：防御性复制------只通过"整体替换"修改

不提供元素级操作，要求调用者传入整个新集合来更新，内部做防御性复制。

java 复制代码

public class AppConfig {

    private static final List<String> NAMES = new ArrayList<>();

    // 返回不可变视图
    public static List<String> getNames() {
        return Collections.unmodifiableList(NAMES);
    }

    // 整体替换------不接受元素级操作
    public static void setNames(List<String> newNames) {
        Objects.requireNonNull(newNames);
        NAMES.clear();
        NAMES.addAll(newNames);
    }
}

对比方案一

维度	方案一（受控修改）	方案四（防御性复制）
修改粒度	元素级（add/remove）	集合级（整体替换）
语义清晰度	多次小修改，状态难追踪	一次替换，状态明确
并发友好度	需要额外同步	替换操作更易做原子控制
适用场景	动态增删注册项	配置热加载、缓存刷新

如果需要真正的快照语义 ，getNames() 可以返回 new ArrayList<>(NAMES) 而非不可变视图------调用者拿到的是独立副本，后续修改互不影响。

方案五：注册中心模式------完全面向对象

当全局变量需要复杂的操作逻辑（校验、事件通知、依赖管理、持久化......），把它封装成专门的管理类。

java 复制代码

public class NameRegistry {

    private static final NameRegistry INSTANCE = new NameRegistry();

    private final List<String> names = new ArrayList<>();
    private final List<Consumer<String>> listeners = new CopyOnWriteArrayList<>();

    private NameRegistry() {}

    public static NameRegistry getInstance() {
        return INSTANCE;
    }

    // ── 核心操作 ──────────────────────────

    public void add(String name) {
        Objects.requireNonNull(name);
        if (names.contains(name)) {
            throw new IllegalArgumentException("名称已存在: " + name);
        }
        names.add(name);
        // 通知监听器
        listeners.forEach(l -> l.accept(name));
    }

    public boolean remove(String name) {
        boolean removed = names.remove(name);
        if (removed) {
            // 可扩展：移除通知、级联清理......
        }
        return removed;
    }

    // ── 查询 ──────────────────────────────

    public List<String> getNames() {
        return Collections.unmodifiableList(names);
    }

    public Optional<String> find(String keyword) {
        return names.stream()
                    .filter(n -> n.contains(keyword))
                    .findFirst();
    }

    // ── 事件订阅 ──────────────────────────

    public void onAdded(Consumer<String> listener) {
        listeners.add(listener);
    }
}

使用方式

java 复制代码

// 注册
NameRegistry.getInstance().add("service-A");

// 查询
List<String> all = NameRegistry.getInstance().getNames();

// 订阅变更事件
NameRegistry.getInstance().onAdded(name ->
    System.out.println("新注册: " + name));

什么时候值得上方案五？

修改时需要复杂业务逻辑（校验规则、事件广播、级联操作）
需要支持观察者模式（UI 刷新、配置同步）
未来可能从单例演进为多实例 或分布式
团队规模大，需要明确的API 契约

选型指南

复制代码

全局列表需要被修改吗？
│
├─ 不需要 → Collections.unmodifiableList() 包装
│
└─ 需要 ── 修改时需要附加逻辑吗？
           │
           ├─ 不需要 ── 多线程访问吗？
           │           │
           │           ├─ 是 → CopyOnWriteArrayList（读多写少）
           │           │      或 synchronizedList（读写均衡）
           │           │
           │           └─ 否 → 方案四：防御性复制
           │
           ├─ 需要，但逻辑简单 → 方案一：受控修改
           │                     或 方案三：包级封装
           │
           └─ 需要，且逻辑复杂 → 方案五：注册中心模式

总结

方案	线程安全	修改粒度	复杂度	典型场景
① 受控修改	需自行保证	元素级	低	配置项增删
② 线程安全集合	内置	元素级	低	简单缓存
③ 包级封装	需自行保证	元素级	低	模块内注册
④ 防御性复制	替换操作易原子化	集合级	低	配置热加载
⑤ 注册中心	可在内置保证	任意	中	复杂全局状态

最后一点思考

static final 只保证无法把引用指向另一个对象，并不禁止集合内部元素的增删 。这是 Java 语言设计的一个特性，而非缺陷------但恰恰因为这个特性，"允许修改的全局变量"才更需要被审慎设计。《Effective Java》：要么为可变性提供最小的访问权限，要么让对象不可变。记住这个原则：把修改途径收窄、把并发安全处理好，就能避免全局可变状态带来的绝大多数陷阱。

愿我都能在各自的领域里不断成长，勇敢追求梦想，同时也保持对世界的好奇与善意!

static final 指向可变集合的设计模式