StringBuffer and Memory

[John Ryan]

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:

 
String x = "abc";
x = x.concat("def");
System.out.println("x = " + x); // output is "x = abcdef"

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 :

  
StringBuffer sb = new StringBuffer("abc");
sb.append("def");
System.out.println("sb = " + sb); // output is "sb = abcdef"

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]

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]

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]

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 that

String s = "";
for (int i = 0; i < 100; i++) {
   s += " " + i;
}

Is much more expensive than

StringBuffer sb = new StringBuffer();
for (int i = 0; i < 100; i++) {
   sb.append(" ").append(i);
}
String s = sb.toString();

And make sure you don't fall into the trap that I've seen numerous developers fall into:

StringBuffer sb = new StringBuffer();
for (int i = 0; i < 100; i++) {
   sb.append(" " + i);
}
String s = sb.toString();

This is no better than the very first code listing.

- Peter

[Corey McGlone]

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.

[John Ryan]

Okay thanks for all this Peter. Much clearer on the issue now. Onto the next chapter