collections.ncopies返回不可变视图，调用add/remove会抛unsupportedoperationexception；需用new arraylist()包装才可修改，且禁用于可变对象。
为什么 Collections.nCopies 生成的列表不能直接 add/remove
因为 Collections.nCopies 返回的是不可变视图——它不创建新对象，只是用一个固定值“假装”有 n 个副本。底层共享同一份数据，所以调用 add()、remove() 或 set() 会立刻抛出 UnsupportedOperationException。
常见错误现象：Exception in thread "main" java.lang.UnsupportedOperationException，尤其在你把它当作普通 ArrayList 接着操作时。
- 如果真需要可修改的重复列表，必须显式拷贝：用
new ArrayList(Collections.nCopies(n, value)) - 只读场景（比如传参、校验、Stream 源）可以直接用，省内存又快
- 注意：即使你用
Arrays.asList()包一层，也改不了它的不可变性——它和nCopies一样是 unmodifiable
用 Collections.nCopies 初始化 List 的正确写法
它不是构造器，而是工厂方法，返回 List<t></t>，但类型擦除后容易误判。最安全的初始化方式是带泛型声明或明确接收类型。
使用场景：批量填充默认值、测试数据构造、函数式编程中作为固定输入源。
立即学习“Java免费学习笔记（深入）”；
- ✅ 推荐：
List<string> list = new ArrayList(Collections.nCopies(3, "abc"));</string> - ⚠️ 危险：
List<string> list = Collections.nCopies(3, "abc");</string>—— 看似没问题，但后续任何修改都失败 - ⚠️ 隐患：
var list = Collections.nCopies(3, "abc");——var推导为不可变ImmutableCollections.ListN，IDE 可能不报错，运行时才翻车
Collections.nCopies 和 Arrays.fill / 循环初始化比有什么区别
核心差异在语义和开销：nCopies 是逻辑复用，Arrays.fill 是内存填充，循环是逐个新建对象。
性能影响明显：对不可变对象（如 String、Integer 常量），nCopies 几乎零分配；对可变对象（如 new HashMap()），它会重复引用同一个实例——这往往是 bug 而非特性。
- ✅ 安全用于：基本类型包装类、字符串、枚举等不可变值
- ❌ 绝对避免用于：自定义对象、
new ArrayList()、任何需要独立副本的可变类型 - 对比
Arrays.fill：后者只适用于数组，且要求目标数组已存在；nCopies返回的是List，更契合 Collection API 流程
当元素是 null 时，Collections.nCopies 行为是否可靠
完全可靠。null 是合法元素值，Collections.nCopies(5, null) 会生成含 5 个 null 的列表，既不会 NPE，也不影响不可变性约束。
但要注意：如果你后续用 new ArrayList(...) 包装它，得到的就是含 5 个 null 引用的可修改列表，可以正常 set(0, "x") 或 add(...)。
- 常见误判：以为 null 会导致方法抛异常——实际不会
- 兼容性无问题：Java 5+ 全版本支持 null 元素
- 真正要小心的是下游代码是否允许 null，比如某些集合工具类（如 Guava 的
ImmutableList构造）会拒绝 null，但nCopies本身不管这个
nCopies 返回的根本不是传统意义上的列表，而是一个轻量级代理。一旦想往里塞东西，就得先过拷贝这一关。 
