Java中Integer缓存池机制导致==比较失效和自动装箱引发性能开销，根源在于valueOf()缓存策略与编译器透明装箱；缓存范围-128~127内==可能为true，范围外或new创建则为false；自动装箱在未命中缓存时产生对象分配与GC压力；拆箱遇null抛NPE；应统一用.equals()比较、性能敏感处用int、解析字符串优先parseInt。
Java 中 Integer 缓存池机制和自动装箱看似便利，实则暗藏两层关键风险：一是 == 比较失效，二是 隐式对象创建带来的性能开销。根源不在语法本身，而在 JVM 对 Integer.valueOf() 的缓存策略与编译器对装箱操作的透明处理。
缓存范围导致的 == 比较陷阱
Integer 默认缓存 -128 到 127（含）之间的整数值。这个范围由 IntegerCache 静态内部类维护，且不可更改（除非通过系统属性 java.lang.Integer.IntegerCache.high 扩展上限）。
- 值在缓存范围内（如 127），
Integer a = 127;实际调用Integer.valueOf(127)，返回缓存池中同一个对象 —— 此时a == b为 true - 值超出范围（如 128），
Integer c = 128;同样调用valueOf(128)，但因未命中缓存，每次都会 new 出新对象 ——c == d为 false - 手动
new Integer(127)绕过缓存机制，无论值多少，都新建对象，==始终为 false
自动装箱引发的性能损耗
自动装箱不是零成本操作。它本质是编译期插入 Integer.valueOf() 调用，而该方法在缓存未命中时会触发对象分配和 GC 压力。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 在循环中频繁装箱（如
list.add(i)），每轮都可能创建新 Integer 实例，百万次迭代即产生百万个短期对象 - 相比直接使用
int，包装类型额外携带对象头、类元数据等，内存占用翻倍以上 - 高并发场景下，若缓存池被大量小整数反复访问，虽不线程安全问题（缓存本身是静态且只读初始化），但频繁分配仍影响吞吐
空指针与拆箱风险
自动拆箱依赖非 null 引用，一旦包装类变量为 null，解包即抛 NullPointerException。
立即学习“Java免费学习笔记（深入）”；
-
Integer num = null; int x = num;→ 运行时报错，等价于num.intValue() - 集合取值、数据库映射字段为 null 时尤其危险，例如
map.get("count")返回 null，直接赋给int就崩 - 该问题与缓存无关，但常与装箱场景共存，属于自动装箱/拆箱机制的连带隐患
规避建议：写法与选型原则
不靠记忆“128”，而靠设计习惯规避陷阱：
- 比较值是否相等，一律用
.equals()，避免==；若确定非 null，可用Objects.equals(a, b) - 性能敏感路径（如算法内循环、高频日志计数）优先用
int，仅在泛型/集合/反射等必须场合才用Integer - 解析字符串数字时，优先选
Integer.parseInt(s)而非Integer.valueOf(s)，前者返回基本类型，无对象开销 - 明确需要缓存行为时，可主动调用
Integer.valueOf(i)；需强制新对象时再用new Integer(i)（但极少必要）
