被 Java 的 Integer 缓存坑过吗？127 和 128 的区别太坑了

本文聚焦 Java 中 Integer 缓存机制引发的问题，尤其是 127 和 128 在比较时出现的差异。先介绍 Integer 缓存的基本概念与作用，接着深入分析 127 和 128 比较结果不同的原因，包括自动装箱、缓存范围等。还探讨了该问题在实际开发中的影响，如程序逻辑错误等，并给出避免踩坑的方法，最后总结相关要点，帮助开发者深入理解并规避此类问题。​

一、Integer 缓存机制的基本认知​

在 Java 编程中，Integer 是我们经常使用的包装类之一。它与基本数据类型 int 有所不同，Integer 是对象类型，而 int 是 primitive 类型。在 Java 的设计中，为了提高性能和节省内存，引入了 Integer 缓存机制。​

Integer 缓存，简单来说就是 Java 虚拟机在启动时，会预先创建一定范围的 Integer 对象并存储在缓存中。当我们需要使用处于这个范围内的 Integer 对象时，虚拟机就会直接从缓存中获取，而不是重新创建新的对象。这样做的好处是减少了对象的创建和销毁，从而提升了程序的运行效率，同时也节省了内存资源。​

那么，这个缓存的范围是多少呢？默认情况下，Integer 缓存的范围是 - 128 到 127。这是 Java 语言规范中明确规定的，目的是覆盖日常开发中最常用的整数范围。当然，这个范围在一定条件下是可以通过 JVM 参数进行调整的，但在大多数情况下，我们接触到的都是默认范围。​

二、127 和 128 比较结果不同的原因​

（一）自动装箱的影响​

在 Java 中，存在自动装箱和自动拆箱的机制。自动装箱就是将基本数据类型自动转换为对应的包装类对象，比如将 int 转换为 Integer；自动拆箱则是将包装类对象自动转换为基本数据类型。​

当我们定义类似Integer a = 127;这样的语句时，实际上发生了自动装箱操作。此时，Java 虚拟机会检查缓存中是否存在值为 127 的 Integer 对象，如果存在，就直接将该对象的引用赋给变量 a；如果不存在，才会创建一个新的 Integer 对象。​

对于Integer b = 127;，同样会进行自动装箱。由于 127 在缓存范围内，所以变量 b 引用的也是缓存中同一个 Integer 对象。因此，当我们使用a == b进行比较时，比较的是两个变量引用的是否是同一个对象，结果自然为 true。​

而对于Integer c = 128;和Integer d = 128;，情况就有所不同了。因为 128 超出了默认的 Integer 缓存范围（-128 到 127），所以在进行自动装箱时，Java 虚拟机会为 128 创建两个新的 Integer 对象，分别赋给变量 c 和 d。此时，c == d比较的是两个不同对象的引用，结果就为 false。​

（二）“==” 与 equals () 的区别​

在比较 Integer 对象时，我们还需要注意 “==” 和 equals () 方法的区别。“==” 对于对象类型来说，比较的是对象的引用地址，只有当两个变量引用的是同一个对象时，结果才为 true；而 equals () 方法在 Integer 类中被重写了，它比较的是两个 Integer 对象的实际数值是否相等。​

所以，当我们比较Integer a = 127;和Integer b = 127;时，使用a == b为 true，使用a.equals(b)也为 true。而比较Integer c = 128;和Integer d = 128;时，c == d为 false，但c.equals(d)为 true，因为它们的数值都是 128。​

很多开发者在编程时，容易混淆 “==” 和 equals () 的用法，尤其是在处理包装类对象时，这就可能因为 Integer 缓存机制而导致错误的比较结果。​

三、Integer 缓存机制在实际开发中的影响​

（一）程序逻辑错误​

在实际开发中，如果不了解 Integer 缓存机制，很容易因为 127 和 128 的比较问题导致程序逻辑错误。比如在一些判断条件中，使用 “==” 来比较两个 Integer 对象是否相等，当数值在 127 及以下时，可能会得到正确的结果，但当数值超过 127 时，就会出现错误，从而影响程序的正常运行。​

