99%的人忽略了！Java Integer缓存池原来暗藏玄机

一个看似简单的bug

那天下午，我正在调试一个用户积分系统，突然测试同学跑过来：“你这代码有bug！同样的积分值，有时候能正常比较，有时候就失效了。”

我心想：比较两个Integer还能有什么坑？打开代码一看：

Integer score1 = getUserScore(userId1);  // 返回100
Integer score2 = getUserScore(userId2);  // 返回100
if (score1 == score2) {
    System.out.println("积分相等");
} else {
    System.out.println("积分不等");  // 有时候走这里！
}

我傻了，明明都是100，为什么有时候相等有时候不等？这简直像见了鬼一样。

探索之路：从疑惑到恍然大悟

第一次尝试：换个数值试试

我把测试数据改了改，发现了一个奇怪的规律：

• 积分在 -128到127 之间时，== 比较总是正确的
• 超出这个范围，== 比较就开始"抽风"

这时候我想起了Java的一个"隐藏特性"——Integer缓存池。

真相大白：JVM的小心机

原来，JVM为了优化性能，对 -128 到 127 范围内的Integer对象做了缓存。当你创建这个范围内的Integer时，JVM会复用同一个对象实例。

但超出范围后，每次都会创建新的Integer对象，所以 == 比较的是对象引用，自然就不相等了。

// 缓存范围内 - 同一个对象
Integer a = 100;
Integer b = 100;
System.out.println(a == b);  // true

// 超出缓存范围 - 不同对象
Integer c = 200;
Integer d = 200;
System.out.println(c == d);  // false，踩坑了！

踩坑瞬间：生产环境的惊魂一刻

更要命的是，这个bug在开发环境很难发现。为什么？因为我们测试时习惯用小数值，比如1、2、100这种，正好都在缓存范围内！

直到上了生产环境，用户积分动辄几千几万，问题才暴露出来。那天晚上我被紧急叫起来修bug，排查了两个小时才找到原因。

那一刻我深深体会到：细节决定成败，基础知识的盲区就是生产事故的温床。

解决方案：正确的比较姿势

问题找到了，解决就简单了。Integer比较要用 equals() 方法：

// 正确的比较方式
if (score1.equals(score2)) {
    System.out.println("积分相等");
}

// 或者转为基本类型比较
if (score1.intValue() == score2.intValue()) {
    System.out.println("积分相等");
}

经验启示：魔鬼在细节里

这次踩坑让我总结出几个经验：

包装类型的陷阱不只Integer

防坑指南

1. 包装类型比较永远用equals()，这是铁律
2. 能用基本类型就用基本类型，简单直接
3. 代码评审时重点关注包装类型的使用
4. 单元测试要覆盖边界值，别只测小数

深层思考

其实，Integer缓存池体现了JVM设计者的智慧——用空间换时间，缓存常用对象来提升性能。但这个优化对开发者来说却是个隐藏的坑。

这提醒我们：了解底层原理不是为了炫技，而是为了写出更可靠的代码。

写在最后

从那以后，我在代码评审时会特别留意包装类型的使用。也会在新人培训时重点讲解这个坑，毕竟预防胜过治疗。

技术的路上，我们都是在踩坑中成长。重要的不是避免所有的坑，而是要从每个坑里学到些什么，然后帮助后来者少踩一些。

你在项目中遇到过类似的"诡异bug"吗？欢迎在评论区分享你的踩坑经历！

本文转自渣哥https://zha-ge.cn/java/7