1

I know that Integers act like interns for the values less than 128 (default) and not for the values more than that. I know that this has been given as an answer many times but I couldn't noticed a place that the reason is asked.

So what I want to know is Why Integers act as interns only for the values less than 128 (default) and not for the values more than that? How does it improve the less memory usage / high performance?

ironwood
  • 8,936
  • 15
  • 65
  • 114
  • Refer to [Java Integer: Constant Pool](http://stackoverflow.com/q/13098143/1065197) – Luiggi Mendoza Jul 17 '13 at 08:34
  • 2
    The intern range is -128 to 127 (same as `byte`). It's a design decision. The reasoning probably that you only need a byte to store it, and *most* integer constants are small numbers in this range. – Bohemian Jul 17 '13 at 08:35

2 Answers2

5

Technically the values are pre-cached when the class is loaded. It is not like String.intern() where a value you created can be returned.

Also the maximum might not be 127, it can be higher if you set it so or use options like -XX:+AggressiveOpts

The default range is likely to be chosen just to be consistent with Byte. Note: the cached values are

Boolean: both values
Byte: all
Character: 0 to 127
Short: -128 to 127
Integer: -128 to 127
Long: -128 to 127
Float and Double: none
BigInteger: -16 to 16 (in HotSpot Java 7)
BigDecimal: 0 to 10 (if you use valueOf(long)) and 
            0 to 0.000000000000000 (if you use valueOf(long, int)) (in HotSpot Java 7)

The reason it is done is to improve performance and reduce GC pressure.

Creating garbage can fill your cache with garbage, slowing down all your code, it also takes work to create objects and to clean them up. The less work you do the faster and more consistent your program will be.

Here is a good article of the difference it makes http://www.javaspecialists.eu/archive/Issue191.html

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
1

Look at it like this:

It is certainly not desirable to cache all Integer values. For, this would mean that when a JVM starts up, it'd have to make more than 4 billion Integer objects which would most likely not fit in the memories of contemporary computers.

Hence, one must decide to cache some smaller number of Integers (if at all). This number should be small enough so that no memory usage or slower startup is noticeable. OTOH, it should cover as most cases as possible. Not having read any study concerning this, but from experience we can say with confidence that very small integers are most often used.

Thus, the decision to cache 128 numbers is completly arbitrary, yet it still makes sense. It could as well be 30 or 300. But certainly not a million.

How does this help performance? Well, it sppeds up autoboxing for small numbers, because one does not have to construct an Integer, but rather pick one from the cache (which is most likely an Integer[128] array) with a single memroy access. At the same time, it is well known that many Integers are short-lived. Use of pre-allocated objects that need not be garbage collected takes away stress from the GC.

Ingo
  • 36,037
  • 5
  • 53
  • 100