subList分页不会抛ConcurrentModificationException，但前提是原始List未被并发修改；其返回原列表视图，结构性修改会导致已有subList失效，调用size()或遍历时可能抛该异常。
subList 分页会抛 ConcurrentModificationException 吗？
不会——但前提是原始 List 没被并发修改。subList 返回的是原列表的视图，不是副本，所以后续对原列表的结构性修改（比如 add、remove）会立刻让已有的 subList 失效，调用其 size() 或遍历时就可能抛这个异常。
- 安全做法：分页前先用
new ArrayList(originalList)做一次浅拷贝，再对副本调用subList - 注意
subList(fromIndex, toIndex)的toIndex是「开区间」，要小心越界：传入Math.min(end, list.size())更稳妥 - 如果原列表是
LinkedList，subList虽然合法，但随机访问性能差，不建议用于高频分页场景
Stream.skip/limit 分页为什么慢？
因为 Stream 是惰性求值，但 skip(n) 必须「跳过前 n 个元素」，底层会逐个消费，无法像数组下标那样 O(1) 定位。对大列表（比如 10 万条），第 99 页（skip(9900)）实际要遍历近 10 万个元素。
- 仅适合小数据量或一次性简单分页，别在循环里反复调用
skip/limit做多页计算 - 若数据来自数据库，优先把分页逻辑下推到 SQL（
LIMIT offset, size），而不是在 Java 层加载全量再流式切 -
stream().skip().limit().collect(Collectors.toList())会产生新对象，内存开销比subList高
分页边界处理：end 超出 size 怎么办？
直接传超限的 toIndex 给 subList 会抛 IndexOutOfBoundsException；而 Stream.limit 则自动截断，更宽容但容易掩盖逻辑错误。
- 统一做法：算出真实结束索引
int end = Math.min(start + pageSize, list.size()) - 别依赖
list.subList(start, list.size())来兜底——万一start > list.size()，照样崩 - 推荐封装一个工具方法，内部校验
start是否合法（>= 0 && <= list.size()），避免静默返回空列表误导调用方
并发环境下该选哪个？
两个都不直接线程安全。subList 视图共享原列表状态，Stream 操作本身无状态但源头可能被改。真正需要并发分页时，核心是「隔离数据源」。
立即学习“Java免费学习笔记（深入）”；
- 如果原始列表会被其他线程写，必须在分页前加锁或使用不可变副本（如
ImmutableList.copyOf(list)） - 别用
Collections.synchronizedList包一层就以为安全——subList返回的视图不继承同步语义 - 高并发分页且数据不变时，可预先按页缓存
List<List<T>>，避免每次重复切片
最麻烦的不是选 subList 还是 Stream，而是忘记检查原始集合是否为空、是否被外部修改、以及页码参数是否为负数——这些地方一漏，线上就容易出现莫名其妙的空指针或越界。
