Is the Head First Java book wrong about Strings and GC?

[raindog308]

So I'm looking at the second edition of the Head First Java book and on page 675, it discusses Strings and garbage collection.

It gives this example code:

String s = "0";
for (int x = 1; x < 10; x++ ) {
  s = s + x;
}

And then says:

"Whenever you make a new String, the JVM puts it into a special part of memory called the 'String Pool' (sounds refreshing doesn't it.?). If there is already a String in the String Pool with the same value, the JVM doesn't create a duplicate, it simply refers your reference variable to the existing entry. TheJVM can get away with this because Strings are immutable; one
reference variable can't change a String's value out from under another reference variable referring to the same String.

"The other issue with the String pool is that the Garbage Collector doesn't go there. So in our example unless by coincidence you later happen to make a
String called "01234", for instance, the first nine Strings created in our for loop will just sit around wasting memory."

Really?

I thought that any strings created in the code were in the String pool, but other strings were normal objects just like other things, from a GC perspective.

So if you say in your source:

String s = "some string";

The "some string" part of that does truly live forever in the String Pool, but all other String objects are garbage collected as normal.

For example, when I compile and run this...

class MemTest {
        public static final void main (String[] args) {
                for (int i=1; i<1000000; i++) {
                        String s = String.valueOf(i);
                }
        }
}

...I don't see memory ballooning - the GC seems to be collecting the objects quite nicely (running with java -verbose:gc):

[GC 8128K->224K(30784K), 0.0013690 secs]
[GC 8352K->192K(30784K), 0.0008570 secs]
[GC 8320K->192K(30784K), 0.0006000 secs]
[GC 8320K->192K(38912K), 0.0006030 secs]
[GC 16448K->192K(38912K), 0.0009020 secs]
[GC 16448K->192K(54144K), 0.0007010 secs]

[quad64bit]

I don't know much about the inner workings of the JVM, but I have verified your test:

2146000000: 64
2146100000: 77
2146200000: 73
2146300000: 69
2146400000: 65
2146500000: 77
2146600000: 73
2146700000: 69
2146800000: 66
2146900000: 78
2147000000: 74
2147100000: 70
2147200000: 66
2147300000: 79
2147400000: 75

The first number is the iteration (0 to Integer.max), the second is the free memory. This app ran without issue all the way up. Had I attempted to do a concat or something, I would def. have bombed in just a couple seconds. So it seems in the case you described, the JVM is definitely allowing GC to happen to the String pool, or the String pool is now allowing an infinite number of unused strings to stack up.

[quad64bit]

PS, it would seem to me that if all one-use strings stayed around forever, then every single java app that reads and writes many strings would bloat up. I have not found this to be the case at all, so I think the book is either incorrect, or is pointing at something that is poorly described.