Garbage collection behavior for String.intern ()

Question

If I use String.intern () to improve performance, since I can use "==" to compare interned string, will I encounter garbage collection problems? How is intern string string garbage collection different from regular string?

Answer 1

In fact, this is not garbage collection optimization, but rather row pool optimization. When you call String.intern() , you replace the link to your starting line with the link to the base link (the link the first time this line was encountered, or this link if it is not already known).

However, it will become a garbage collector problem if your string is no longer used in the application, since the interned string pool is a static member of the String class and will never be garbage collected.

As a rule, I find it preferable to never use this intern method and let the compiler use it only for constants. Strings declared as follows:

 String myString = "a constant that will be interned"; 

This is better since it will not allow you to make a false assumption == may work when it is not.

In addition, the fact of String.equals underlies == as optimization, which makes it possible to optimize interned strings under the hood. This is another proof == if ever used for strings.

Answer 2

String.intern() manages the internal pool, implemented on the basis of its own implementation, which has some special functions related to the GC. This is old code, but if it was reimplemented, it would use java.util.WeakHashMap . Weak links are a way to keep a pointer to an object without interfering with its collection. The right thing for a pool together, such as interned strings.

These interned strings collect garbage that can be demonstrated with the following Java code:

 public class InternedStringsAreCollected { public static void main(String[] args) { for (int i = 0; i < 30; i ++) { foo(); System.gc(); } } private static void foo() { char[] tc = new char[10]; for (int i = 0; i < tc.length; i ++) tc[i] = (char)(i * 136757); String s = new String(tc).intern(); System.out.println(System.identityHashCode(s)); } } 

This code creates the same string 30 times, interning it each time. Additionally, it uses System.identityHashCode() to show which hash code of Object.hashCode() would be returned to this interned string. When run, this code prints clear integer values, which means that you are not getting the same instance every time.

In any case, the use of String.intern() somewhat discouraged. This is a common static pool, which means that it easily turns into a bottleneck in multi-core systems. Use String.equals() to compare strings, and you will live longer and happier.

Answer 3

This article provides the complete answer.

In java 6, the row pool is in PermGen since java 7 row pool is in the heap memory.

Manual internment strings will be garbage collected.
String literals will only collect garbage if the class that defines them is unloaded.

The row pool is a fixed-size HashMap that was small in java 6 and earlier versions of java 7, but increased to 60013 with java 7u40.
It can be changed using -XX: StringTableSize = <new size> and viewed with the -XX: + PrintFlagsFinal java options.

Answer 4

Please read: http://satukubik.com/2009/01/06/java-tips-memory-optimization-for-string/

The conclusion I can get from your information: You have interned too many lines . If you really need to put so many String to optimize performance, increase the memory of permenting , but if I were you , I will first check if I really need a lot of interned String.