Wednesday, September 9, 2009

StringPool and GarbageCollection

It is interesting and important to understand how strings are handled in Java. The way Java handles or manages strings is little different from other objects.

Case1:

String a = "java";
String b= "java";

Does these two strings represent the same object reference ?. The answer is yes they do.

Case 2:
String c=new String("java");
String d =new String("java");
Does c and d point to the same object reference. The answer is NO . They don't.

Now let us see how all these work out.

First thing: Java maintains a pool of string constants called literal pool. Infact this pool contains references to string instances in heap. Since Strings are also objects they are also created in the heap.

Whenever you put a literal ( example to this is what the variable a represents) in the code, this gets special treatment. When the JVM loads your class where there is a string literal, the VM checks whether there is an existing entry in the string pool for this string value. If yes , the symbolic link is replaced with the actual reference to that string object.
If there is no such string in the pool a entry will be created in the pool and a string instance will be created in the heap. The entry in the pool points to reference of this string object. Again the symbolic link in your class is replaced with the actual reference to the string object in heap.

Again refer to the Case 2 at the top. Here a new string is created using new operator. When we do this , we are telling VM to create a new instance of string in heap. VM won't mind whether the string pool has an entry for this string value. With new always a new instance is created.

These string objects created using new operator are eligible for Garbage collection when there are no reference to them for other parts of the code.

But what about the string objects in heap that are created by VM as a response to a string literal creation like Stirng a ="java". These objects are never garbage collected as they have a reference to them from the string pool constant table.

This string pool constant table is part of the class data of string class and since string class would be never offloaded by the classloader, these referenceexists in the method area and GC can never collect them.





No comments: