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 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。
- 反例：
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，但它们不是同一个对象）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
