subSet() 返回的是原 TreeSet 的视图而非新集合，修改双方实时互映，共享红黑树结构，不复制数据、性能高但存在并发修改和迭代器弱一致性风险。
subSet() 返回的是视图，不是新集合
调用 TreeSet.subSet() 得到的对象底层仍指向原 TreeSet 的红黑树结构，任何修改（如 add()、remove()）都会实时反映到原集合中，反之亦然。这不是拷贝，也不触发数据复制——所以性能开销极小，但副作用也真实存在。
常见错误现象：ConcurrentModificationException 在遍历子集视图的同时修改原集合（或反之），因为二者共享同一结构；或者误以为删掉子集里的元素不会影响原集合。
- 子集视图不支持
add(null)（若原TreeSet不允许 null） - 子集视图的
size()是 O(log n) 时间复杂度（非缓存值，需动态计算区间节点数） - 若原
TreeSet使用自定义Comparator，子集视图完全继承该比较逻辑，无需额外配置
边界参数必须满足“可比较性”且在范围内
subSet(fromElement, toElement) 要求 fromElement ≤ toElement（按集合的比较规则），否则抛 IllegalArgumentException；更关键的是，两个端点本身不必存在于原集合中，但必须能被集合的 Comparator 正确比较——比如用 String.CASE_INSENSITIVE_ORDER 时，传入的 fromElement 也得是 String 类型，不能是 Integer。
使用场景：分页查姓名首字母在 'M' 到 'S' 之间的用户，即使集合中没有恰好叫 "M" 或 "S" 的人，也能安全切片。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 若
fromElement> 所有现存元素，返回空视图（isEmpty() == true） - 若
toElement≤ 所有现存元素，结果不含任何元素（左闭右开，且toElement本身不包含） - 对自然排序的
Integer集合，subSet(5, 10)包含 5、6、7、8、9，不含 10
三种重载方法的区别与选型
除了最常用的 subSet(E fromElement, E toElement)，还有带布尔标志的两个重载：subSet(E fromElement, boolean fromInclusive, E toElement, boolean toInclusive) 和对应 headSet/tailSet 的变体。它们解决同一个问题：控制端点是否包含。
性能影响几乎为零，但语义更精确。例如想获取 [5, 10]（闭区间），用基础版做不到，必须用四参数版：subSet(5, true, 10, true)。
- 基础两参数版等价于
subSet(fromElement, true, toElement, false) - 若只需左开右闭（如 (5, 10]），用
subSet(5, false, 10, true) - 所有重载均返回
NavigableSet，支持pollFirst()、higher()等导航操作
并发修改和迭代器失效风险
子集视图的迭代器是“弱一致性”的：它不抛 ConcurrentModificationException，但也不保证看到最新修改。如果在迭代子集过程中，另一个线程往原 TreeSet 插入落在该子集范围内的新元素，这次插入可能被当前迭代器跳过——取决于红黑树结构调整时机。
容易被忽略的地方：很多人以为“只读视图”就绝对安全，其实只要原集合被改，子集视图的结构状态就可能瞬时不一致；若业务逻辑依赖严格顺序或完整遍历，应在外层加同步，或先转成 ArrayList 再处理。
- 子集视图的
iterator()不是 fail-fast，但也不是强一致 -
toArray()方法会触发全量快照，适合需要稳定结果的场景 - 不要在子集视图上调用
clear()后继续使用原TreeSet——虽不报错，但原集合已空，后续操作全无效
