java stream api 本身不是线程安全的，设计为单线程一次性消费；stream 实例不可多线程共享或重复调用终止操作，parallelstream 的并行性不保证业务逻辑线程安全，关键取决于lambda是否访问可变共享状态。
Java Stream API 本身不是线程安全的，它的设计初衷是**单线程、一次性消费**。是否线程安全，关键看你怎么用——尤其是是否共享流对象、是否并行执行、以及中间/终止操作是否访问可变共享状态。
Stream 实例不可被多线程共享
一个 Stream 对象（如通过 list.stream() 创建）只能被一个线程调用一次 terminal operation（如 forEach、collect、count）。重复调用或多个线程同时调用会抛出 IllegalStateException。
- Stream 不是“可重入”或“可复用”的容器，它代表的是对数据源的一次性遍历过程；
- 即使数据源（如 ArrayList）是线程安全的，Stream 实例本身也不支持并发消费；
- 错误示例：两个线程同时对同一个 stream.forEach(...)，必然失败。
parallelStream 的并行性不等于线程安全
parallelStream() 会将数据拆分、用 ForkJoinPool 多线程处理，但它不会自动保护你的业务逻辑。只要你的 lambda 表达式里读写共享变量（如静态计数器、外部 List、Map），就极易引发竞态条件。
- 例如：用 parallelStream().forEach(i -> list.add(i)) —— ArrayList 的 add() 非线程安全，大概率抛 ConcurrentModificationException 或丢失元素；
- 正确做法：改用线程安全集合（如 CopyOnWriteArrayList）、或使用无副作用的收集方式（如 .collect(Collectors.toList())）；
- 注意：.forEachOrdered() 能保证顺序，但不解决共享状态冲突，只避免输出乱序。
哪些操作天然安全？哪些必须加锁？
判断依据始终是：**是否读写可变共享状态**。
- ✅ 安全场景：仅读取不可变对象（如 String、Integer）、纯函数式转换（map(s -> s.toUpperCase())）、过滤（filter(x -> x > 0)）；
- ❌ 危险场景：在 lambda 中修改静态变量、向外部集合 add、更新共享 Map 的值、调用非线程安全方法；
- ⚠️ 折中方案：用 collect() 替代 forEach 做聚合，因为 collect 是为并行设计的，能自动合并中间结果（如 Collectors.summingInt、toConcurrentMap）；
- ? 若必须写共享状态，应显式同步：用 synchronized 块、AtomicInteger、ReentrantLock，而不是依赖 Stream 机制。
推荐实践：保持无状态 + 使用安全终端操作
真正规避线程安全问题的方式，是让 Stream 流水线本身不持有或修改任何共享状态。
- 优先用 collect() 而非 forEach/forEachOrdered 做结果聚合；
- 需要统计或归约时，选用线程安全的收集器：Collectors.toConcurrentMap、Collectors.groupingByConcurrent；
- 若需副作用（如日志、发消息），确保目标操作本身线程安全，或把副作用移到串行阶段（如先 parallelStream().map(...).collect(...)，再单线程 forEach 处理结果）；
- 避免在 lambda 中捕获可变局部变量（如非 final 的数组引用、普通对象引用）。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
