Integer缓存范围详解：-128到127

Java中Integer等包装类的缓存机制（-128到127）导致用==比较时结果“看似随机”：范围内的值因复用同一对象而返回true，范围外则新建实例使==返回false；这并非bug而是JVM规范要求，且Boolean、Byte、Character、Short、Long也有类似但范围各异的缓存，唯独Float和Double完全无缓存；真正安全的做法是统一使用equals()或优先采用基本类型，尤其在处理可能为null的场景（如数据库映射字段）时，可避免空指针异常——缓存本身很稳定，陷阱往往源于开发者对“相等”的直觉误判。

为什么 Integer 用 == 比较有时对、有时错

因为 Integer 在 -128 到 127 范围内会复用缓存对象，超出范围则每次新建实例。所以 == 实际比较的是引用是否相同，不是值是否相等。

常见错误现象：Integer a = 100; Integer b = 100; System.out.println(a == b); // true，但换成 200 就输出 false。

• 这是 JVM 规范要求的行为，由 Integer.valueOf(int) 实现，不是 bug
• 编译期字面量（如 Integer c = 100;）也走 valueOf，所以同样受缓存影响
• 手动调用 new Integer(100) 绕过缓存，但已废弃，且必然导致 == 为 false

Integer.valueOf() 的缓存范围能改吗

能，但不建议。JVM 启动参数 -Djava.lang.Integer.IntegerCache.high=256 可扩大上限，但只影响当前 JVM 实例，且必须在类加载前设置。

使用场景极少：比如遗留系统里大量 == 比较且无法改代码，又恰好集中在某个略超 127 的固定值上。

• 下限 -128 固定不可调
• 修改后不会影响已加载的 Integer 类，需确保 Integer 尚未被初始化（通常意味着得在 main 前设置）
• 多数框架（Spring、Hibernate）或容器（Tomcat）会提前触发 Integer 加载，此时参数无效

哪些包装类也有类似缓存

只有 Boolean、Byte、Character（\u0000–\u007f）、Short、Integer 和 Long 的 valueOf 方法有缓存，但范围各不相同。

性能影响很小，但语义风险一致：依赖 == 比较包装类，就等于依赖缓存策略。

• Boolean 缓存 true 和 false 两个实例（总是安全）
• Character 只缓存 0–127（即 ASCII 可见字符），不是 -128–127
• Short 和 Long 缓存范围也是 -128 到 127，不可配置
• Float 和 Double 没有缓存，valueOf 每次返回新对象

实际编码中怎么避免踩坑

统一用 .equals() 比较包装类值，或者优先用基本类型 int。

容易被忽略的点：自动拆箱可能抛 NullPointerException，尤其当变量可能为 null 时。

• if (a != null && a.equals(b)) 比 a == b 更安全，也比 a.intValue() == b.intValue() 更健壮
• 数据库映射字段（如 MyBatis 返回 Integer）常为 null，直接 == 或拆箱极易 NPE
• Lombok 的 @Data 生成的 equals() 默认对包装类用 Objects.equals(a, b)，已处理 null 安全

缓存机制本身很稳定，真正复杂的是人对“看起来一样”的直觉判断——特别是当测试数据恰好落在 -128–127 里，而生产数据飘出去之后。

好了，本文到此结束，带大家了解了《Integer缓存范围详解：-128到127》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！