When will a string be garbage collected in java

You are correct; strings in the intern pool will never be GC'd.

However, most strings on not interned.
String literals are interned, and strings passed to String.intern() are interned, but all other strings are not interned and can be GC'd normally.

Now in case of a string, this is not the case because string will go into the string pool and JVM will keep the object alive for reuse. So that means a string once created will 'never' be garbage collected?

First, it is only string literals (see notes) that get automatically interned / added to the string pool. String objects that are created by an application at runtime are not interned ... unless your application explicitly calls String.intern().

Second, in fact the rules for garbage collecting objects in the string pool are the same as for other String objects: indeed all objects. They will be garbage collected if the GC finds them to be unreachable.

In practice, the String objects that correspond to string literals typically do not become candidates for garbage collection. This is because there is an implicit reference to the String object in the code of every method that uses the literal. This means that the String is reachable for as long as the method could be executed.

However, this is not always the case. If a string literal was defined in a class that was dynamically loaded (e.g. using Class.forName(...)), then it is possible to arrange that the class is unloaded. If that happens, then the String object corresponding to the literal may then be unreachable, and may ultimately be GC'ed.

See also: When and how are classes garbage collected in Java?

Notes:

1. A string literal (JLS 3.10.5) is a string that appears in Java source code; e.g.

     "abc"            // string literal
   new String(...)  // not a string literal
   

2. A string produced by evaluation of (compile-time) constant expression (JLS 15.28) may also be interned.

      "abc" + 123      // this is a constant expression
   

3. Strictly speaking, not all String literals are interned:

   • If a String literal only appears in the source code as a sub-expression of a constant expression, then the literal may not appear in the ".class" file in any form. Such a literal won't be interned because it won't exist at runtime.

   • In Java 9+, string concatenations involving literals and values that are not compile time constants may be handled differently. Now, at the option of the bytecode compiler, a string concatenation like the following:

      int x = 42;   // not a compile time constant
     String s = "prefix " + x + " suffix";
     

     may result in a string constant like the following being interned:

      "prefix \1 suffix"
     

     At runtime, the above string constant is used as the "recipe" for generating a dynamic concatenation method. The original string literals (i.e. "prefix " and " suffix") would not turn into interned string objects.

     Kudos to @Holger for pointing this out. More details are in JEP 280 and the javadoc for StringConcatFactory.

4. Prior to Java 7, the string pool was in PermGen. For some versions of Java, garbage collection of PermGen was not enabled by default if you selected the CMS collector. But CMS was never the default collector AND there was a flag to enable PermGen collection by CMS. (And nobody should be developing code for Java 6 and earlier anymore.)

String objects which are in the string pool will not be garbage collected. Other String objects will be garbage collected if you don't have reference to it in your program execution.

You may ask which string objects goes to string pool.Objects in the string pool are either:

• Compile time literals (e.g.String s1 = "123";)

• Interned String objects in the runtime (e.g. String s2 = new String("test").intern();)

Both s1 and s2 reference a string object in the string pool.

Any objects which are created at run time and not interned will act as a normal object and reside in heap memory. These objects can be garbage collected.

An example of this would be: String s3 = s1 + s2;

Here, s3 references a string object which resides in heap memory alongside other objects (not in the String pool).

Before Java 7 the string pool resided in Permanent Generation space. So string literals were never garbage collected (which also led to out of memory issues many a times) After Java 7, string pool is placed in heap space, which is garbage collected by the JVM. It also reduces the chances of getting Out of memory issues in JVM.