Collections.singletonList 更轻量、更不可变，仅持一个引用且无数组，内存约16字节，set操作直接抛异常；Arrays.asList 背后绑定真实数组，开销更大且允许 set 修改元素。
直接说结论：Collections.singletonList 更轻量、更不可变。它只持一个引用，不分配数组；Arrays.asList 虽也固定大小，但背后绑着一个真实数组，且允许 set() 修改元素。
内存开销差异明显
singletonList 返回的是 JDK 内部的静态私有类 SingletonList，整个对象仅含一个 element 字段，无数组、无 size、无 modCount —— 对象头 + 一个引用，通常仅约 16 字节（HotSpot 64-bit + CompressedOops）。
Arrays.asList 则返回一个包装原始数组的视图，哪怕只传一个元素，也要创建长度为 1 的 Object[] 数组（约 24 字节），加上列表对象本身，总开销更高。
不可变语义更严格
两者都拒绝 add/remove/clear，但关键区别在 set()：
• Collections.singletonList 的 set 操作直接抛 UnsupportedOperationException
• Arrays.asList 允许 set(0, newValue)，且会同步改到底层数组，属于“非结构性修改”
适用场景建议
选 singletonList 当你明确需要：
• 纯只读语义（连替换都不允许）
• 高频创建单元素临时集合（如 Stream fallback、API 响应封装）
• 追求极致内存效率（尤其在大量短生命周期对象场景）
选 Arrays.asList 当你需要：
• 保留对元素值的运行时更新能力（比如配置项可动态重设）
• 后续可能扩展为多元素（它天然支持 varargs，语义更通用）
立即学习“Java免费学习笔记（深入）”；
别踩这些坑
• 不要包装 singletonList：return new ArrayList(Collections.singletonList(x)) 白费新建对象
• 不要用它存 null 来“占位”——它允许 null 元素，但若业务逻辑依赖非空，需额外校验
• 别把它当可变集合用：所有修改操作都会失败，不是 bug，是设计使然