例如，在一个用户积分系统中，当判断用户积分是否达到某个阈值（如 128）时，如果使用了Integer类型的变量进行 “==” 比较，就可能出现判断失误，导致符合条件的用户没有得到相应的奖励，或者不符合条件的用户得到了奖励，这无疑会影响系统的准确性和可靠性。​

（二）代码调试困难​

当程序因为 Integer 缓存机制出现问题时，调试起来可能会比较困难。因为这种问题具有一定的隐蔽性，在数值较小时程序运行正常，当数值超过 127 时才会出现错误，开发者可能需要花费大量的时间去排查问题所在，尤其是在大型项目中，排查的难度会更大。​

四、避免被 Integer 缓存坑到的方法​

（一）明确使用基本数据类型​

在编程过程中，如果我们不需要使用包装类的特殊功能，仅仅是进行数值的存储和比较，那么尽量使用基本数据类型 int，而不是 Integer。因为基本数据类型在比较时使用 “==”，比较的是实际数值，不会受到缓存机制的影响，能够避免很多潜在的问题。​

（二）正确使用 equals () 方法​

当必须使用 Integer 包装类时，在进行比较操作时，要使用 equals () 方法，而不是 “==”。这样可以确保比较的是两个对象的实际数值，无论数值是否在缓存范围内，都能得到正确的结果。​

不过，在使用 equals () 方法时，需要注意避免出现空指针异常。如果有一个 Integer 对象可能为 null，那么在调用 equals () 方法时，最好将非空的对象放在前面，比如127.equals(a)，而不是a.equals(127)，当 a 为 null 时，后者会抛出空指针异常。​

（三）手动装箱时指定使用缓存​

虽然自动装箱在缓存范围内会使用缓存对象，但在某些情况下，我们可能需要手动创建 Integer 对象并确保使用缓存。不过，Java 中并没有直接提供这样的方法，但我们可以通过Integer.valueOf()方法来实现。​

Integer.valueOf()方法的内部实现会检查数值是否在缓存范围内，如果在，就返回缓存中的对象；如果不在，就创建新的对象。因此，使用Integer a = Integer.valueOf(127);和Integer b = Integer.valueOf(127);时，a == b为 true；而使用Integer c = Integer.valueOf(128);和Integer d = Integer.valueOf(128);时，c == d为 false，这和自动装箱的结果是一致的。但明确使用valueOf()方法可以让代码的意图更清晰，提醒开发者注意缓存机制的存在。​

（四）了解 JVM 参数调整缓存范围​

虽然在大多数情况下，我们不需要调整 Integer 缓存的默认范围，但了解可以通过 JVM 参数-XX:AutoBoxCacheMax=<size>来调整缓存的上限还是有必要的。比如，将缓存上限调整为 255，那么数值在 - 128 到 255 之间的 Integer 对象在自动装箱或使用valueOf()方法时都会使用缓存。​

不过，需要注意的是，调整缓存范围可能会增加内存的占用，因为需要缓存更多的 Integer 对象。所以，在调整时需要权衡性能和内存的关系，根据实际需求做出合理的设置。​

五、总结归纳​

Java 中的 Integer 缓存机制是为了提高性能和节省内存而设计的，默认缓存范围是 - 128 到 127。这就导致了 127 和 128 在作为 Integer 对象比较时出现不同的结果：127 因为在缓存范围内，通过 “==” 比较时结果为 true；128 因为超出缓存范围，通过 “==” 比较时结果为 false。​

在实际开发中，这种差异可能会导致程序逻辑错误，且调试困难。为了避免踩坑，我们可以尽量使用基本数据类型 int，在必须使用 Integer 时，正确使用 equals () 方法进行比较，明确使用Integer.valueOf()方法以清晰表达意图，必要时了解并合理调整 JVM 参数来改变缓存范围。​

深入理解 Integer 缓存机制及其带来的影响，掌握正确的使用方法，能够帮助我们写出更健壮、更可靠的 Java 代码，避免因这个 “坑” 而导致的不必要的问题。​