intstream等原始类型流更省内存，因避免装箱拆箱开销，每个int仅占4字节而非integer的16字节，且内存连续、cpu缓存友好、jvm深度优化；百万级求和可减少上百mb堆内存与gc压力。
用 IntStream、LongStream 或 DoubleStream 替代 Stream
为什么原始类型流更省内存
普通 Stream 处理整数时，每个 int 都要包装成 Integer 对象：占用 16 字节（对象头 + 值字段 + 对齐填充），还要承担 GC 压力；而 IntStream 直接操作栈或堆外连续的 int 数组，每个元素仅占 4 字节，无对象开销。
- 百万级整数求和场景下，Stream
可能额外分配上百 MB 堆内存；IntStream 几乎不产生临时对象 - CPU 缓存更友好：int 数组是连续内存块，CPU 预取效率高；而 Integer 对象分散在堆中，易引发缓存未命中
- JVM 对原始类型流有深度优化，如 range()、iterate() 的底层实现可向量化，部分运算甚至编译为单条 CPU 指令
哪些操作必须换用原始类型流
凡涉及大量数值生成、遍历、聚合的环节，都应优先使用对应原始类型流：
-
生成数据：用
IntStream.range(1, 1000000)替代Stream.iterate(1, i -> i + 1).limit(1000000).mapToInt(i -> i) -
数组转换：用
Arrays.stream(intArray)而非Arrays.stream(IntegerArray) -
聚合计算：用
IntStream.sum()、IntStream.average()、IntStream.summaryStatistics()，避免reduce+ 包装类累加器 -
数值映射：若 map 后仍是基本类型（如 int → int），保持在 IntStream 内完成，不要中途转回 Stream
注意边界情况与陷阱
原始类型流不是万能的，需避开几个典型误区：
- 混合类型运算（如 int 和 double 混算）会触发隐式提升，可能意外转为 DoubleStream，失去 int 精度和内存优势
- 需要 null 表达“缺失值”时，原始类型流无法表示（int 默认是 0），此时应明确设计默认值或改用 OptionalInt
- 从集合获取原始流需谨慎：List
不能直接转 IntStream，必须用 list.stream().mapToInt(Integer::intValue)—— 这里仍发生一次装箱后立即拆箱，性能不如源头就用 int[] 或 IntStream 构建 - 并行处理时，IntStream.parallel() 的分片和合并开销远低于 Stream
，但若数据量小于 1 万，串行 IntStream 仍比并行更快
验证效果的小技巧
不用等上线压测，本地就能快速对比：
- 用 JMH 写两个 benchmark 方法：一个用 Stream
.reduce()，一个用 IntStream.sum()，固定相同数据规模 - 启动 JVM 时加
-XX:+PrintGCDetails -Xlog:gc*，观察 GC 次数和堆内存波动差异 - 用 VisualVM 或 JFR（Java Flight Recorder）采样，看热点方法是否还集中在 Integer.valueOf() 或 Integer.intValue()
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
