集合框架中的适配器模式：Arrays.asList解析

Arrays.asList() 是 Java 集合框架中一个典型且精妙的适配器模式实践，它不复制数据，而是将原始数组“零成本”桥接为符合 List 接口的视图对象，让数组无缝融入 Collection 生态（如参与排序、流操作或方法参数传递）；但正因它是轻量级视图而非独立集合，所有结构性修改（add/remove/clear）均会抛出 UnsupportedOperationException——理解这一设计本质，才能避开强制转型陷阱、误用只读列表的风险，并在需要可变性时通过 new ArrayList(Arrays.asList(...)) 主动完成安全脱钩，真正掌握接口抽象与实现约束之间的平衡艺术。

Arrays.asList() 返回的 List 为什么不能 add/remove？

因为 Arrays.asList() 返回的不是 java.util.ArrayList，而是 Arrays 内部的一个静态类 ArrayList（注意包名不同），它只实现了 get()、set()、size() 等方法，压根没重写 add()、remove()、clear() —— 这些方法继承自 AbstractList，默认抛出 UnsupportedOperationException。

• 它本质是数组的「视图」，不是拷贝，不支持结构性修改
• 调用 list.set(0, "x") 会直接改原始数组；同理，改数组也会反映到 list 上
• 哪怕传入的是 new String[]{"a","b"} 这种新数组，返回的 list 依然不可增删

什么时候该用 Arrays.asList()，什么时候不该用？

适合场景非常明确：快速构建一个「只读 + 可设值 + 固定长度」的轻量列表，比如作为参数传给需要 List 接口的方法，或用于 contains()、indexOf() 等查询操作。

• ✅ 安全用法：String[] arr = {"a", "b"}; List list = Arrays.asList(arr); boolean found = list.contains("a");
• ❌ 危险用法：list.add("c")、list.remove(0)、list.clear() —— 运行时必报 UnsupportedOperationException
• ⚠️ 隐蔽陷阱：把 Arrays.asList() 结果赋给 ArrayList 变量（如 ArrayList al = (ArrayList) Arrays.asList(...)）会强制转型失败或触发 ClassCastException

如何安全地把它转成可变集合？

唯一推荐做法：用构造函数包装一层，让 JVM 做一次真正的数据拷贝。这样就和原始数组彻底解耦，后续所有增删改都自由。

• 标准写法：new ArrayList(Arrays.asList("a", "b"))
• 如果只是临时用、不存引用，也可以用 new LinkedList(Arrays.asList(...))，但没必要，除非真要频繁首尾插入
• 别用 Lists.newArrayList()（Guava）或 Stream.of().collect(Collectors.toList()) 来替代——它们虽可行，但引入额外依赖或开销，纯 JDK 场景下 new ArrayList() 最直白、最可控

它真是适配器模式吗？桥接作用体现在哪？

是的，而且很典型：Arrays.asList() 把原生数组（T[]）这个没有集合接口能力的数据结构，“适配”成了符合 List 接口规范的对象，让老式数组能无缝接入 Collection API 生态，比如传给 Collections.sort()、stream() 或任何接受 List 的方法。

• 它不做数据复制，不改变语义，只提供统一接口 —— 这正是适配器的核心价值
• “桥接”不是指跨系统通信，而是跨类型契约：数组 → List 视图 → 标准集合操作链
• 容易忽略的一点：这个适配是单向强化的——你获得接口便利性，但必须接受它的限制；想绕开限制，就得主动做一次「脱钩」（即 new ArrayList(...)）

今天关于《集合框架中的适配器模式：Arrays.asList解析》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！