不能靠异常捕获结构判断集合临界值并自动切换并行流，因并行流启用是显式调用决定的，异常仅暴露代码错误而非切换信号。
不能靠异常捕获结构来判断集合临界值并自动切换并行流。
并行流的启用与数据规模无关，也不依赖异常触发
Stream 的 parallel() 或 parallelStream() 是显式调用的行为，底层不会因为抛出 ConcurrentModificationException、OutOfMemoryError 或其他异常，就“自动”回退或切换到并行/串行模式。JVM 不提供这种运行时自适应机制。
所谓“临界值”，实际只影响 ForkJoinPool 内部任务拆分粒度（例如默认阈值约 10,000 元素），但它不决定是否启用并行——只要调用了 parallel()，就会走并行路径；哪怕只有 1 个元素，也仍会进入 commonPool 执行，只是拆分后只剩一个子任务。
真正影响是否该用并行流的关键因素
不是集合大小，而是操作类型和执行环境：
- 计算密集型 + 无状态操作：如 map(x -> x * x)、filter(x -> x > 100)、reduce(Integer::sum)，适合并行，提速明显
- 含 I/O 或阻塞操作：如 map(x -> httpGet(x))、forEach(System.out::println)，极易拖垮 commonPool，反而更慢甚至卡死
- 有状态中间操作：sorted()、distinct()、limit() 需全局协调，扩展性差，并行收益低甚至负向
- 小数据集（：线程调度+合并开销可能超过计算收益，串行更稳更快
若想实现“按需自动并行”，需手动控制
没有内置钩子监听异常来决策，但可封装逻辑做主动判断：
- 根据 list.size() 预估：size > 5000 且操作纯计算 → 走 parallelStream()
- 用 ForkJoinPool.commonPool().getParallelism() 获取当前并行度，结合 Runtime.getRuntime().availableProcessors() 判断资源余量
- 对关键操作加 try-catch 并记录耗时，历史数据积累后做简单启发式降级（如连续 3 次并行耗时 > 串行 1.5 倍，则下次跳过 parallel）
- 避免在 forEach、collect(toList()) 等易出错环节依赖异常作为开关——ConcurrentModificationException 表明你已写错代码，不是切换信号
异常只能暴露问题，不能驱动策略
比如出现 ConcurrentModificationException，说明你在并行流中修改了被遍历的 ArrayList；出现 RejectedExecutionException，说明 commonPool 已饱和；这些是 bug 提示，不是“该切串行”的业务信号。修复方式是换用线程安全容器、预处理数据、或改用自定义 ForkJoinPool，而不是靠 catch 异常再重试串行流。
