为什么 Integer 缓存池默认是 -128 到 127？如何通过启动参数扩大该范围？

Ja va 规范里关于 Integer 缓存的这段设计，看起来像是一道“死记硬背”的面试题，但背后其实藏着不少基于工程实践的精巧权衡。我们先把这个规定拆开看：所有 JVM 都必须保证，用 Integer.valueOf() 的时候，落在 -128 到 127 这个区间内的整数，返回的是同一个对象。

这个数字区间可不是随便拍脑袋定的，背后有非常具体的考量：

• -128 是 byte 类型取值的最左端，也是我们日常代码里负数使用的“实际下限”。你几乎很难找到什么业务场景，需要频繁地在循环或条件判断里跟 -129 这种数值打交道。
• 127 这个上限就更讲究了，它几乎覆盖了你平时用到“小整数”的绝大部分场景——比如循环里的索引、HTTP 状态码（200、404 这种）、枚举的顺序号、数组的长度值、小计数器等等。可以说，99% 的“小整数”都在这扇门以内。
• 只缓存 256 个对象（从 -128 到 127 正好 256 个），内存开销也就几十 KB，几乎可以忽略不计。但你想想，如果把这个范围扩大到 1000，缓存的对象数量几乎翻了两番，带来的性能收益却会急剧下降，性价比很低。

所以，这个范围不是魔法，是典型的“二八法则”在语言规范中的体现。

如何用 JVM 参数扩大 Integer 缓存上限

如果你确实有特殊需求，想扩大这个缓存区间，也可以，但要注意一点：你只能动上限，下限是焊死的。IntegerCache.low 固定是 -128，改不了；只能通过启动参数调整 IntegerCache.high 这个默认值 127。

具体的参数写法有下面两种，推荐用第一种，更直观：

• -Dja va.lang.Integer.IntegerCache.high=200
• -XX:AutoBoxCacheMax=200

用的时候有几个坑得心里有数：

• 如果你设置的值比 127 还小，JVM 会“自作主张”帮你修正回 127，下限保护机制很严格。
• 这个参数只影响 Integer.valueOf(int) 方法和自动装箱（比如你写 Integer a = 180; 这种）。如果你非要用 new Integer(180) 来创建对象，那不好意思，天王老子来了它也是个新对象，跟缓存池没关系。
• 缓存数组在类加载的时候就已经初始化好了，所以这个参数必须在应用启动之前传入，运行时再改是没用的。

扩大缓存范围的实际影响和风险

听起来好像把范围拉大就能一劳永逸解决 Integer 比较的坑，但实话实说，在真实的项目里，几乎没人这么干，也不建议你这么干。

原因很实在：

• 你把缓存上限设到 200，Integer.valueOf(180) == Integer.valueOf(180) 确实会返回 true，看着舒服了。但别忘了，Integer.valueOf(180) == new Integer(180) 依然铁定是 false。这种“一半真一半假”的语义混乱，反而会让代码更不可预测。
• 不同的运行环境（测试环境 vs 生产环境）、不同的 JDK 版本、不同的 JVM 参数配置，都会导致缓存行为不一致。今天在一个环境里通过的测试，明天换个地方就挂了，这种坑踩一次就够了。
• 哪怕你把上限设成 500，也堵不住所有的漏洞。只要有人写了一句 Integer a = 1000;，这个陷阱依然会准确无误地出现。你永远没法靠单纯扩大缓存范围来“根治”这个问题。

所以说，与其在参数上做文章，不如把代码习惯本身调整过来。最稳定、最不费脑子的写法就两条：比较值的时候就用 .equals()，如果和基本类型混用，就依赖自动拆箱机制。别再把 == 当成万能的数值比较工具来用了——这才是从根上解决问题的办法。