最稳妥解法是用equals()或拆箱比较；==比较的是对象地址而非数值，Integer缓存仅对-128~127间valueOf()创建的对象生效，new Integer()总新建对象，超范围或手动创建时==不可靠。

直接用 equals() 或先转成基本类型再比较，是最稳妥的解法。缓存机制本身不是 bug，而是 JVM 的性能优化设计；真正的问题在于误把引用比较当数值比较用。

理解 == 在 Integer 场景下到底在比什么

== 比较的是两个变量是否指向堆中同一个对象地址，不是数值是否相等。而 Integer 缓存池只对 经由 Integer.valueOf() 创建的对象 生效——自动装箱（如 Integer a = 127;）就走 valueOf，但 new Integer(127) 绕过缓存，每次新建对象。

• -128 到 127 范围内：多次赋值相同值 → 复用缓存池中同一对象 → == 返回 true
• 128 及以上（或 -129 及以下）：每次调用 valueOf → 新建对象 → == 返回 false
• new Integer(x)：无论 x 是多少，都创建新对象 → 和任何缓存对象 == 都为 false

实战中高频踩坑场景与写法对照

这些写法看着相似，行为却完全不同：

• Integer a = 127, b = 127; → a == b 为 true（同缓存对象）
• Integer c = 128, d = 128; → c == d 为 false（两个独立对象）
• Integer e = new Integer(127), f = Integer.valueOf(127); → e == f 为 false（一个新对象，一个缓存对象）
• Integer g = 128; int h = 128; → g == h 为 true（g 自动拆箱成 int 后数值比较）

安全可靠的替代方案

不依赖缓存范围，也不受对象创建方式影响：

• 统一用 g.equals(h)：适用于所有 Integer 间比较，内部已做 null 安全和类型校验
• 显式拆箱后比较：g.intValue() == h.intValue() 或直接 g == h.intValue()（推荐用于确定非 null 场景）
• 集合键值使用时特别注意：HashMap 中 key 用 128 两次，会生成两个不同 key，导致重复插入 —— 这类问题必须靠 equals/hashCode 保证语义正确性，不能靠 ==

进阶控制：按需扩大缓存范围（慎用）

若业务大量使用固定区间（如订单号 0~200），可通过 JVM 参数临时扩展缓存上限：

• 启动参数：-Djava.lang.Integer.IntegerCache.high=200
• 效果：valueOf(180) 开始复用缓存，== 在该范围内可能再次为 true
• 注意：缓存对象在类加载时即常驻堆内存，增大 high 值会多占约 (200 + 128) × 对象大小，低配环境易引发 OOM