设置java_cache大小,为什么JVM允许设置“高”？ IntegerCache的值，但不是“低”？...

We all know that Java has a cache for Integer (and some other types) for number in the range [-128, 127] which are considered to be "commonly used".

The cache is designed as follow :

private static class IntegerCache {

static final int low = -128;

static final int high;

static final Integer cache[];

static {

// high value may be configured by property

int h = 127;

String integerCacheHighPropValue =

sun.misc.VM.getSavedProperty("java.lang.Integer.IntegerCache.high");

if (integerCacheHighPropValue != null) {

try {

int i = parseInt(integerCacheHighPropValue);

i = Math.max(i, 127);

// Maximum array size is Integer.MAX_VALUE

h = Math.min(i, Integer.MAX_VALUE - (-low) -1);

} catch( NumberFormatException nfe) {

// If the property cannot be parsed into an int, ignore it.

}

}

high = h;

cache = new Integer[(high - low) + 1];

int j = low;

for(int k = 0; k < cache.length; k++)

cache[k] = new Integer(j++);

// range [-128, 127] must be interned (JLS7 5.1.7)

assert IntegerCache.high >= 127;

}

private IntegerCache() {}

}

I know that I can extend the high value by giving a parameter to the JVM :

java -Djava.lang.Integer.IntegerCache.high=xxxx Aclass.class

What I don't understand is why aren't we allowed to override the low value ?

Note that I was not trying to find a workaround, but instead understand why it is not allowed for some obscure reasons.

解决方案

Found out that there is already an unresolved RFP on this.

Joe Darcy commented on the issue :

It is conceivable that it would be helpful to cache a greater range of

negative number as well, but as of yet there has been no pressing need

to do so.

Note that the RFP offer a poor workaround if ever someone was interested in using this before it is handled :

No workaround possible for increasing

the size of the cache apart from Implementing your own cache and

reffering to this first before going to the java.lang.Integer class.

This is obviously not good as it requires calls to other classes

rather than just the default use of the Integer.valueOf(int i) call.