0

Possible Duplicate:
Integer wrapper objects share the same instances only within the value 127?

I have a question about the memory management in Java.

When I try the following code:

Integer a = 1;
Integer b = 1;
System.out.println(a==b); // this gives "true"

However, 

Integer a = 256;
Integer b = 256;
System.out.println(a==b); //this gives "false"

Why?

Thanks very much.

Community
  • 1
  • 1
penpen926
  • 115
  • 1
  • 6

3 Answers3

6

That is because "autoboxing" uses Integer.valueOf, and Integer.valueOf keeps a cache of Integer objects for small integer values. Here's what the JLS says:

"If the value p being boxed is true, false, a byte, or a char in the range \u0000 to \u007f, or an int or short number between -128 and 127 (inclusive), then let r1 and r2 be the results of any two boxing conversions of p. It is always the case that r1 == r2." JLS 5.1.7.

When you use the == operator to compare a pair of Integer objects, it is actually comparing the object references. So your get true if boxing gave you the same cached Integer object, and false if it didn't. Note that the JLS guarantees this behaviour for the ranges stated, but it also permits an implementation of the valueOf method to cache a wider range of values.

The bottom line is that you should use equals(Object) to compare Integer objects ... unless you are really trying to test if they are the same object.

According to what I read, "Integer" should create an "object" in the heap, thus the two objects should be the same.

If your code explicitly does a new Integer(...), it is guaranteed to create a new Integer object. However, autoboxing uses Integer.valueOf(...), and that is where the caching behaviour is implemented.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • 1
    +1 BTW Long between -128 and 127 (with autoboxing), BigInteger between -16 and 16 and BigDecimal from 0 to 10 (with valueOf()) are also cached. – Peter Lawrey Aug 12 '12 at 09:47
  • Thank very much, this answer is just what I want. Yes, I tried to test if they refer to the same object, that's why I got confused. According to what I read, "Integer" should create an "object" in the heap, thus the two objects should be the same. But I don't know when the values are small, they are actually related to "autoboxing".. Thanks a lot – penpen926 Aug 12 '12 at 09:54
  • Could you highlight were it mentions `long` for me? – Peter Lawrey Aug 13 '12 at 07:26
  • 1
    @PeterLawrey - it should be noted that those are all implementation specific. Not even the javadoc for the relevant methods specifies that there will be any caching ... or for what values it is done. – Stephen C Aug 13 '12 at 09:30
  • The Javadoc should at least indicate that caching can occur. It appears to be a common source of confusion, though I suspect many people using auto-boxing won't read the Javadoc for `valueOf`. ;) – Peter Lawrey Aug 13 '12 at 09:33
2

You shouldn't use reference equality (==) for objects. It's printing true in your first example because the first 128 Integer objects are cached by the Integer class. Use .equals()

Amir Afghani
  • 37,814
  • 16
  • 84
  • 124
0

When the values greater than range of data representation, they are different object because they are wrapped. You are now coparing like object ids.

You are comparing objects' addresses
huseyin tugrul buyukisik
  • 11,469
  • 4
  • 45
  • 97