IntegerCache在Integer类首次主动使用（如valueOf或自动装箱）时，由JVM在线程安全的静态初始化阶段执行其静态代码块完成初始化，此时按配置确定high值（默认127）、固定low为-128，创建并填充256个缓存对象。
IntegerCache 的初始化发生在 Integer 类首次被主动使用时，也就是类加载过程中的“初始化”阶段（Initialization），而非加载（Loading）或链接（Linking）阶段。它由 JVM 保证线程安全、仅执行一次，并依赖静态代码块完成预热。
IntegerCache 是如何被触发初始化的
IntegerCache 是 Integer 类的私有静态内部类，本身不独立加载。它的初始化绑定在 Integer 类的静态初始化流程中：
- 当代码第一次访问 Integer 的静态成员（如调用
Integer.valueOf(10)、读取Integer.MIN_VALUE，或执行Integer i = 10;自动装箱）时，JVM 判定 Integer 类尚未初始化，随即进入初始化阶段； - 此时会按源码顺序执行 Integer 类顶层的静态变量赋值和静态代码块 —— 而
IntegerCache的静态代码块正是在此过程中被执行； - 该过程由 JVM 通过“类初始化锁”保障，即使多线程并发触发，也只会有一组线程真正执行初始化，其余阻塞等待，确保缓存数组只构建一次。
静态代码块里实际做了什么
精简后的逻辑如下（对应 JDK 8+ 源码）：
- 确定缓存上界
high：默认为 127；若系统属性java.lang.Integer.IntegerCache.high被设置（例如启动参数-Djava.lang.Integer.IntegerCache.high=200），则取其值，且不低于 127； - 计算数组长度：
(high - low) + 1，其中low固定为 -128； - 创建
Integer[] cache数组，并用new Integer(i)循环填充所有整数对象（从 -128 开始递增）； - 所有缓存对象在初始化时即完成构造并强引用驻留堆中，不会被 GC 回收。
为什么不是类加载时就初始化
Java 规范要求“被动引用”不触发初始化，比如单纯声明 Integer i; 或访问其运行时常量池中的字面量（如 final static int X = 100;）不会导致类初始化。只有“主动使用”才会启动该流程。这种延迟策略避免了无谓的内存分配和对象创建，尤其在应用未用到 Integer 缓存时可节省资源。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
验证方式：可观察类初始化时机
可通过添加 JVM 参数 -XX:+TraceClassInitialization 运行程序，输出类似：
[Initializing java.lang.Integer]
紧接着就会看到 IntegerCache 静态块执行日志。也可在 IntegerCache 的静态块中插入 System.out.println("Cache initialized") 辅助验证 —— 它只打印一次，且总在第一个 valueOf() 或自动装箱前完成。
