maptoint() 与 map() 的核心差异在于底层数据类型和运行时开销：前者返回 intstream，绕过装箱拆箱，直接操作原始 int，显著提升性能并降低内存占用；后者返回 stream，涉及频繁对象创建与拆装箱。
mapToInt() 和 map() 的核心差异不在语法，而在底层数据类型和运行时开销。当你处理数值型字段（如年龄、数量、ID、评分）时，用 mapToInt() 替代 map() 不只是写法变化，而是绕过了 Java 的自动装箱机制，直接在原始 int 层面运算。
装箱拆箱是性能损耗的根源
map() 返回的是 Stream
- 每调用一次 Integer::parseInt 或 Person::getAge，就触发一次装箱（int → Integer）
- 后续调用 reduce、sum 等操作时，又要反复拆箱（Integer → int）
- 100 万个元素 ≈ 创建 100 万个临时 Integer 对象，堆内存压力明显上升
IntStream 提供原生数值能力
mapToInt() 返回 IntStream，它不是“对象流”，而是专为 int 设计的原始类型流，天然支持：
- sum()、average()、min()、max() —— 直接返回基本类型，无需 collect + Collectors
- summaryStatistics() —— 一次性获取 count/sum/min/max/average
- toArray() —— 直接生成 int[]，避免 new Integer[n] 再逐个赋值
真实场景下的性能差距
以 100 万条字符串转整数求和为例（JMH 基准测试结果）：
| 方式 | 耗时（ms） | 内存占用（MB） | GC 压力 |
|---|---|---|---|
| stream().map(Integer::parseInt).reduce(0, Integer::sum) | 145 | 85 | 高（频繁 Minor GC） |
| stream().mapToInt(Integer::parseInt).sum() | 62 | 32 | 低（几乎无对象分配） |
提速约 2.3 倍，内存减少超 60%。数据量越大，差距越显著。
什么时候不该硬切 mapToInt()
不是所有 int 场景都适合 mapToInt()：
- 需要后续链式调用非数值操作（如 filter 后再 map 成 String），IntStream 不支持泛型转换，得用 boxed() 转回 Stream
，反而增加开销 - 字段本身可能为 null（如 Optional
或数据库允许 NULL 的 age），mapToInt 会抛 NullPointerException，而 map() 可配合 Objects::nonNull 或 Optional 处理 - 实际数值范围可能超出 int（如时间戳毫秒值），应改用 mapToLong()
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
