sublist返回的是原list的视图而非新list，修改会双向影响，存在并发异常、越界、内存泄漏及序列化失败风险，需用new arraylist()显式复制。
subList 返回的是视图，不是新 List
调用 subList 不会拷贝元素，它返回的是原 List 的一个“活的切片”——底层仍指向同一份数据。这意味着你对子列表的修改（比如 add、remove、set）会直接反映到原列表上，反之亦然。
常见错误现象：
• 原列表突然变短或抛出 ConcurrentModificationException
• 传入 subList 结果给其他方法后，原集合意外被改
• 多线程环境下无锁访问导致不可预测行为
- 只读场景下可用，但必须确保原列表不被并发修改
- 若需独立副本，显式调用
new ArrayList(list.subList(a, b)) - 避免长期持有
subList返回值——尤其在缓存、静态变量或跨方法传递时
add/remove 操作可能触发原列表结构变更失败
subList 自身不维护独立结构，它的 add 和 remove 实际委托给原列表执行。但原列表若为 ArrayList，这些操作会触发数组扩容或移动；而 subList 内部缓存的范围边界（fromIndex/toIndex）不会自动更新，导致后续操作越界或漏数据。
典型报错：IndexOutOfBoundsException 或静默跳过元素
立即学习“Java免费学习笔记（深入）”；
-
subList.add()在非末尾位置插入 → 原列表元素位移，subList视图索引失效 -
subList.remove(0)后再调用subList.get(0)可能抛异常 - 安全做法：需要增删时，先转成新
ArrayList，别依赖视图的可变性
内存泄漏风险：subList 持有原列表的强引用
subList 的实现类（如 ArrayList.SubList）内部持有一个指向原 ArrayList 实例的强引用。哪怕你只取了几个元素，只要这个 subList 对象还活着，整个原列表就无法被 GC 回收。
使用场景陷阱：
• 从大文件解析出的百万级 ArrayList 中取前 10 条做预览，却把 subList(0, 10) 存进缓存
• 日志聚合中截取异常栈片段，但保留了原始完整日志对象的 subList
- 检查堆内存时发现小对象占着大数组——大概率是
subList引用没释放 - JDK 9+ 的
ImmutableList.copyOf(list.subList(...))可切断引用，但注意它是不可变的 - 最稳妥：用
Arrays.asList(arr).subList(...)前先确认arr本身不巨大
序列化与跨进程传递会直接失败
subList 返回的对象（如 ArrayList.SubList）默认未实现 Serializable，或其实现依赖原列表状态。序列化它通常抛 NotSerializableException，即使勉强绕过，反序列化后也无法还原正确视图。
常见于：
• Dubbo/Feign 接口返回类型误写为 List.subList(...)
• Redis 缓存时直接存 subList 结果
- 序列化前务必调用
new ArrayList(subList) - 不要把
subList当作 DTO 字段直接暴露给外部系统 - Gson/Jackson 默认不支持序列化内部类视图，会静默忽略或报错
最易被忽略的一点：subList 的“视图性”不是语言特性，而是具体实现决定的——LinkedList.subList 同样有引用绑定和并发问题，但扩容逻辑不同；而第三方库如 Guava 的 Lists.subList 行为可能更严格。别凭经验假设所有 subList 都一样。
