Is the Java Integer cache a realization of the object pool pattern?

Question

One of the best-known examples of a full-fledged object pool is the JDBC connection pool. Main reasons:

• objects in the pool are expensive to create and relate with external resources
• each object in the pool is served to at most one client a time
• objects in the pool need to be brought back to a clean state before being served again to a new client

With the above in mind, can the Java Integer cache be regarded as a object pool realization? Here is why I doubt it:

• objects in the pool can be used by more than one client a time due to their immutability
• immutability also prevents pool objects from reaching a stale state
• there's no notion of a "free" object, ready to be allocated to a client

Answer 1

It is really the flyweight pattern which is a specialized sort of object pool, where objects get shared to save memory.

Answer 2

The problem with a Java Integer cache is that the VM is optimized for boxing/unboxing. The lookup mechanism for a "cached" Java Integer is going to be more expensive than just creating the object.

building cache
test length 500,000,000
cached duration: 12001.345937
boxed duration: 12108.983383

In many scenarios the lookup using many threads is going to cause lots of cache misses across different cores and have more of a performance hit.

System.out.println("building cache");

Integer[] cache = new Integer[50000];

for( int i = 0; i < cache.length; i ++)
{
    cache[i] = new Integer(i);
}

int c = 500 * 1000000;
int t = 0;

System.out.println("test length " + c );

NanoStopWatch watch = new NanoStopWatch();

watch.start();

while( t < c)
{
    Integer p = cache[ (int)  (Math.random() * 5000) ];

    t++;
}

watch.stop();

System.out.println("cached duration: " + watch.duration() );

t = 0;

watch.start();

while( t < c)
{
    Integer p =  (Integer) (int) (Math.random() * 5000);

    t++;
}

watch.stop();

System.out.println("boxed duration: " + watch.duration() );