subList和keySet是原集合的实时视图，修改它们会直接改变原集合；unmodifiableXXX则是只读包装器，所有修改操作均抛UnsupportedOperationException。
subList 返回的 List 为什么改它等于改原 ArrayList？
因为 subList 不是新拷贝一份数据，而是返回一个“活的视图”——底层仍指向原 ArrayList 的同一块数组，只是加了范围限制和代理逻辑。
- 修改
subList中元素（如set(0, "x")）会直接写入原列表对应索引位置 - 调用
subList.add()或remove()会触发原列表结构变化，可能抛ConcurrentModificationException（尤其在遍历原列表时操作子列表） - 若原列表后续扩容或缩容，
subList可能失效（比如原列表被clear()后再访问subList会立即报错）
实操建议：需要独立副本就用 new ArrayList(list.subList(1, 4))；仅读取或临时切片可直接用 subList，但别把它传给不可信方法或长期缓存。
keySet() 返回的 Set 真的“不包含值”吗？
它确实只暴露 key，但这个 keySet 是 HashMap 内部状态的实时投影——不是快照，也不是副本。
- 往原
Map中put新 key，keySet立即可见；remove某 key，keySet也立刻消失 -
keySet.remove("k1")等价于map.remove("k1")，会同步删掉对应的 value - 不能对
keySet做add(null)（除非 map 允许 null key），也不能add已存在的 key（会静默失败，因 Set 不允许重复）
常见错误现象：for (String k : map.keySet()) { if (k.startsWith("tmp")) map.remove(k); } —— 这会抛异常；必须用 Iterator.remove() 或先收集再删。
为什么 Collections.unmodifiableXXX 不算“视图”，而 subList/keySet 算？
关键区别在于“可变性反射”：unmodifiableList 是只读包装器，任何修改都直接报 UnsupportedOperationException；而 subList 和 keySet 虽然自己不持有数据，却把所有写操作穿透回原结构。
-
Collections.unmodifiableList(list)：安全隔离，适合对外暴露只读接口 -
list.subList(0, 2)或map.keySet()：轻量、零拷贝，但要求调用方清楚“它动，原结构也动” - 二者都不能防止原集合被其他引用修改——视图的“镜像”只反映原结构当前状态，不冻结它
性能影响：视图类操作几乎无额外开销（没复制、没哈希计算），但调试时容易误以为是独立对象，结果在别处改了原集合，这边“莫名”变了。
哪些集合操作会意外创建视图？容易踩的坑有哪些？
除了 subList 和 keySet，还有 values()、entrySet()、Arrays.asList()、String.substring()（JDK 7u6 之前）等，都是典型视图陷阱。
-
Arrays.asList(new String[]{"a","b"})返回的 List 不支持add/remove，但set(0, "x")有效——它背后是原数组 -
map.entrySet()中的Entry对象，调用setValue()会直接更新 map 中对应 value - 最隐蔽的坑：把
subList或keySet当作参数传进工具方法，该方法内部做了增删，结果原集合被悄悄改了
复杂点在于：这些视图没有统一标识，IDE 和静态检查很难预警；它们的行为取决于具体实现类（比如 TreeMap 的 keySet() 也是视图，但 ConcurrentHashMap 的 keySet() 在某些版本中是弱一致性快照）。写代码时，只要看到“XXXView”“XXXSet”“subXXX”字样，先问一句：它动，原数据动不动？
