Collections.emptyList()返回不可变单例EmptyList，其add等方法直接抛UnsupportedOperationException；反射仅调用既有方法，无法绕过该设计逻辑，故仍会抛异常。

向 Collections.emptyList() 返回的不可变列表中尝试添加元素，一定会抛出 UnsupportedOperationException，这不是反射“导致”的问题，而是该集合本身的设计使然——反射只是触发了这个已有行为。

为什么反射也改变不了 emptyList 的不可变性？

Collections.emptyList() 返回的是一个静态内部类 EmptyList（JDK 12+ 为 ImmutableCollections.ListN），其 add()、set()、remove() 等所有修改方法都直接抛异常：

throw new UnsupportedOperationException("add");

反射无法绕过方法体内的逻辑，它只能调用已存在的 public / protected / package-private 方法（或通过 setAccessible(true) 访问 private 方法），但这些方法本身就会抛异常。即使你用反射调用 add()，也只是更快地暴露了这个设计事实。

Gradle 9.8.0

下载

常见误用场景与排查要点

• 混淆了“空集合”和“可变集合”：误以为 emptyList() 是一个容量为 0 的 ArrayList，实际它是专为不可变语义设计的单例对象。
• 反射调用未检查返回类型：例如从某方法反射获取返回值后，直接当作 ArrayList 强转并调用 add()，而实际是 EmptyList 实例。
• 试图用反射修改 final 字段或数组：有些开发者想通过反射篡改底层结构（如 EMPTY_ARRAY），但 EmptyList 不含可修改的存储字段，且 JDK 9+ 对关键字段加了更强的运行时保护。

如何安全地处理这类集合？

• 需要可变集合时，显式创建：new ArrayList(Collections.emptyList()) 或 new ArrayList()；
• 接收外部传入的集合参数时，先判断是否为不可变实例：list instanceof java.util.Collections.UnmodifiableRandomAccessList（不推荐硬判类型），更稳妥的是捕获 UnsupportedOperationException 或统一用 new ArrayList(list) 包装；
• 若必须用反射操作集合，先确认目标对象的实际运行时类型：obj.getClass().getName()，避免对 EmptyList、SingletonList、UnmodifiableCollection 等调用修改方法。

调试建议

在抛错位置打上断点，查看异常堆栈顶层的调用者，再检查被操作对象的 getClass().getName() 和 toString() 输出。典型输出类似：

class java.util.Collections$EmptyList
[]

一旦确认是 EmptyList，就无需怀疑反射机制，应转向业务逻辑检查：是谁把不可变集合传入了本该处理可变集合的上下文？

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南