1

I see many Q&A about Immutable String saying that JVM actually create a new reference when we do the following:

String text = "apple";
text = "orange"; // a new reference is created

My question is, what happen to the previous reference "apple"? Since Java Garbage Collection is automatic, does it means that there is no intentional way to re-claim the memory?

EDIT: The reason I am asking this question is that I would like to know how should I handle String variables in future.

Does String Literals get cleared by GC? If not, wouldn't the pool going to get so huge until a point where it goes out of memory? Considering if the program receives different string values from a textbox on the UI, each different values that the user enters are going to add on to the pool.

CodeBender
  • 267
  • 4
  • 14
  • @LuiggiMendoza: actually, no. It will stay in the pool of interned strings. – JB Nizet May 09 '13 at 17:25
  • 1
    @Edison: A new reference is not created. The text variable references another object, which is the string literal "orange". String literals are handled in a special way by the JVM, so if your question is not specifically about string literals, please choose another example. – JB Nizet May 09 '13 at 17:27
  • @JBNizet I knew that, it was just a bad joke =\ – Luiggi Mendoza May 09 '13 at 17:28
  • @LuiggiMendoza: Oh, sorry then. – JB Nizet May 09 '13 at 17:30
  • In http://www.javasync.com/2009/08/how-jvm-handles-strings-objects-and.html, it says "JVM on the other hand does garbage collection that is it periodically checks for dangling references on the string literals and on other constants.Whenever one is encountered JVM sweeps it from the memory pool." Does it means that GC will clear the string literals? – CodeBender May 09 '13 at 17:48
  • Looks like String Literals will be cleared by GC. Thanks guys! – CodeBender May 09 '13 at 18:00
  • @Edison: just saw your edit. A program will receive String instances from a text box, but these String instances won't be interned. Only String **literals** are interned by the JVM. The String literals are the Strings that are hard-coded in the source code (and bytecode) of the program. SO the number of STring literals can't grow without bounds. – JB Nizet May 09 '13 at 21:50

3 Answers3

3

There is no way to intentionally reclaim the memory even with System.gc() (which is just a suggestion to the JVM).

Even when garbage collection runs, "apple" won't necessarily be reclaimed.

According JLS 3.10.5, string literals are interned in a string pool and thus never garbage collected.

Quoting:

A string literal is a reference to an instance of class String (§4.3.1, §4.3.3).

Moreover, a string literal always refers to the same instance of class String.

This is because string literals - or, more generally, strings that are the values of constant expressions (§15.28) - are "interned" so as to share unique instances, using the method String.intern.

EDIT

According to this answer, even interned Strings can be garbage collected.

Community
  • 1
  • 1
rgettman
  • 176,041
  • 30
  • 275
  • 357
  • `According JLS 3.10.5, string literals are interned in a string pool and thus never garbage collected.` Sorry but I have nowhere seen in that jls part that string literals are never garbage collected..Can you please specify that line ? – Vishal K May 09 '13 at 17:49
  • @VishalK It looks like a took too much of a logical leap. It looks like [interned `Strings` can be garbage collected](http://stackoverflow.com/questions/1091045/is-it-good-practice-to-use-java-lang-string-intern). I'll take that part out of my answer. – rgettman May 09 '13 at 17:53
2

No, you you can't force the GC to run. One thing it is important to realize is the "apple" String won't be destroyed. It was declared as a literal String, so it will go the String pool.

Daniel Pereira
  • 2,720
  • 2
  • 28
  • 40
1

There is no way to explicitly reclaim a completely dereferenced object. You can call System.gc();, but that's merely a suggestion to perform a gc and not a guarantee that a gc will be performed

cmbaxter
  • 35,283
  • 4
  • 86
  • 95