How Java do the string concatenation using "+"?
I read about the way Java works with += operator, using StringBuilder.
Is it the same with a ("a" + "b") operation?
Solution 1:
If you combine literal strings (literally "foo" + "bar"), the compiler does it at compile-time, not at runtime.
If you have two non-literal strings and join them with +, the compiler (Sun's, anyway) will use a StringBuilder under the covers, but not necessarily in the most efficient way. So for instance, if you have this:
String repeat(String a, int count) {
String rv;
if (count <= 0) {
return "";
}
rv = a;
while (--count > 0) {
rv += a;
}
return rv;
}
...what the Sun compiler will actually produce as bytecode looks something like this:
String repeat(String a, int count) {
String rv;
if (count <= 0) {
return "";
}
rv = a;
while (--count > 0) {
rv = new StringBuilder().append(rv).append(a).toString();
}
return rv;
}
(Yes, really — see the disassembly at the end of this answer.) Note that it created a new StringBuilder on every iteration, and then converted the result to String. This is inefficient (but it doesn't matter unless you're doing it a lot) because of all of the temporary memory allocations: It allocates a StringBuilder and its buffer, quite possibly reallocates the buffer on the first append [if rv is more than 16 characters long, which is the default buffer size] and if not on the first then almost certainly on the second append, then allocates a String at the end — and then does it all again on the next iteration.
You could gain efficiency, if necessary, by rewriting it to explicitly use a StringBuilder:
String repeat(String a, int count) {
StringBuilder rv;
if (count <= 0) {
return "";
}
rv = new StringBuilder(a.length() * count);
while (count-- > 0) {
rv.append(a);
}
return rv.toString();
}
There we've used an explicit StringBuilder and also set its initial buffer capacity to be large enough to hold the result. That's more memory-efficient, but of course, marginally less clear to inexperienced code maintainers and marginally more of a pain to write. So if you find a performance issue with a tight string concat loop, this might be a way to address it.
You can see this under-the-covers StringBuilder in action with the following test class:
public class SBTest
{
public static final void main(String[] params)
{
System.out.println(new SBTest().repeat("testing ", 4));
System.exit(0);
}
String repeat(String a, int count) {
String rv;
if (count <= 0) {
return "";
}
rv = a;
while (--count > 0) {
rv += a;
}
return rv;
}
}
...which disassembles (using javap -c SBTest) like this:
Compiled from "SBTest.java"
public class SBTest extends java.lang.Object{
public SBTest();
Code:
0: aload_0
1: invokespecial #1; //Method java/lang/Object."<init>":()V
4: return
public static final void main(java.lang.String[]);
Code:
0: getstatic #2; //Field java/lang/System.out:Ljava/io/PrintStream;
3: new #3; //class SBTest
6: dup
7: invokespecial #4; //Method "<init>":()V
10: ldc #5; //String testing
12: iconst_4
13: invokevirtual #6; //Method repeat:(Ljava/lang/String;I)Ljava/lang/String;
16: invokevirtual #7; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
19: iconst_0
20: invokestatic #8; //Method java/lang/System.exit:(I)V
23: return
java.lang.String repeat(java.lang.String, int);
Code:
0: iload_2
1: ifgt 7
4: ldc #9; //String
6: areturn
7: aload_1
8: astore_3
9: iinc 2, -1
12: iload_2
13: ifle 38
16: new #10; //class java/lang/StringBuilder
19: dup
20: invokespecial #11; //Method java/lang/StringBuilder."<init>":()V
23: aload_3
24: invokevirtual #12; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
27: aload_1
28: invokevirtual #12; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
31: invokevirtual #13; //Method java/lang/StringBuilder.toString:()Ljava/lang/String;
34: astore_3
35: goto 9
38: aload_3
39: areturn
}
Note how a new StringBuilder is created on each iteration of the loop and created using the default buffer capacity.
All of this temporary allocation stuff sounds ugly, but again, only if you're dealing with substantial loops and/or substantial strings. Also, when the resulting bytecode is run, the JVM may well optimize it further. Sun's HotSpot JVM, for instance, is a very mature JIT optimizing compiler. Once it's identified the loop as a hot spot, it may well find a way to refactor it. Or not, of course. :-)
My rule of thumb is I worry about it when I see a performance problem, or if I know I'm doing a lot of concatenation and it's very likely to be a performance problem and the code won't be significantly impacted from a maintainability standpoint if I use a StringBuilder instead. The rabid anti-premature-optimization league would probably disagree with me on the second of those. :-)
Solution 2:
No. It's not the same using
StringBuilderthan doing"a" + "b".
In Java, String instances are immutable.
So, if you do:
String c = "a" + "b";
You are creating new Strings every time you concatenate.
On the other hand, StringBuilder is like a buffer that can grow as it needs when appending new Strings.
StringBuilder c = new StringBuilder();
c.append("a");
c.append("b"); // c is only created once and appended "a" and "b".
Rule of the thumb is (changed thanks to the comments I got):
If you are going to concatenate a lot (i.e., concatenate inside a loop, or generating a big XML formed by several string concatenated variables), do use StringBuilder. Otherwise, simple concatenation (using + operator) will be just fine.
Compiler optimizations also play a huge role when compiling this kind of code.
Here'sfurther explanation on the topic.
And more StackOVerflow questions on the issue:
Is it better to reuse a StringBuilder in a loop?
What's the best way to build a string of delimited items in Java?
StringBuilder vs String concatenation in toString() in Java