Integer==的缓存陷阱：-128到127背后的IntegerCache设计
Integer==的缓存陷阱：-128到127背后的IntegerCache设计
适读人群：Java初中级开发者、有过Integer比较踩坑经历的后端工程师 | 阅读时长：约12分钟 | 文章类型：原理剖析+踩坑实录
开篇故事
去年年底，我们团队的小王做了一个积分系统的优惠券模块。逻辑说起来很简单：用户领券之后，判断领取数量是否超限。他写了一段大概这样的代码：
Integer userCount = getUserCouponCount(userId); // 从缓存取，返回Integer
Integer limitCount = config.getLimit(); // 从配置中心取，返回Integer
if (userCount == limitCount) {
throw new BusinessException("已达领取上限");
}测试环境跑得好好的。上线之后，客服那边开始陆续反馈：有用户已经领了100张券了，系统却一直放行。
我们排查了半天，最开始以为是Redis缓存没刷新，后来怀疑是配置中心取值有问题，折腾了两个多小时。最后是我看了一眼代码，问了一句："小王，你这个==比的是什么？"
小王愣了一下，说："比的是数值啊……"
我说："Integer对象，==比的是引用，不是数值。"
他脸一下就红了。
当然，这个问题不完全是"用了=="这么简单。更有意思的是：在测试环境，限制数量是10，而生产上是100。测试环境那个配置值恰好在-128到127之间，所以==比较居然是true，没报问题。一上生产，100虽然也在范围内，但getUserCouponCount返回的是从Redis反序列化出来的对象，并不走IntegerCache，所以两个Integer对象引用不同，==永远是false。
这个案例把IntegerCache的坑展现得淋漓尽致。今天我就把这背后的东西彻底说清楚。
一、问题的根源：Integer不是int
先把最基础的事说清楚。Java里有两种整数类型：
int：基本类型，存的是值本身，在栈上（或作为对象字段在堆上），没有对象引用的概念Integer：包装类型，是一个对象，有对象头，有引用
当你用==比较两个Integer对象时，比较的是堆上的内存地址，而不是里面存的数值。这是Java对象比较的基本规则。
Integer a = new Integer(100);
Integer b = new Integer(100);
System.out.println(a == b); // false，两个不同对象
System.out.println(a.equals(b)); // true，数值相等这个大家一般都知道。但问题来了：
Integer a = 100;
Integer b = 100;
System.out.println(a == b); // true ???为什么这里是true？因为这两行用了自动装箱，而自动装箱背后调用的是Integer.valueOf(int)，而valueOf里有一个缓存机制。
自动装箱的真相
Integer a = 100; 这行代码，编译器会把它转换成：
Integer a = Integer.valueOf(100);Integer.valueOf的源码（JDK 17）：
public static Integer valueOf(int i) {
if (i >= IntegerCache.low && i <= IntegerCache.high)
return IntegerCache.cache[i + (-IntegerCache.low)];
return new Integer(i);
}逻辑很清楚：如果值在缓存范围内，就从缓存数组里取；否则新建一个Integer对象。
所以Integer a = 100和Integer b = 100，拿到的是同一个缓存对象，==自然是true。
二、IntegerCache的设计原理
缓存的边界值
默认情况下，IntegerCache缓存的范围是 -128 到 127。这个设计来自Java语言规范（JLS 5.1.7），规范明确要求：
如果 p 的值是 -128 到 127 之间的 int，那么自动装箱产生的 Integer 对象必须是同一个对象。
为什么选这个范围？主要是工程上的权衡：
- 字节范围（-128到127）是最常见的整数使用场景（循环计数、状态码、小数量）
- 缓存太大会浪费内存，太小则命中率低
IntegerCache的内部实现
private static class IntegerCache {
static final int low = -128;
static final int high;
static final Integer[] cache;
static Integer[] archivedCache;
static {
// 高位可以通过JVM参数配置
int h = 127;
String integerCacheHighPropValue =
VM.getSavedProperty("java.lang.Integer.IntegerCache.high");
if (integerCacheHighPropValue != null) {
try {
h = Math.max(parseInt(integerCacheHighPropValue), 127);
h = Math.min(h, Integer.MAX_VALUE - (-low) - 1);
} catch (NumberFormatException nfe) {
// 格式不对就用默认127
}
}
high = h;
// ...初始化cache数组
}
}有一个很多人不知道的事：缓存上限可以通过JVM参数调整：
-XX:AutoBoxCacheMax=500或者：
-Djava.lang.Integer.IntegerCache.high=500设置之后，0到500的Integer也会被缓存，==比较也会是true。但下限永远是-128，不能改。
执行流程
三、完整代码实验
实验一：验证缓存边界
package com.laozhang.trap.integer;
/**
* 验证 IntegerCache 缓存边界
* 运行环境：JDK 8+
*/
public class IntegerCacheBoundaryTest {
public static void main(String[] args) {
// 边界值测试
System.out.println("=== 缓存范围内 ===");
Integer a1 = -128;
Integer b1 = -128;
System.out.println("-128 == -128: " + (a1 == b1)); // true
Integer a2 = 127;
Integer b2 = 127;
System.out.println("127 == 127: " + (a2 == b2)); // true
System.out.println("\n=== 缓存范围外 ===");
Integer a3 = -129;
Integer b3 = -129;
System.out.println("-129 == -129: " + (a3 == b3)); // false
Integer a4 = 128;
Integer b4 = 128;
System.out.println("128 == 128: " + (a4 == b4)); // false
System.out.println("\n=== equals 不受影响 ===");
System.out.println("128.equals(128): " + a4.equals(b4)); // true
System.out.println("\n=== new Integer 绕过缓存 ===");
// 注意：JDK 9+ 已废弃 new Integer()，但仍然可用
@SuppressWarnings("deprecation")
Integer a5 = new Integer(100);
@SuppressWarnings("deprecation")
Integer b5 = new Integer(100);
System.out.println("new Integer(100) == new Integer(100): " + (a5 == b5)); // false
// 正确做法：always use equals
System.out.println("\n=== 正确做法 ===");
Integer x = 200;
Integer y = 200;
System.out.println("equals比较: " + x.equals(y)); // true
System.out.println("intValue比较: " + (x.intValue() == y.intValue())); // true
}
}实验二：模拟生产事故场景
package com.laozhang.trap.integer;
import java.util.HashMap;
import java.util.Map;
/**
* 模拟积分领券系统中的 Integer == 陷阱
* 还原小王踩过的那个坑
*/
public class CouponLimitTrap {
// 模拟从Redis反序列化拿到的用户领券数（新建对象，不走缓存）
private static Integer getUserCouponCountFromRedis(long userId) {
int count = fetchFromRedis(userId);
// 模拟JSON反序列化：new Integer(count)，不走valueOf缓存
return new Integer(count); // 故意用new，模拟反序列化行为
}
// 模拟从配置中心获取限制数量
private static Integer getLimitFromConfig() {
// 假设配置的是100
return Integer.valueOf(100); // 走valueOf，在缓存范围内走缓存
}
@SuppressWarnings("deprecation")
public static void main(String[] args) {
long userId = 10001L;
// 场景1：限制为10（测试环境），两个都走缓存
Integer countScenario1 = Integer.valueOf(10); // 缓存对象
Integer limitScenario1 = Integer.valueOf(10); // 同一缓存对象
System.out.println("测试环境（限制=10）：");
System.out.println(" count == limit: " + (countScenario1 == limitScenario1)); // true，测试通过
System.out.println(" count.equals(limit): " + countScenario1.equals(limitScenario1));
// 场景2：限制为100（生产环境），count来自反序列化
Integer countScenario2 = new Integer(100); // 反序列化，新对象
Integer limitScenario2 = Integer.valueOf(100); // 配置中心，缓存对象
System.out.println("\n生产环境（限制=100，count来自Redis反序列化）：");
System.out.println(" count == limit: " + (countScenario2 == limitScenario2)); // false！！！陷阱
System.out.println(" count.equals(limit): " + countScenario2.equals(limitScenario2)); // true，正确
// 正确的判断方式
System.out.println("\n--- 正确实现 ---");
if (countScenario2.equals(limitScenario2)) {
System.out.println("已达领取上限，抛出异常");
}
// 或者拆箱比较
if (countScenario2.intValue() >= limitScenario2.intValue()) {
System.out.println("已达领取上限（intValue方式）");
}
}
private static int fetchFromRedis(long userId) {
// 模拟从Redis取到的值
return 100;
}
}四、踩坑实录
坑1：反序列化/RPC调用绕过valueOf缓存
报错现象：
业务逻辑判断失效，数值明明相等，== 比较却是false具体表现是：日志里能看到两个Integer打印出来都是128，但if (a == b)就是不进去。
根本原因：
JSON反序列化（Jackson/Fastjson）在把JSON数字转成Integer时，并不一定走Integer.valueOf，有时直接new Integer(value)。Dubbo等RPC框架反序列化时也有类似情况。缓存范围外的值，每次都是新对象。
具体解法：
// 错误
if (remoteResult.getStatus() == LocalStatus.ACTIVE.getCode()) { ... }
// 正确方式1：equals
if (remoteResult.getStatus().equals(LocalStatus.ACTIVE.getCode())) { ... }
// 正确方式2：拆箱（注意NPE风险）
if (remoteResult.getStatus() != null &&
remoteResult.getStatus().intValue() == LocalStatus.ACTIVE.getCode()) { ... }坑2：Long同样有类似缓存，但范围相同
报错现象：
Long id1 = 100L;
Long id2 = order.getUserId(); // 从数据库取出，Long类型
System.out.println(id1 == id2); // 有时true有时false根本原因：
Long也有LongCache，范围同样是-128到127。但数据库ID通常是大数字，会超出缓存范围。
具体解法：
Long、Short、Byte的包装类都有类似缓存，统一原则：包装类型比较一律用equals，不用==。
// 数据库ID比较
if (userId.equals(order.getUserId())) { ... }
// 枚举code比较（Integer类型）
if (OrderStatus.PAID.getCode().equals(order.getStatus())) { ... }坑3：三目运算符触发拆箱导致NPE
这个坑更隐蔽，跟Integer缓存关联但又不完全一样。
报错现象：
Exception in thread "main" java.lang.NullPointerException
at com.laozhang.trap.integer.AutoUnboxTrap.main(AutoUnboxTrap.java:12)触发代码：
Integer a = null;
int b = condition ? a : 0; // 三目运算符，a被拆箱，NPE根本原因：
三目运算符condition ? Integer : int，由于两侧类型不一致，Java会把Integer拆箱成int。如果Integer是null，拆箱时调用null.intValue()，抛NPE。
具体解法：
// 方式1：统一为Integer类型
Integer b = condition ? a : Integer.valueOf(0);
// 方式2：提前null检查
int b = (a != null) ? a.intValue() : 0;
// 方式3：Java 8+ Optional
int b = Optional.ofNullable(a).orElse(0);坑4：switch对Integer的隐式拆箱
Integer status = getOrderStatus(); // 可能返回null
switch (status) { // 这里会拆箱，如果status是null，NullPointerException
case 1: break;
case 2: break;
}根本原因：
switch语句对Integer参数会隐式拆箱，null值直接NPE。
具体解法：
if (status == null) {
// 处理null情况
return;
}
switch (status) {
case 1: break;
case 2: break;
}五、总结与延伸
IntegerCache这个设计本质上是一个享元模式（Flyweight Pattern）的应用——对于常用的小整数，复用同一个对象，避免频繁创建销毁。性能上确实有收益，但也带来了==比较的歧义性。
几个记住就够用的原则：
1. 包装类型比较，永远用equals，不用==
// 写这个
a.equals(b)
// 不写这个
a == b2. 数值比较，优先拆箱
如果你确定两个值都不是null，直接用.intValue()拆出来比较，清晰无歧义：
if (a.intValue() == b.intValue()) { ... }3. 用Objects.equals防NPE
if (Objects.equals(a, b)) { ... }
// 等价于：a == null ? b == null : a.equals(b)4. 在IDE里打开"数值比较使用=="警告
IntelliJ IDEA默认会对Integer的==比较给出警告（黄色波浪线），不要忽略它。
另外，如果你用的是Java 17+，可以考虑启用-XX:AutoBoxCacheMax把缓存上限调高，对于大量使用小数字ID的系统有一定性能提升。但这治标不治本，正确使用equals才是根本。
其实回过头来看，Java在这里的设计并不优雅。C#的值类型有更清晰的语义，Kotlin把可空性放到类型系统里强制处理。Java这种"有时缓存有时不缓存"的行为，确实是个历史包袱。但既然用Java，就得把这个坑记住，不然就像小王那样，生产上让用户多领了几百张券。