triggered by automatic packing and unpacking I look at the integer source code

Background and issues

See the following code when you look at the material that someone has collated:

 Packagecom.sitech.test;/*** Automatic packing and unpacking jdk1.6 *@authorLIAOWP **/ Public classTestinteger { Public Static voidMain (string[] args) {Integer i1= I2 = i3 = 999, I4 = 999; System.out.println (I1= = I2);//trueSystem.out.println (i3 = = I4);//false    }}

If you have not read the source of the students must feel the answer is either 2 true or 2 false. I just saw this piece of code also feel is 2 true, feel myself 100% OK, but really run after only found dumbfounded, a true a false, this is a bug bar. In fact, LZ has seen a part of the integer source code, but now think it seems not serious, embarrassing. So by this issue triggered the LZ to seriously look at an integer source (I want to seriously, haha).

Let's go back to the question above, first solve the problem in the blowing NB. We can see that the above code 4 variables are integer references, so the output = = Operation compares not an integer value but an integer reference . What is the nature of boxing? When we assign an int value to an integer object, we call the static method of the integer class valueof, and we look at the valueof method to see why there is such a result.

    /*** Returns an {@codeInteger} instance representing the specified * {@codeint} value. If a new {@codeInteger} instance is isn't * required, this method should generally being used in preference to * the constructor {@link#Integer (int)}, as this method was likely * to yield significantly better space and time performance by * Cach     ing frequently requested values.  * This method would always have the cache values in the range-128 to 127, * inclusive, and may caches other values outside     of this range. *     * @paramI an {@codeint} value. * @returnAn {@codeInteger} instance representing {@codei}. *@since1.5*/     Public StaticInteger ValueOf (inti) {//is a static method Integercache is an internal classassertIntegercache.high >= 127;//Assertion Reference http://lavasoft.blog.51cto.com/62575/43735/if(I >= integercache.low && i <=Integercache.high)//If I is greater than for integercache.low () and I is less than or equal to Integercache.highreturnIntegercache.cache[i + (-Integercache.low)];/ /Take it directly from the cachereturn Newinteger (i);//Create a new integer object}

From the above code we can see that the integer maintains a cache system, if it is in the scope of the cache directly out of the good, if not the need to create a new integer object. But what the cache range is, we're going to go inside and look at:

    /*** Cache to support the object identity semantics of autoboxing for values between * -128 and 127 (inclusive)     As required by JLS.  * * The cache is initialized on first usage.     The size of the cache * May is controlled by the-xx:autoboxcachemax=<size> option. * During VM initialization, Java.lang.Integer.IntegerCache.high property * is set and saved in the private system     Properties in the * Sun.misc.VM class. */    Private Static classIntegercache {//static class OhStatic Final intLow =-128;//Minimum value is -128Static Final inthigh;//HighestStatic FinalInteger cache[];//Cache Array These three are final, non-modifiableStatic{//Static code block static code block is performed before the retrofit method//High value is configured by property            intH = 127;//The default String integercachehighpropvalue=//defines a stringSun.misc.VM.getSavedProperty ("Java.lang.Integer.IntegerCache.high");//Gets the set valueif(Integercachehighpropvalue! =NULL) {//If the set value is setinti =parseint (Integercachehighpropvalue);//convert string to int i= Math.max (i, 127);//Get the bigger one for I and 127, which is actually not small with the default//Maximum array size is Integer.max_valueh = math.min (i, Integer.max_value-(-Low )); /If you take the small one, you cannot exceed the maximum value of the integer +low} High=h;//Maximum value is 127 cache=Newinteger[(high-low) + 1];//Creating a cache array sizeintj =low;//Minimum Value for(intk = 0; K < Cache.length; k++) Cache[k]=NewInteger (j + +);//Cache initialization}PrivateIntegercache () {}//private construct}

Problem Solving

The cache for integer

After reading, I believe basic know why the first piece of code will be like this, I now do a small summary, theinteger inside an internal class Integercache, is used to do cache optimization performance. The default cache is 128 to 127 in the middle of the number, which is said to make it more frequent. In fact, many of the classes in Java have such optimizations. If the cache is directly between 128-127, the new integer is not. so that explains the problem.

would also like to analyze the whole class once, after looking at other people's analysis of the findings of their own analysis has little effect, if you want to look at the complete analysis of the integer class, LZ recommended http://www.cnblogs.com/vinozly/p/5173477.html

triggered by automatic packing and unpacking I look at the integer source code