真用过包装类与自动装箱的人，都有几个忘不掉的坑。面试官就爱聊这个——默认行为是什么、边界在哪、出错时是什么表现，背资料的人在这里会集体沉默。包装类看着只是"基本类型的对象版"，但它背后藏着缓存、拆箱空指针、隐式类型提升三处高频雷区。
先把结论放在前面：包装类在值为 null 时拆箱会直接抛空指针；三元表达式里混用基本类型与包装类会触发隐式拆箱；Integer 在 -128~127 有缓存池，超出后 == 比较的是不同对象。这题要答好，得先知道常见的错误长什么样，再反向把正确姿势讲清。
机制拆解
这篇从原理、用法到坑，把包装类与自动装箱一次理清。
自动装箱到底做了什么
自动装箱是编译器在"基本类型 ↔ 对应包装类"之间自动插入的语法糖：写 Integer a = 127 时编译器帮你变成 Integer.valueOf(127)，写 int x = a 时帮你变成 a.intValue()。注意装箱产生的是对象、拆箱是取值，这两步在循环、集合遍历里会大量发生，稍不留神就制造海量临时对象。
一个关键区分：== 对包装类比的是"引用"，对基本类型比的是"值"。当两边都是包装类时，它走的是对象身份比较，而不是数值相等——这正是缓存池边界坑的根源。equals 才是包装类的正确比较方式，它比的是装箱后的数值。把"包装类一律用 equals，基本类型才用 =="写成团队铁律，能拦掉一大半相关 bug。
这些坑的正确绕法
最常见的坑是用 == 比较两个从接口或方法返回的 Integer。本地自测时值落在 -128~127 命中缓存、是同一个对象，== 碰巧为 true；一上线上遇到超过 127 的值，返回的是两个不同对象，== 立刻为 false，表现诡异地不一致。正确做法：任何包装类比较都走 equals，或用 intValue() 拆成基本类型再比。
其次是在热点循环里对 Long 等包装类型累加，每次自增都产生一个新 Long 对象，监控里出现大量 Long 分配与 GC 压力。计数器、求和这类场景，热点路径应直接用基本类型 long，只有需要放进集合或可能为 null 时才装箱。
还有一个更隐蔽的坑：三元表达式 flag ? a : b 中，当 a、b 一个是基本类型一个是包装类时，编译器会把两边都提升成基本类型（触发拆箱），若那个包装类是 null，拆箱当场 NPE，而且出错位置指向三元表达式整行，难以一眼定位。涉及包装类的三元，统一先确认两侧类型一致、或显式处理 null。
代码里见真章
看一段能直接跑的代码，把上面的机制落到具体写法上：
Integer a = 127, b = 127; // 命中缓存池 -128~127：同一对象
Integer c = 128, d = 128; // 超出缓存：各自 new，引用不同
System.out.println(a == b); // true（陷阱：同一对象）
System.out.println(c == d); // false（不同对象，引用不等）
System.out.println(c.equals(d)); // true（包装类比较一律用 equals）
int unbox = c; // 自动拆箱，c 若为 null 会 NPE
这段代码值得盯三处：第一处，a == b 为 true 不是因为数值相等，而是命中缓存池拿到了同一对象——这是最迷惑人的表面现象；第二处，c == d 为 false 暴露了"包装类 == 比引用"的真相；第三处，int unbox = c 的自动拆箱在 c 为 null 时直接 NPE。面试讲到这一层，基本就稳了。
这题在面试里怎么问、怎么答
"请简单介绍一下包装类与自动装箱，它在 Android 开发中起什么作用？"先一句话说清它是什么（基本类型的对象表示，支持 null、可进集合），再拿项目场景证明你真用过（接口返回可能为 null 的数值、SharedPreferences 的 int 装箱、集合里的计数）。结尾补一句"包装类比较一律 equals、拆箱警惕 null"，立刻显出深度。
"包装类与自动装箱的底层原理是什么？"按动机、机制、代价三层展开，关键处引用实现，别停在 API 表层。Integer.valueOf 在 -128~127 走缓存池、超出才 new；Long 缓存同理；自动装箱是编译期插入 valueOf、拆箱插入 xxxValue，因此热点路径的反复装箱/拆箱会放大对象分配。再深一层：包装类字段无法享受基本类型的栈上分配与标量替换优化，频繁使用的数值字段用基本类型更省。
"使用包装类与自动装箱时遇到过什么问题？"围绕一次真实踩坑展开：现象（接口返回大值 ID 比较偶发不等）、定位（发现用了 == 且越过了缓存边界）、修复（改 equals + 增加单测覆盖边界值）、验证（用 127/128/ Integer.MAX 三组断言）。复现不了的修复等于赌博，验证要提前设计。
"包装类与自动装箱和替代方案相比有什么优劣？"候选方案列全：基本类型省内存、无 null、无装箱开销，但进不了集合、表达不了"缺失"；包装类反之。性能、复杂度、可维护性三项比完，结论要落到场景：持久化与计算用基本类型，集合、JSON 字段、可为空的外部数据用包装类。选型时把"循环里 Long 累加产生海量临时对象"这类代价摆到桌面，再决定怎么用。
缓存池的细节还有一层值得展开：IntegerCache 的上界 127 其实可通过 JVM 参数 -XX:AutoBoxCacheMax= 调整，但下界 -128 是写死的；Boolean 把 TRUE/FALSE 两个常量直接缓存，Byte、Short、Long 则缓存了对应区间（Byte 全范围本就只有 256 个，索性全缓存）。理解这套缓存，就能预判"为什么这段比较有时对、有时错"，而不是靠运气。
拆箱还会和重载决议搅在一起制造歧义。比如有两个重载 f(int) 与 f(Integer)，传入一个 Integer 时选 f(Integer)；但若只有 f(int)，传入 Integer 会被拆箱去匹配——一旦该值为 null，拆箱当场 NPE，而且报错指向调用处整行，不易定位。把"重载 + 装箱"的组合当作高风险写法，在涉及可空包装类的调用处显式处理 null，能避开这一类隐蔽故障。
放到 Android，Parcel 跨进程传递基本类型时也会经历装箱/拆箱，频繁传递大量数值若全用包装类，序列化与反序列化的对象分配会放大；此外 SQLite、SharedPreferences 这类持久化接口返回的多是基本类型或需要显式拆箱的包装，读取后立刻做 null 判空再拆箱是基本素养。把这些上下文串起来，包装类与自动装箱就不再是孤立的小知识点，而是一条贯穿"内存—类型—持久化"的实线。
还有一处和 equals/hashCode 相关的纪律：两个 Integer 只有当类型相同且值相等时 equals 才为 true——new Integer(1).equals(new Long(1)) 是 false，因为类型不同。这提醒在混用不同数值包装类做比较、或放进 HashMap 当键时，必须保证 key 的类型一致，否则明明"数值一样"却被判为不同键，集合行为会诡异地出错。把"包装类比较先确认类型再 equals、热点路径用基本类型"两条记牢，这道题在实战里就基本不会栽跟头。
给正在准备面试的你
包装类与自动装箱看懂只是第一步，动手跑通一遍再复盘，记忆才算扎实。面试中关于这题，关键是从原理、应用、踩坑三个层面给出有深度的回答，而不是列两个 API。
再补一条工程经验：写一段单测演示 Integer 缓存边界行为（127/128 用 == 与 equals 的对比），并把它固化进团队的编码规范，能让同类故障在 code review 阶段就被拦下。
复习时别孤立刷题：泛型通配符与 PECS、extends 与 super 的边界这些考点从来不是孤立的，边界清了才稳。
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。你的支持就是这个系列持续更新的动力。
「Android软件开发面试·从入门到精通」连载系列
上一篇：枚举-enum：不止是常量集合
下一篇预告：Object-通用方法：equals、hashCode-与-clone-契约
有任何问题欢迎在评论区留言交流。
