Java自动装箱缓存由IntegerCache等实现，-128~127范围复用对象，==比较易出错，应统一用equals()；Float/Double无缓存；三目运算遇null易NPE；高频场景建议显式控制装箱。

Java 中的自动装箱缓存机制，核心是 IntegerCache（以及其他几个包装类的类似缓存），它不是“魔法”，而是明确写在 JDK 源码里的优化策略。理解它，关键在于搞清两点：谁在用、怎么用；踩坑，往往就发生在对缓存边界和 == 比较的误判上。

缓存是谁创建的、什么时候生效

缓存由 Integer.valueOf(int) 方法驱动，而自动装箱（如 Integer i = 100;）在编译后就等价于调用这个方法。JVM 启动时，IntegerCache 静态块会预先创建 -128 到 127（含）范围内的所有 Integer 实例，放进一个静态数组里。之后每次调用 valueOf(100)，直接返回缓存中的那个对象；但调用 valueOf(128)，就会 new 一个新对象。

• 缓存范围固定：Byte、Short、Integer、Long 默认都是 -128 ~ 127；Character 是 0 ~ 127；Boolean 只有 true/false 两个实例
• Float 和 Double 没有缓存机制，每次装箱都新建对象
• 缓存不可关闭，但 Integer 的上限可通过 JVM 参数 -XX:AutoBoxCacheMax=200 扩大（仅影响 Integer，且需在启动时设置）

为什么 == 比较容易出错

因为 == 比较的是引用地址，不是值。缓存让小整数复用对象，所以 Integer a = 127; Integer b = 127; a == b 返回 true；但 Integer c = 128; Integer d = 128; c == d 返回 false——它们是两个不同对象。

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

• 永远别用 == 比较两个包装类变量，除非你 100% 确认它们都在缓存范围内且来源可控
• 统一用 .equals()：它内部先判 null，再拆箱比值，安全可靠
• 如果其中一个操作数是基本类型（如 Integer a = 128; int b = 128; a == b），会触发自动拆箱，此时比较的是值，结果为 true——但这依赖隐式转换，可读性差，不推荐

三目运算符和 NPE 是高发陷阱区

当三目运算符的两个分支类型不一致（比如一个是 int，一个是 Integer），JDK 会统一提升为包装类，再做自动拆箱。一旦其中一个是 null，运行时立刻抛出 NullPointerException。

立即学习“Java免费学习笔记（深入）”；

• 反例：Integer a = null; int result = flag ? a : 0; —— a 为 null 时，试图对 null 调用 intValue()，NPE
• 正确写法：先判空，或统一用包装类并用 .equals() 或 Objects.equals()
• 集合取值也要警惕：Integer val = map.get("key"); int x = val; 如果 key 不存在，val 是 null，这行就崩

什么场景该手动控制，而不是依赖自动装箱

业务代码中，以下情况建议绕过自动装箱，显式处理：

• 需要明确区分“未赋值”和“值为 0”时，用包装类 + 显式判 null，而不是靠自动装箱隐藏逻辑
• 高频循环中创建大量整数对象（如 for 循环里 list.add(i)），若 i 在缓存外，反复 new Integer 会加重 GC 压力；可考虑预缓存或改用原始类型集合（如 Eclipse Collections、Trove）
• 序列化/网络传输场景，避免因缓存导致对象身份混淆（比如两个服务各自缓存了 100，但它们不是同一个对象）