如何在运行时判断Java Collection集合是否可修改

首先直接给核心结论：Java标准库没有提供通用的官方API可以返回布尔值标识集合是否可修改，也没有专门的公共标记接口用来区分可修改/不可修改集合，你遇到的是Java集合框架设计层面遗留的已知痛点，从JDK1.2集合框架上线至今这个问题都没有在标准API层面解决。

为什么常规判断思路行不通 #

• 所有JDK内置的不可修改集合，包括Collections.unmodifiableXxx()包装的集合、Java 9+ 提供的List.of()/Set.of()/Map.of()返回的集合、List.copyOf()系列方法返回的集合，都是不同JDK版本下的私有内部实现类，没有统一的公共父类或者标记注解。靠instanceof判断类名的做法极其脆弱，JDK小版本迭代都可能改动内部类名，直接用到生产环境大概率会出跨版本兼容问题。
• 不存在通用的“可修改集合”类型标识：很多第三方库也会提供自己的不可修改集合实现，就算覆盖了JDK的所有实现类，也没法覆盖第三方的场景。

业界实际采用的落地方案 #

方案1：通过方法契约明确入参约束 #

这是绝大多数主流开源项目采用的标准做法：直接在方法注释、接口文档里明确要求传入的集合必须支持修改操作，同时声明传入不可修改集合时会抛出UnsupportedOperationException。
这种做法完全符合Java集合框架本身的设计约定——如果调用方违反契约传入不符合要求的参数，抛出异常是合理的行为，不属于异常控制流程。
示例代码：

/**
 * 批量更新列表内的元素
 * @param list 待处理的列表，必须支持修改操作
 * @throws UnsupportedOperationException 传入不可修改列表时抛出
 */
public void updateList(List<String> list) {
    // 直接执行业务逻辑即可，不需要额外前置判断
    list.replaceAll(s -> s.trim());
    list.add("updateFinish");
}

方案2：防御性创建可修改副本 #

如果你的方法不希望把异常抛给调用方，最稳妥的做法根本不是判断原集合是否可修改，而是直接拿入参创建一个你完全可控的可修改副本，所有修改操作都在副本上执行，最后按需返回副本即可。这种写法可以100%规避不可修改集合的问题，不需要做任何兼容性判断。
示例代码：

public List<String> processCollection(Collection<String> origin) {
    // 基于原集合创建可修改的ArrayList副本，不管原集合是否可修改都能正常写入
    List<String> target = new ArrayList<>(origin);
    // 所有修改操作都在副本上执行
    target.removeIf(String::isBlank);
    target.add("processed");
    return target;
}

方案3：封装独立的参数校验逻辑 #

如果你确实需要在执行业务逻辑前提前拦截不可修改的集合，注意不要把异常捕获写在业务流程分支里，可以把可修改性校验封装成独立的参数校验方法，和非空判断、长度校验等常规参数校验放在同一层级。这种场景下的异常捕获不属于“把try-catch当常规流程控制”，是完全合规的写法。
注意校验时不要真的改动集合原有数据：

private void requireModifiable(Collection<?> collection) {
    if (collection == null) {
        throw new IllegalArgumentException("集合不能为null");
    }
    try {
        // 执行零数据影响的修改探测，执行完立即回滚
        boolean modified = collection.add(null);
        if (modified) {
            collection.remove(null);
        }
    } catch (UnsupportedOperationException e) {
        throw new IllegalArgumentException("传入的集合不支持修改操作，请传入可修改的集合实例", e);
    }
}

补充说明：Java集合框架的设计者当初选择不拆分可修改/不可修改集合的类型接口，核心考量是保持接口的简洁性，避免拆分出过多的细粒度接口增加开发者的学习和使用成本，但这个设计确实带来了你提到的使用痛点，属于典型的设计权衡带来的历史遗留问题。

内容的提问来源于stack exchange，提问作者RedCrafter LP