Java规范强制要求Integer缓存-128~127，因该范围覆盖99%高频使用场景、内存开销小（仅256个对象），且下限-128对应byte最小值，上限127满足状态码、计数等常见需求。
Integer 缓存范围为什么是 -128 到 127
这不是随意选的数字，而是 Java 语言规范（JLS）强制要求的最小缓存区间。所有 JVM 实现都必须保证 Integer.valueOf() 对 -128 到 127（含）之间的整数返回同一对象实例。
选择这个范围的核心依据有三点：
-
-128是byte类型的最小值，也是日常负数使用中实际下限——极少有业务逻辑需要频繁用到小于 -128 的整数 -
127覆盖了绝大多数高频场景：循环索引、HTTP 状态码（如 200、404）、枚举序号、数组长度、小计数器等，99% 的“小整数”都在此内 - 缓存
256个对象（127 − (−128) + 1）内存开销极小，约几十 KB；若扩大到 1000，缓存对象数翻倍，收益却急剧下降
如何用 JVM 参数扩大 Integer 缓存上限
只能调高上限，不能改下限：IntegerCache.low 固定为 -128，不可修改；IntegerCache.high 默认 127，可通过启动参数调整。
两种等效写法（推荐前者）：
-Djava.lang.Integer.IntegerCache.high=200-XX:AutoBoxCacheMax=200
注意：
- 设置值低于
127会被 JVM 自动修正为127 - 该参数只影响
Integer.valueOf(int)和所有自动装箱（如Integer a = 180;），对new Integer(180)完全无效 - 类加载时就初始化缓存数组，所以参数必须在应用启动前传入，运行时修改无效
扩大缓存范围的实际影响和风险
看似能“解决”部分 == 比较为 false 的困惑，但真实项目中几乎不值得这么做。
原因很实在：
- 缓存扩大后，
Integer.valueOf(180) == Integer.valueOf(180)可能为true，但Integer.valueOf(180) == new Integer(180)仍为false，语义混乱没根除 - 不同环境（测试/生产）、不同 JDK 版本、不同 JVM 参数配置下，缓存行为不一致，导致
==结果不可预测 - 哪怕设成
500，只要有人写Integer a = 1000;，陷阱照旧出现——你永远没法靠扩大缓存“堵住所有漏”
真正稳定的写法始终是：比较值就用 .equals()，混用基本类型就依赖自动拆箱，别把 == 当数值比较用。
