aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes StringBuffer and Memory Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "StringBuffer and Memory" Watch "StringBuffer and Memory" New topic
Author

StringBuffer and Memory

John Ryan
Ranch Hand

Joined: Mar 14, 2001
Posts: 124
Hi all,
Currently doing some preparation for the programmers exam.
The main reason given for using a StringBuffer over Strings is that it prevents a large number of String literals being abandoned in the String literal pool and thus wasting memory.

If we have a code sample as follows:



We got a new String but the downside is that the old String
�abc� has been lost in the String pool, thus wasting memory.

If we used a StringBuffer instead :



we are told that it will save memory.

My question is as follows. In the first piece of code 3 objects would have been created - the literal "abc" would result in an object in the String literal pool, the literal "def" would also result in an object in the String literal pool and finally the concatenation operation would have resulted in a third string. However the String literals "abc" and "def" no longer have a reference they would be "wasting" memory (As an aside does anyone know if String objects are garbaged from the String literal pool. I assume they are!).

The scond piece of code results in the creation of a StringBuffer object. However both the String buffer constructor and the append operation have arguments that are String literals. Are these literals created in the String literal pool. If so this piece of code will also have resulted in 3 objects and the two literals in the String literal pool will not have any references. Thus I cannot see where the memory has been saved??. All help welcome.

John
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by John Ryan:
we are told that it will save memory.
If that's really what you've been told, you've been told nonsense. In either case, both "abc" and "def" will be in the string literal pool. They will be there from the very start. They are not created at run time, and never garbage collected. The very same String objects will be used every time your code is executed (remember, Strings are immutable).

So there is no difference in memory usage. There is however a difference in object creation - the first code listing has better behaviour on the Sun JRE 1.4 because the String.concat() method produces a new String without using an intermediate StringBuffer. Your second listing produces a StringBuffer which is likely to be eventually turned into a String again, so there's one extra object being created.

There is a moral to this story: unless you know exactly what you're doing, don't try to be cleverer than Sun in managing Strings and StringBuffers[1]. You are likely to end up with worse rather than better behaviour.

- Peter

[1] You wouldn't believe the number of outfits who attempted to reduce object churn by implementing a StringBuffer pool. Why this is a bad idea is left as an exercise for the reader. Hint: follow the lifecycle of the char[] that backs both String and StringBuffer.
[ June 04, 2004: Message edited by: Peter den Haan ]
John Ryan
Ranch Hand

Joined: Mar 14, 2001
Posts: 124
Thanks for your comments Peter.

Originally posted by Peter den Haan:
They will be there from the very start. They are not created at run time, and never garbage collected. The very same String objects will be used every time your code is executed (remember, Strings are immutable).


If they arent created at RunTime they must be created at compile time?. This seems a bit strange but Ill take your word for it.

Originally posted by Peter den Haan:

There is a moral to this story: unless you know exactly what you're doing, don't try to be cleverer than Sun in managing Strings and StringBuffers[1]. You are likely to end up with worse rather than better behaviour.

So if StringBuffers arent more performant when is it appropriate to use them - or is there any case for their usage over Strings (unless of course you need some of the functionality provided by StringBuffer which does not exist in String e.g. the insert method)
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by John Ryan:
If they arent created at RunTime they must be created at compile time?. This seems a bit strange but Ill take your word for it.
Well, not quite, and don't take my word for it! It really happens at load time. The string literals that you use are embedded in the .class file produced from your class. When a class is first loaded, its string constants are intern()ed into the JVM-wide pool of String constants. As a consequence, "foo" == "foo" even if the two "foo" literals have been defined in totally different classes or packages. See also String.intern().

So if StringBuffers arent more performant when is it appropriate to use them - or is there any case for their usage over Strings (unless of course you need some of the functionality provided by StringBuffer which does not exist in String e.g. the insert method)
The two things that you need to be aware of are these:
  • Strings are immutable. Whenever you "modify" a String, as in String.concat() for example, you are in fact creating a new String object. This makes a succession of small String modifications relatively expensive.
  • Whenever you concatenate Strings using the "+" operator, an implicit StringBuffer gets created to do the concatenation.
  • This means thatIs much more expensive thanAnd make sure you don't fall into the trap that I've seen numerous developers fall into:This is no better than the very first code listing.

    - Peter
    Corey McGlone
    Ranch Hand

    Joined: Dec 20, 2001
    Posts: 3271
    Nice explanation, Peter. If you don't mind, I might just nab some of this and throw it in my blog. I just think you laid that out particularly well.


    SCJP Tipline, etc.
    John Ryan
    Ranch Hand

    Joined: Mar 14, 2001
    Posts: 124
    Okay thanks for all this Peter. Much clearer on the issue now. Onto the next chapter
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: StringBuffer and Memory
     
    Similar Threads
    Problem with String and StringXxx objects
    Stringbuffer doubt?
    String, String Buffer and String Builder
    String objects are immutable they can be shared. I do no get what this means...please help.
    Doubt in K&B SCJP 5: topic Important Facts About Strings and Memory