Results 1 to 3 of 3
  1. #1
    raindog308 is offline Member
    Join Date
    Jan 2011
    Rep Power

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

    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:

    Java 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."


    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...

    Java Code:
    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):

    Java Code:
    [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]

  2. #2
    quad64bit's Avatar
    quad64bit is offline Moderator
    Join Date
    Jul 2009
    Rep Power


    I don't know much about the inner workings of the JVM, but I have verified your test:
    Java Code:
    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.

  3. #3
    quad64bit's Avatar
    quad64bit is offline Moderator
    Join Date
    Jul 2009
    Rep Power


    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.

Similar Threads

  1. Java Project Head, Kochi
    By enroutehuma in forum Jobs Offered
    Replies: 1
    Last Post: 11-09-2009, 06:44 PM
  2. Monitor Disc Head Using Java
    By zorroforce in forum New To Java
    Replies: 4
    Last Post: 09-18-2009, 07:51 AM
  3. javamail exception: 557 mail head error
    By allanwakes in forum Java Servlet
    Replies: 2
    Last Post: 10-02-2008, 11:05 AM
  4. HEAD first by kathy sierra
    By j2vdk in forum New To Java
    Replies: 0
    Last Post: 08-30-2008, 01:08 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts