Java 128陷阱详解：Integer缓存机制、自动装箱与equals比较避坑指南

128陷阱这个名字，Java 服务端开发基本都躲不过。它说的不是某个安全漏洞，也不是网络协议问题，而是 Integer 自动装箱之后用 == 比较时出现的“薛定谔式”结果：同样的代码，数字换成 100 是 true，换成 128 就变成 false。很多人第一次遇到时都会怀疑 JVM 是不是有问题，或者编译器是不是抽风了。今天我就把这件事从现象到源码、从踩坑到修复彻底说清楚，同时给你一套以后写代码不会再犯同类错误的方案。

1. 线上翻车现场：为什么 status 等于 128 时总走错分支

先说一个真实场景。早几年我做过一个交易对账系统，上游返回的订单状态是 Integer 类型，代码里有一行判断：

java复制if (order.getStatus() == 128) {
    // 走“对账异常”分支
}

当时同事写这行代码的时候，状态值是 128 的情况一直没触发过，所以线上跑得很正常。直到某天大促期间真的来了一笔状态为 128 的订单，系统没有走进这个分支，反而走到了默认分支，导致告警没上报、补偿任务没触发，最后靠日志捞数据人工处理才平掉。

排查了很久，最后定位到这行 == 比较上。单看语法没什么问题，order.getStatus() 返回的是 Integer 对象，右边的 128 是 int 基本类型，理论上两者比较时会把对象拆箱成数值。但真正的坑还有一层：getStatus() 的值在序列化和反序列化之后是一个新的 Integer 对象，而左边的对象和右边经自动装箱产生的对象不是同一个引用。

1.1 一段让所有人沉默的最小复现代码

我后来把问题抽成了一段最简短的代码：

java复制Integer a = 128;
Integer b = 128;
System.out.println(a == b); // false

Integer c = 127;
Integer d = 127;
System.out.println(c == d); // true

如果你没了解过 Integer 缓存，看到这个输出会觉得离谱：127 引用相等，128 却不相等。更离谱的是，System.out.println(a == b) 的结果并不是因为 128 > 127 这个数学大小，而是因为自动装箱流程在背后偷偷做了不同的事。

把数值往两边扩一下，你会发现规律更明显：

java复制Integer x = -128;
Integer y = -128;
System.out.println(x == y); // true

Integer m = -129;
Integer n = -129;
System.out.println(m == n); // false

负数和正数同样存在边界，两边都有一条清晰的分界线：-128 到 127 这一段是“安全区”，在这个范围内的同值装箱返回同一个实例；超出这个范围后，每次装箱都会 new 一个新对象。上线是 128，所以大家习惯把这种现象叫做 128 陷阱。它真正的本质是对象引用比较和数值比较混用后造成的幻觉。

1.2 同样的数值，换个写法结果又不一样

这个陷阱最迷惑人的地方在于：它不是“只要等于 128 就 false”。换成下面这些写法，结果会完全相反。

java复制Integer a = 128;
int b = 128;
System.out.println(a == b); // true

Integer c = new Integer(128);
Integer d = new Integer(128);
System.out.println(c == d); // false

第一条语句返回 true，是因为当 == 的一侧是基本类型 int 时，编译器会强制把另一侧的 Integer 拆箱成 int，然后比较 128 和 128 是否数值相等。这已经不是引用比较，而是基本类型数值比较。

第二条语句返回 false 更直白：new Integer(128) 明确指出每次都要新建一个对象，跟缓存无关。所以在排查“为什么同样写 == 有人对有人错”的时候，先分清楚参与比较的双方到底是对象还是基本类型，这比背结论重要得多。

第五行其实要特别强调。如果 Integer g 是 null，执行 g == 128 时 Java 会先拆箱，也就是调用 g.intValue()，此时直接抛 NullPointerException。很多人只记住了“对象和基本类型比较是安全的”，却没意识到 null 拆箱是另一颗雷。

2. IntegerCache 与装箱机制：分界线为什么锚定在 128

想彻底搞懂 128 陷阱，不能只停留在“缓存了 -128 到 127”这个结论上，还得知道这个缓存是谁建的、什么时候建的、从哪个方法进入的。

2.1 控制合流的入口：valueOf 方法

Java 里写 Integer a = 128，编译器并不会真的创建一个普通对象然后赋给变量，它会翻译成：

java复制Integer a = Integer.valueOf(128);

这个 valueOf 就是一切分界线的入口。打开 JDK 源码，Integer.valueOf 的逻辑如下：

java复制public static Integer valueOf(int i) {
    if (i >= IntegerCache.low && i <= IntegerCache.high)
        return IntegerCache.cache[i + (-IntegerCache.low)];
    return new Integer(i);
}

不到十行代码，却把 128 陷阱的关键全说透了。valueOf 不是无脑创建新对象，而是先看看传入的数值是否落在缓存区间内。如果在，就直接从数组里取预先建好的对象返回；如果不在，才走 new Integer(i) 这条路。因此“128 为什么 false”的答案就是：128 超出了 IntegerCache.high 的默认值 127，每次调用都会创建新对象，两个对象引用自然不等。

2.2 缓存数组是在类加载时默默造好的

IntegerCache 是 Integer 里的一个私有静态内部类。它的初始化在 Integer 类首次被使用时触发，也就是说，在你第一次执行任何与 Integer 相关的代码时，JVM 可能已经把 cache 数组填好了。

java复制private static class IntegerCache {
    static final int low = -128;
    static final int high;
    static final Integer cache[];

    static {
        int h = 127;
        high = h;
        cache = new Integer[(high - low) + 1];
        int j = low;
        for (int k = 0; k < cache.length; k++)
            cache[k] = new Integer(j++);
    }
}

上面是省略了配置项之后的简化版源码。真实 JDK 中还会读取一个系统属性来做扩展，但默认行为和这段代码一致：从 -128 开始循环，一路创建到 127，一共 256 个对象，全部放在数组里。这些对象从 JVM 启动那一刻开始就一直存活，不会随便被 GC 回收。

当代码里写 Integer c = 100 时，valueOf(100) 发现 100 在区间内，于是直接返回数组里预先创建好的那个对象。无论你写多少次 Integer b = 100，只要都走自动装箱，拿到的就是同一个引用，所以用 == 比较是 true。写成 128 时越界，每次都 new，自然两个对象的堆地址不同。

这个“把常用小整数预先创建并复用”的思路，本质上和线程池、连接池很像：高频使用的对象不要频繁创建，而是常驻内存循环使用。数值在业务代码里最多被使用的往往是 0、1、状态码、错误码这些两位数或三位数，所以选择低位区间的整数做缓存，收益最高，内存代价也最低。

2.3 为什么不是缓存到 1000 或者缓存到 10000

刚接触这个机制的人常会问：既然缓存这么好，为什么上限不设高一点？我个人的理解是，这需要在“命中率”和“内存浪费”之间取平衡。想要覆盖到 10000，就意味着类加载时要一次性创建一万多个 Integer 对象，即使很多值根本不会被用到，内存也一样被占据。要覆盖到 128，只需要 256 个对象，成本几乎忽略不计。于是默认值选择了和 byte 范围对齐的 -128 到 127。

还有一个容易被忽略的小点：Java 中这一机制不止服务于自动装箱，很多容器和框架内部也会调用 Integer.valueOf。比如把基本类型放进集合时，List<Integer> 的 add 操作同样会经过这个方法。也就是说，就算你不直接写 Integer x = 128，集合里的 Integer 也很可能从缓存里取得，所以比较时一样会踩坑。

2.4 缓存区间不是绝对不能改

前面说“默认值”，意味着它有被调整的空间。在部分 JDK 实现中，可以通过 -Djava.lang.Integer.IntegerCache.high=xxx 或类似参数提高缓存上限。比如你把上限改成 200，那么 Integer a=128; Integer b=128; a==b 就会变成 true。

但这绝不意味着你可以靠调大缓存来解决代码问题。第一，不是所有 JDK 版本和厂商实现都支持这个参数；第二，遇到 new Integer(128) 一样会创建新对象；第三，缓存范围改了之后，代码可读性和部署环境强相关，别人在默认环境下无法复现你的行为，排障更混乱。真正值得做的只有一件事：不要依赖缓存边界来判断引用相等。

3. 128 陷阱远远不止 Integer 一个坑

很多人在解决了 Integer 的问题后，觉得万事大吉，却不知道 Long、Short、Character、Boolean 这些包装类里也藏着类似机制，只是名字不叫 128 陷阱，表现形式却惊人相似。

3.1 Long 和 Short 的缓存边界几乎一样

Long 同样维护了一个 LongCache， 缓存范围也是 -128 到 127。也就是说，Long a=127L; Long b=127L; a==b 是 true，Long a=128L; Long b=128L; a==b 是 false。很多人写主键 ID 时喜欢用 Long，然后在一个两个对象之间做 == 判断，一旦 ID 超过 127，同样会踩到完全相同的雷。

java复制Long id1 = 1000L;
Long id2 = 1000L;
System.out.println(id1 == id2); // false

这个问题在实际业务里比 Integer 更隐蔽，因为 ID 天然会很大，几乎不可能一直待在 -128 到 127 里。有些小型项目前期数据量小，ID 没超过 127，测试也一直通过，等数据量涨上去后故障才集中爆发。

Short 也一样。ShortCache 的范围同样是 -128 到 127，因为 short 的可表示范围更大，缓存只覆盖了其中一小段。

3.2 Character 缓存的是 0 到 127

Character 不是一个数值型包装类，但它也做了类似缓存。范围是 0 到 127，对应 ASCII 码表里的字符。所以用 Character 变量存普通英文字符时，很多同值比较会返回 true；一旦字符码表位置超过 127，引用比较大概率返回 false。

java复制Character c1 = 'a';
Character c2 = 'a';
System.out.println(c1 == c2); // true

Character c3 = '中';
Character c4 = '中';
System.out.println(c3 == c4); // false

类似地，Byte 因为本身取值范围就是 -128 到 127，缓存相当于覆盖了全部取值。Boolean 则更特殊，它内部只有 TRUE 和 FALSE 两个静态实例，所以任何 true 值的自动装箱返回的都是同一个对象。Float 和 Double 没有被放入缓存，因为它们小数数量太多，做整数区间缓存没有意义。

下表是我整理的一份快速对照表，可以用在企业代码规范和面试复习里：

3.3 包装类放进集合就安全吗

这个问题很多人问过我：既然 HashMap 的 key 是 Integer，那找 key 时是不是也会掉进 128 陷阱？答案是不会。因为 HashMap 查 key 时走的是 hashCode 和 equals，不是 ==。Integer.equals 被设计为比较两个对象的内部 int 值，所以哪怕 key 是 new Integer(128) 和另一个 Integer.valueOf(128)，只要数值相等也能命中。

不过“集合里安全”不代表“集合相关的业务代码里安全”。有人会写 map.get(someKey) == targetValue，左边是 Integer，右边是 Integer，此时仍然可能触发引用比较。你只是把 128 陷阱从 key 查找转移到了 value 比较环节上。更稳的做法是取出集合值后，不要让它和另一个包装对象黏在 == 两侧。

4. 这个坑在业务代码里是怎么反复咬人的：真实复盘

接下来聊聊我实际排查过的几个案例。这些案例的共性不是技术有多复杂，而是代码表面看起来没有任何问题，测试甚至在小数据量下全绿，只有压测或特定数据出现时才暴露。

4.1 主键 ID 比较“时好时坏”

某个后台管理项目在导出报表时，需要判断两条记录是否属于同一用户。代码大概是：

java复制if (userA.getId() == userB.getId()) {
    // 合并用户数据
}

当时建表用的是自增主键，早期测试数据 ID 只有几十，所以 idA == idB 基本都能正确命中。等测试环境造了一批超过 128 的数据后，合并功能突然失灵，排查定位到 getId() 返回的是 Long。同一个用户的两条记录明明 ID 相同，却因为两个不同对象引用而不相等。

修复时把 == 改成了 Objects.equals：

java复制if (Objects.equals(userA.getId(), userB.getId())) {
    // 合并用户数据
}

Objects.equals 是 JDK 7 开始提供的工具方法，它内部先做 null 判断，然后调用第一个参数的 equals。如果两个参数都为 null，返回 true；一个是 null 另一个不是，返回 false；两边都有实际值，就比较值是否相等。在业务代码里比手写 a.getId().equals(b.getId()) 更稳，因为不需要担心某个对象为 null 导致空指针。

4.2 状态码判断在新旧数据切换后翻车

还有一个定时任务项目，状态字段用 Integer 保存，不同模块间通过 MQ 传递。消费者拿到消息后做判断：

java复制Integer newStatus = (Integer) message.getData().get("newStatus");
if (newStatus == STATUS_SUCCESS) {
    // 执行成功回调
}

这里的 STATUS_SUCCESS 是一个 Integer 常量，定义在某个类里。从 MQ 反序列化出来的 newStatus 是一个全新对象，而常量 STATUS_SUCCESS 在类加载时也可能已经走缓存。如果状态值大于 127，== 永远返回 false，成功回调永远不执行，甚至没有任何异常提示。

这种问题的迷惑性极强：任务不报错、日志显示消息已消费，只有业务结果不对。我当时是靠打印每个关键判断节点的布尔结果，才把问题从一堆正常日志里挑出来。

4.3 轻量级框架里的枚举比较陷阱

还有一类典型场景是，我们自研了一个简单的状态机，内部用 Integer 作为状态流转的 key。每次流转时比较当前状态和前置条件：

java复制if (stateReference.getState() == preState) {
    // 放行
}

因为状态值都是用 Integer 定义，测试时只试了 0、1、2 这几个数字，完全正常。后来新增了 200 号状态，任何从 200 开始的流转全部被拦截。真正的坑在于，代码如果一直只在低值区间活动，可能上线几年都不触发；一旦业务叠加到高位枚举值，就毫无征兆地坏掉。遇到这种问题，靠简单地“把 128 记住”解决不了，因为业务状态码可能随时扩展到几百上千。

所以我在团队里定了条雷打不动的规矩：凡是对象和对象做等值判断，一律使用 equals 或 Objects.equals；只有基本类型和基本类型之间，才允许使用 ==。

5. 解决 128 陷阱不靠记边界，靠一套能长期执行的规矩

如果你想在团队里推行一套机制，让仓库里的代码不再踩 128 陷阱，只靠每个人读这篇博客是不够的，需要把“人治”变成“规治”。

5.1 编译期视觉检查清单

我在代码评审时，看到 == 会比较严厉地检查参与比较的两个变量。只要任何一侧是包装类型，就优先考虑改成：

• Objects.equals(a, b)：最通用，推荐写默认。
• a.equals(b)：需要先确保 a 不为 null，否则有空指针风险。
• a.intValue() == b.intValue()：确定两边都非 null 时可用，逻辑更直白。
• 如果业务场景允许，干脆在实体里用基础类型 int 或 long，让 RPC 不传值时有默认值兜底。这样做能从源头避免 null 拆箱问题，不过要结合字段是否允许为 null 来决定。

最简单的判断方式是：一眼看过去，如果 == 的左边和右边没有一个是 int、long、double 这类基础关键字，就要默认它是对象引用比较，不允许轻易放行。

5.2 用边界测试锁住回退

另一个值得做的工作，是把边界条件写进单元测试。很多代码的问题本质上是没测过 127、128、-129 这几个点。针对任何涉及包装类型比较的方法，可以写一个参数化测试：

java复制@ParameterizedTest
@CsvSource({
    "-129, false",
    "-128, true",
    "127, true",
    "128, false"
})
void testIntegerCacheBoundary(int value, boolean expected) {
    Integer a = value;
    Integer b = value;
    assertEquals(expected, a == b);
}

这个测试看起来像是在验证 JVM 缓存行为，但它真正的价值在于：如果你哪天把某段代码从 == 改成 equals，这个测试会立刻变成全 true，等于给你一个信号，确认“之前的引用比较已经被彻底替换为值比较”。同理，也可以测试 Objects.equals(a, b) 永远为 true，确保核心路径不会再回退到引用比较。

5.3 静态检查规则兜底

如今绝大多数 IDE 和代码检查工具都能识别包装类用 == 比较的问题。比如 SonarJava 规则 S4973，专门检查“Strings and Boxed types should be compared using equals()”。开启后，只要有人写了 Long value1 == value2 这种代码，CI 阶段就会亮黄。你可以把这条规则设为 error，不让它进入主分支。

不过要说明一点，这类自动检查也会有误报。当一边是基本类型、一边是包装类型时，== 是安全且合规的，工具不会误伤。比如 Integer a=128; int b=128; a==b，规则看到一侧是 int 就不会抱怨。这也是我认为静态检查比人工评审更可靠的原因：它会根据语义区分，而不是一刀切禁止 ==。

5.4 如果只想记住一个结论

把前面各种情况高度浓缩一下，就是三句话：

• 两个包装类型用 ==，比较的是引用，不是数值。
• 包装类型与基本类型用 ==，会触发拆箱，比较数值。
• 不要依赖缓存边界做对象引用判断，128 是不是 false、127 是不是 true，都只是默认实现的细节。

只要你的代码规范接受了这三句话，128 陷阱在团队里基本就没有生存空间了。

6. 我在踩完几次坑后留下的个人习惯

最后分享一下我现在写 Java 代码时比较固定的几个习惯。这些习惯不全是解决 128 陷阱本身，更多是把同类隐患提前消灭掉。

第一，实体字段里不再随便用 Integer 承载“可能为空”的数值。如果确定某个字段不能让数据库出现 null，我优先用基础类型 long 或 int。只有像状态字段可能为“未设置”时才用包装类型，但到了比较环节，一定是 Objects.equals 或者 Optional.ofNullable(...).map(...) 这类安全操作。

第二，凡是收到下游 RPC、MQ 传过来的对象，我不会假设它内部的值一定走了某个缓存区间。反序列化几乎总会创建新对象，所以对“这个值一定在 -128 到 127 之间”这类假设，我看都不看。代码里只要出现 a.getX() == b.getY()，第一反应就是打回。

第三，对状态值、错误码这类有限集合，能用枚举就不用 Integer 常量。我自己在后来新起的项目里，把订单状态改成枚举后，团队再没出现过“状态 128 不匹配”的问题。枚举本身是单例，== 比较安全，而且可读性也好过魔法数字。

第四，如果 Integer 是第三方接口返回的，并且你只能拿它和其他变量比较，那就不妨多写一步转换，把对象赋值给 int 或 long 基本变量后再比较。比如：

java复制Integer remoteStatus = remoteResponse.getStatus();
int status = (remoteStatus == null) ? -1 : remoteStatus;
if (status == 128) {
    // 业务逻辑
}

这段代码一眼就能看清意图：先把对象转成基础类型，再去和基本类型比较，不存在任何引用比较的歧义。虽然多写一行，但对后来维护的人极其友好。

我自己经历这个坑的次数不算少，每次都是同一个结论：Java 的缓存设计本身没有错，错的是代码里“值比较”和“引用比较”的混用。128 陷阱只是一个引子，它背后是一种更普遍的代码习惯问题。只要你在所有包装类型的相等判断上都使用同一套安全策略，这个坑就不会再在半夜把你叫起来。