Number类体系：包装类缓存机制（IntegerCache）全解

说起Ja va包装类的缓存机制，这其实是JVM在背后做的一个“小动作”——它把那些常用的小数值对象提前创建好、存起来，等需要的时候直接拿出来复用。这么做的目的很明确：减少频繁创建对象带来的堆内存分配压力，提升运行效率，顺便也减轻了垃圾回收（GC）的负担。不过，这个机制并非对所有包装类一视同仁，也不是在任何创建方式下都生效。真正理解它，得抓住三个关键点：缓存的范围、对象的创建方式，以及由此引发的比较习惯问题。

Integer 缓存：-128 到 127 是默认安全区

Integer的缓存，是由一个叫IntegerCache的内部静态类实现的。它强制缓存了从-128到127（包含两端）这个区间内的所有整数。这个范围可不是随便定的，它是Ja va语言规范（JLS）白纸黑字要求的标准，所有合规的JVM实现都必须遵守。

为什么是这个范围？因为它覆盖了日常开发中的绝大多数高频场景：数组索引、循环变量、简单的状态码、ASCII字符值等等，基本都落在这个区间内。一旦数值超出了这个“安全区”，比如128或者-129，那么每次通过Integer.valueOf()或者自动装箱，JVM都会老老实实地在堆上创建一个全新的Integer对象。

这里有个小技巧：你可以通过JVM参数-XX:AutoBoxCacheMax=200来扩大缓存的上限（比如扩大到200）。但需要注意的是，这个参数只影响上限，缓存的下限-128是固定不可调的。

哪些操作能命中缓存？哪些绕过？

缓存机制并非对所有创建Integer对象的方式都有效。它只在以下两种路径下被触发：

• 自动装箱：当你写下Integer a = 100;这样的代码时，编译器在背后悄悄把它转换成了Integer.valueOf(100)，从而有机会命中缓存。
• 显式调用valueOf()：直接调用Integer.valueOf(100)，这是利用缓存的规范方式。

而有一种方式会完全绕过缓存，那就是使用new关键字构造器。例如new Integer(100)，无论这个100是否在缓存范围内，JVM都会在堆上分配一个全新的对象。这就导致了一个经典陷阱：Integer x = 100; Integer y = new Integer(100); 此时，x == y比较的结果一定是false，因为它们根本就不是同一个对象。

其他包装类的缓存策略差异

别以为所有包装类都跟Integer一个样，它们的缓存策略各有各的“脾气”：

• Byte：最“大方”，缓存了其所有可能的值（-128 ~ 127），没有例外。
• Short 和 Long：默认行为与Integer类似，也缓存-128 ~ 127这个范围。但需要特别注意的是，Long的缓存行为在部分JDK版本中可能不被保证，它依赖于具体的JVM实现。
• Character：缓存范围是Unicode值0 ~ 127，这基本上就是ASCII字符集（包括可见字符和控制字符）。
• Boolean：最简单，只缓存了true和false这两个实例，任何布尔值的装箱操作都是直接复用它们。

== 和 equals() 的坑，必须警惕

缓存机制最让人头疼的地方，就是它会让==操作符在某些情况下“意外地”返回true。但这只是引用相等性的一个副产品，绝非设计本意，依赖它进行逻辑判断非常危险。

• Integer a = 127; Integer b = 127; a == b → true （因为指向了缓存里的同一个对象）
• Integer c = 128; Integer d = 128; c == d → false （超出缓存范围，是两个不同的对象）
• Integer e = 127; Integer f = new Integer(127); e == f → false （一个来自缓存，一个是全新堆对象）

所以，这里有一条铁律：只要是比较包装类对象的值，一律使用.equals()方法。尤其是在使用集合（比如Map）进行值判断时，绝对要避免使用==，否则很可能掉进难以察觉的bug里。