面试考察点
- 是否知道装箱和拆箱对应的编译器转换。
- 能否解释 Integer 使用
==时结果不一致的原因。 - 是否关注空值拆箱和循环装箱的成本。
核心答案
自动装箱通常转换为
Integer.valueOf(int)，拆箱转换为intValue()。Integer默认缓存 -128 到 127，因此缓存范围内的装箱对象可能相同，但==比较对象身份，数值比较应使用equals或先拆箱。
包装类型为 null 时自动拆箱会抛出 NullPointerException，这在条件判断、算术运算和三元表达式中很容易被忽略。
关键机制
Integer.valueOf 会复用缓存对象，而显式 new Integer 总是创建新对象。不同包装类型的 equals 通常要求类型也相同，例如 Integer(1) 不等于 Long(1)。
编译器实际做了什么
Integer boxed = 100; // Integer.valueOf(100)
int raw = boxed; // boxed.intValue()
boxed++; // 拆箱、加一、再装箱，并非修改原对象
包装类是不可变对象，boxed++ 会让变量指向新的 Integer。若 boxed 为 null，异常发生在调用 intValue() 的拆箱阶段，堆栈有时只指向一行普通算术表达式。
缓存与比较示例
Integer a = 127;
Integer b = 127;
Integer c = 128;
Integer d = 128;
System.out.println(a == b); // 常见实现中为 true
System.out.println(c == d); // 常见实现中为 false
System.out.println(c.equals(d)); // true
这个例子只能用于说明对象身份，不应写成依赖缓存的业务判断。Boolean、Byte、Short、Character、Long 等包装类也有各自缓存规则，范围和实现细节不能混记成统一契约。
隐式拆箱的高风险位置
Map<String, Integer> counts = new HashMap<>();
if (counts.get("paid") > 0) { // 键不存在时拆箱 null
// ...
}
应使用 getOrDefault、显式 null 判断或把“未设置”和“零”设计成不同状态。条件表达式也要谨慎：
Integer value = condition ? nullableInteger : 0;
由于数值类型推断，这类表达式可能对 nullableInteger 拆箱。不要只看目标变量是 Integer 就假定整个过程没有拆箱。
性能与数据建模
一百万个 Integer 不仅保存数值，还包含对象头、引用数组和对齐成本，内存远大于 int[]。高频计算、计数器和大规模数值数据优先使用基本类型或专用原始类型集合；普通 DTO、泛型集合和允许 null 的数据库字段才使用包装类型。
金额和精确小数不应因为“避免装箱”就改用 double，应优先正确性，使用整数最小货币单位或 BigDecimal，并明确舍入规则。
实践边界
- DTO 和数据库字段允许空值时，计算前先明确空值语义。
- 高频数值循环使用基本类型，减少对象分配与 GC 压力。
- 集合泛型只能使用包装类型，但读取后可显式转换为基本类型处理。
常见误区
不能依赖缓存范围推断 == 结果，缓存大小还可能受实现和配置影响。三元表达式也可能触发数值提升和拆箱，导致意外空指针。
高频追问与参考回答
追问：Integer 和 int 用 == 比较会怎样？
通常会把 Integer 拆箱成 int 后进行数值比较；如果 Integer 为 null，拆箱阶段会抛出空指针异常。
追问：new Integer(127) 和 Integer.valueOf(127) 相同吗？
前者明确创建新对象且构造器已不推荐使用，后者可以复用缓存。数值相等应使用 equals 或拆箱，不能根据创建方式使用 ==。
追问：为什么 Integer.equals(Long) 为 false？
包装类 equals 通常要求运行时类型相同再比较值，以保持对称和明确语义。跨数值类型比较应先转换到共同且不会丢精度的表示。
追问：AtomicInteger 会触发装箱吗？
其核心更新 API 接受并返回 int，通常不需要 Integer 对象；但把结果放入 List<Integer>、作为 Object 传递或进入泛型 API 时仍会装箱。
总结
包装类型既有对象身份又有数值语义，业务比较使用 equals 或基本类型，并始终考虑 null 和装箱成本。
机制全景图
下面把「自动装箱、拆箱和 Integer 缓存有哪些坑？」从输入到结果压缩成一条可复述的主链路。面试时先用图建立全局坐标，再进入局部实现，能避免只背零散结论。
flowchart LR
A["基本类型参与表达式"]
A --> B["编译器插入装箱"]
B --> C["查询包装类缓存"]
C --> D["生成或复用对象"]
D --> E["拆箱比较与运算"]
完整链路：从输入到结果
沿着「基本类型参与表达式 → 编译器插入装箱 → 查询包装类缓存 → 生成或复用对象 → 拆箱比较与运算」观察输入、状态与输出，下面每个阶段都对应一个可以在源码、日志或系统表中验证的位置。
1. 基本类型参与表达式
自动装箱是编译器语法糖，例如 int 到 Integer 通常转换为 Integer.valueOf，而不是 JVM 新的参数传递规则。
2. 编译器插入装箱
valueOf 会先检查缓存范围；Integer 默认缓存 -128 到 127，其他包装类范围与行为并不完全相同。
3. 查询包装类缓存
命中缓存返回共享实例，未命中通常创建新对象，因此用引用相等比较包装类会得到随数值变化的结果。
4. 生成或复用对象
拆箱调用 xxxValue；null 包装类参与算术、比较或三元表达式时会在拆箱位置抛出 NullPointerException。
5. 拆箱比较与运算
高频集合和流式计算中的装箱会增加分配、指针访问和 GC 压力，性能敏感路径可使用基本类型数组或专用集合。
源码与实现定位
| 入口 | 阅读重点 |
|---|---|
| java.lang.Integer#valueOf | IntegerCache 范围与复用 |
| javap invokestatic/intValue | 观察装箱、拆箱插入点 |
源码或系统表应按上表顺序追踪：先确认入口实际走到哪条路径，再用运行时数据验证，而不是仅凭类名或配置推测。
参数配置与可复现实验
Integer a = 127, b = 127;
Integer c = 128, d = 128;
assert a == b;
assert !c.equals(null) && c.equals(d);
编译数值比较、三元表达式和集合流操作，使用 javap 定位 valueOf/intValue；JFR 对比 Integer 流与 IntStream 的分配。
验证步骤与预期结果
1. 固定输入和基线
先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「包装类分配率」为主基线，记录值应满足「非热点路径可忽略」；同时保存 包装类分配速率、拆箱 NPE 堆栈，使后续变化能够回到同一时间轴比较。
2. 从实现入口确认路径
在「java.lang.Integer#valueOf」确认请求确实进入「IntegerCache 范围与复用」对应的实现，再沿「javap invokestatic/intValue」观察「观察装箱、拆箱插入点」。如果入口路径都未命中，就不应继续调整下游参数，而应先检查调用条件、版本或路由是否与假设一致。
3. 注入本文特有的失败模式
优先复现「用 == 比较包装对象」，并把单一变量逐级放大，直到「包装类分配率」越过「进入分配 Top 10」。随后再分别验证「null 自动拆箱触发异常」和「热循环装箱造成大量短命对象」，三类故障分开执行，避免多个变量同时变化而无法归因。
4. 执行止损和根因修复
第一轮只应用「禁止包装数值用 == 做业务判断」，确认它能控制影响范围；第二轮应用「可空数值在边界显式校验」，验证核心链路恢复；最后落实「高频计算改用基本类型专用 API」，消除同类问题再次出现的条件。每一步都保留变更前后数据，不用“感觉变快了”替代测量。
5. 通过退出条件
实验只有同时满足三项才算通过：「包装类分配率」回到「非热点路径可忽略」、「拆箱 NPE」回到「目标为 0」、「引用比较扫描」回到「业务代码目标为 0」，并且业务结果差异为零。若性能恢复但结果不一致，仍应视为失败；若指标恢复后很快再次越线，则说明只完成了临时止损，没有消除根因。
量化基线
| 指标 | 样例基线/口径 | 风险线 | 结论 |
|---|---|---|---|
| 包装类分配率 | 非热点路径可忽略 | 进入分配 Top 10 | 改基本类型流/数组 |
| 拆箱 NPE | 目标为 0 | 出现任意样本 | 在边界定义 null 语义 |
| 引用比较扫描 | 业务代码目标为 0 | Integer 使用 == | 替换 equals/数值比较 |
这些数值是实验口径或示例告警线，不是可复制到所有系统的固定答案；上线阈值应由本系统稳态、峰值和故障演练共同确定。
事故复盘：金额比较在不同数值范围表现不一致
业务代码用 Integer 的 == 判断券数量，小值测试全部通过，生产中超过缓存范围后比较失败。改为 Objects.equals 或先拆箱比较，并为 null 建立明确语义后，行为才与对象身份无关。
| 失败模式 | 首要证据 | 第一处置动作 |
|---|---|---|
| 用 == 比较包装对象 | 包装类分配速率 | 禁止包装数值用 == 做业务判断 |
| null 自动拆箱触发异常 | 拆箱 NPE 堆栈 | 可空数值在边界显式校验 |
| 热循环装箱造成大量短命对象 | Young GC 压力 | 高频计算改用基本类型专用 API |
发布与回滚检查点
- 发布前：确认「java.lang.Integer#valueOf」对应实现和上述配置在目标版本仍然有效，并保存「包装类分配率」基线。
- 灰度中：同时观察 包装类分配速率、拆箱 NPE 堆栈、Young GC 压力；任一指标越过表中风险线，就停止继续扩量。
- 回滚时：先执行「禁止包装数值用 == 做业务判断」控制影响，再回退代码或参数；涉及持久状态时必须额外核对结果差异。
- 发布后：至少覆盖一个完整峰值周期，确认「用 == 比较包装对象」没有再次出现，才关闭变更观察窗口。
方案对比与选型
| 方案 | 更适合的场景 | 主要收益 | 代价与边界 |
|---|---|---|---|
| 基本类型 | 高频计算且不存在 null | 无装箱分配、语义直接 | 不能表达缺失值且不能直接用于泛型 |
| 包装类型 | 泛型容器、可空字段和反射 API | 可表达 null、API 兼容 | 存在装箱、拆箱和身份误用风险 |
| OptionalInt 等 | 返回值需要表达可能缺失的基本数值 | 避免包装类 null | 不适合作为实体字段或通用容器 |
选型至少带上 对象创建率、调用频次、输入规模和 API 边界，并用上面的量化基线验证；未知数据应明确为待测假设。
设计边界与工程取舍
缓存是实现优化而不是业务契约；代码应依据数值相等性编写，不能通过扩大 Integer 缓存范围来修复错误的引用比较。
工程落地遵循：优先保证语言语义、类型契约和向后兼容，再讨论微小性能收益。回答时直接引用「java.lang.Integer#valueOf」、配置实验和事故数据，比复述固定模板更有说服力。