Weird Java question: Why does 128 == 128 return False, but 127 == 127 returns True?

This is the topic we are going to discuss today because I think it is very interesting.

If you run the following code:

 Class A
 {
 public   static void main(String[] args)
 {
 Integer a = 128, b = 128;
        System. out .println(a == b);
 Integer c = 127, d = 127;
        System. out .println(c == d);
 }
 }

You will get the following result:

 false  
 true  

We know that if two references point to the same object, then == is true; conversely, if the two references do not point to the same object, then == is not true, even if the contents of the two references are the same. Therefore, the result will be false.

This is where it gets really interesting. If you look inside the Integer.java class, you’ll find an inner private class called IntegerCache.java that provides a cache for all integer objects between -128 and 127.

This thing provides an internal cache for small integers, and when declared like this:

 Integer c = 127

This is what it looks like inside:

 Integer var3 = Integer .valueOf(127);

In fact, after I decompile the A.class file, the code is as follows:

If we look at the valueOf() class function, we can see:

 public   static   Integer valueOf( int i) {
        if (i >= IntegerCache.low && i <= IntegerCache.high)
 return IntegerCache.cache[i + (-IntegerCache.low)];
 return new Integer (i);
 }

If the value is between -128 and 127, it returns an instance of that cache.

therefore...

 Integer c = 127, d = 127;

Both refer to the same object.

That's why the following code evaluates to true:

 System.out.println (c == d) ;

Now you might ask, why would there be a cache for all integers between -128 and 127?

This is because the frequency of use of small integers in this range is much greater than that of other integers in daily life, and the fact that the same underlying object is used multiple times can be effectively optimized for memory through this setting. You can use this feature arbitrarily using the reflection API.

Run the following code and you will see the magic.

 public   static void main(String[] args) throws NoSuchFieldException, IllegalAccessException { 
 
      Class cache = Integer .class.getDeclaredClasses()[0];
      Field myCache = cache.getDeclaredField( "cache" );
      myCache.setAccessible( true ); 
 
 Integer [] newCache = ( Integer []) myCache.get(cache);
      newCache[132] = newCache[133]; 
 
 int a = 2;
 int b = a + a;
      System. out .printf( "%d + %d = %d" , a, a, b); //
 }

The print result is:

 2 + 2 = 5

Let's look at the disassembled code again:

Is this the same problem as above?

But why is the result 2 + 2 = 5?

Let's continue to look at the Integer source code to gain a deeper understanding of the Integer cache mechanism. Here is a screenshot:

According to the source code, we can find that the method of modifying the upper limit of the Integer cache has some minor flaws. Let's take a look at what the API suggests to us:

 the size   of the cache may be controlled by the {@code -XX:AutoBoxCacheMax=< size >} option .

It turns out that we only need to set -XX:AutoBoxCacheMax=133 at runtime.