修改 IntegerCache 会引发连锁异常，因其破坏 JVM 对 -128~127 范围内 Integer 缓存的只读契约，导致 valueOf() 返回错误对象、== 比较失效、第三方库异常及多线程脏数据。
Java 中通过反射修改 IntegerCache 缓存数组确实会导致难以察觉的诡异行为，本质是破坏了 JVM 对 Integer 值缓存的契约——这个缓存本应只读、稳定、线程安全。一旦被篡改，所有依赖自动装箱（如 == 比较、Integer.valueOf() 返回值）的逻辑都可能出错，且问题往往延迟暴露、跨模块传染。
为什么修改 IntegerCache 会引发连锁异常
Integer.valueOf(int) 在 -128 到 127 范围内直接返回缓存数组中的固定对象引用，这是 JVM 规范要求的行为。该缓存由 IntegerCache.cache 静态字段持有，初始化后默认不可变。若用反射强行修改其内容（例如将 cache[129] 改为 new Integer(42)），后续所有对 valueOf(1)、valueOf(100) 等调用都可能返回错误对象——甚至出现 1 == 1 返回 false 这种反直觉结果。
- 缓存被污染后，
==和.equals()行为不一致：两个逻辑相等的Integer实例因指向不同对象而==失败 - 第三方库（如 Jackson、Hibernate）内部大量使用
valueOf()，可能触发 NPE 或类型校验失败 - 问题在多线程下更隐蔽：缓存数组被并发修改，导致部分线程看到脏数据，复现困难
如何快速定位是否是 IntegerCache 被篡改
当发现 Integer 对象在小范围值上 == 比较失效、或 valueOf(x) 返回非预期实例时，可立即检查缓存一致性：
- 写一段验证代码：循环打印
Integer.valueOf(i) == Integer.valueOf(i)在 -128~127 区间是否全为true；任意一个false即表明缓存已被破坏 - 用反射读取
IntegerCache.cache数组内容，检查索引 128（对应值 0）到 255（对应值 127）是否仍为各自对应数值的Integer实例（可用field.get(null)获取数组，再逐个intValue()校验） - 搜索项目中是否调用了类似
Field.setAccessible(true)+Field.set(null, ...)修改IntegerCache.cache的代码，尤其注意测试工具类、字节码增强插件或“优化”型 Utils
修复与规避的关键做法
根本原则是：绝不修改 IntegerCache。即使出于测试或调试目的，也应避免直接操作底层缓存。
立即学习“Java免费学习笔记（深入）”；
- 禁用反射修改：在代码审查中将
IntegerCache、LongCache等包装类缓存字段列为高危目标，CI 阶段可通过字节码扫描工具（如 ArchUnit）拦截非法反射访问 - 替代方案：需要“伪造”整数行为时，用自定义包装类或 Mockito 的
when().thenReturn()模拟valueOf()，而非动真实缓存 - JVM 层防护：启动参数添加
-XX:+UnlockDiagnosticVMOptions -XX:DisableExplicitGC无用，真正有效的是启用安全管理器（-Djava.security.manager）并限制reflect.ReflectPermission，但生产环境慎用
这类 Bug 的典型误判陷阱
开发者常把现象归因为“JVM bug”或“并发 bug”，而忽略人为反射干预：
- 看到
Integer a = 100; Integer b = 100; a == b有时为false，第一反应是“是不是 JIT 优化问题”，其实是某处已把cache[228]（即值 100 的位置）设为null或其他对象 - 单元测试偶尔失败，认为是随机并发问题，实则测试套件里某个
@BeforeClass方法偷偷重置了缓存数组 - 线上偶发
ClassCastException，堆栈指向Integer.intValue()，根源却是缓存里塞入了一个非Integer实例（如new Long(1)）
