Reputation: 6154
My question is about java interning and constant pools.
Java maintains a a constants pool for java.lang.String
, to use JVM memory cleverly, and to do so java.lang.String is made immutable. So why doesn't java maintain constant pools of other immutable types, such as Long, Integer, Char, Short ? Wouldn't that save memory too ?
I am aware of the fact that Integers are pooled for value range [-127, 127], though I do not understand the reason for choosing this range.
Here's a test code I wrote to test pooling of other immutable data types.
public class PoolTest {
public static void main(String... args) {
// Pooling of Integer [-127, 127]
Integer x = 127, y = 127;
System.out.println("Integer:" + (x == y)); // prints true
x = 129;
y = 129;
System.out.println("Integer:" + (x == y)); // prints false
// Apparent pooling of short [-127, 127]
Short i = 127, j = 127;
System.out.println("Short: " + (i == j)); // prints true
i = 128;
j = 128;
System.out.println("Short: " + (i == j)); // prints false
// No pooling of long values
Long k = 10L, l = 10L;
System.out.println("Long: " + (i == j)); // prints false
k = 128L;
l = 128L;
System.out.println("Long: " + (i == j)); // prints false
}
}
Upvotes: 18
Views: 6772
Reputation: 390
Well, because String objects are immutable, it's safe for multiple references to "share" the same String object.
public class ImmutableStrings
{
public static void main(String[] args)
{
String one = "str1";
String two = "str1";
System.out.println(one.equals(two));
System.out.println(one == two);
}
}
// Output
true
true
In such a case, there is really no need to make two instances of an identical String object. If a String object could be changed, as a StringBuffer can be changed, we would be forced to create two separate objects. But, as we know that String objects cannot change, we can safely share a String object among the two String references, one and two. This is done through the String literal pool.
You can go through this link to know in details.
Upvotes: 0
Reputation: 77177
The purpose of a constant pool is to reduce the memory overhead required by keeping multiple copies of constants. In the case of String
s, the JVM is inherently required to keep some object around for each individually distinguishable constant, and the Java spec basically says that the JVM should deduplicate String
objects when class loading. The ability to manually place String
s in the pool via intern
is inexpensive and allows programmers to identify particular values (such as properties) that are going to be around for the life of the program and tell the JVM to put them out of the way of normal garbage collection.
Pooling numeric constants, on the other hand, doesn't make a lot of sense, for a few reasons:
String
carries around a char[]
, an int
for its length, and another for its hashCode
. For a number, by contrast, a maximum of eight immediate bytes is required.Byte
, Short
, and Integer
objects from -128 to 127 (0 to 127 for Character
) are precached for performance reasons, not to save memory. This range was presumably chosen because this is the ranged of a signed byte, and it will cover a large number of common uses, while it would be impractical to try to precache a very large number of values.As a note, keep in mind that the rules about interning were made long before the introduction of autoboxing and generic types in Java 5, which significantly expanded how much the wrapper classes were casually used. This increase in use led Sun to add those common values to a constant pool.
Upvotes: 10