StringBuilder vs StringBuffer, Choose StringBuilder if possible

StringBuilder is an unsynchronized version of StringBuffer. That is, its instances are not safe for use by multiple threads. The upside is that it’ll be faster than StringBuffer in most implementations as well. Think of Vector vs. ArrayList.
Now let’s think about our most common use of StringBuffer. What is it? I bet it’s inside a method, as a local variable, to concatenate a bunch of strings, just like this:

public String buildHQLString() {
    StringBuffer sb = new StringBuffer();
    sb.append("something");
    // append a lot more things here
    return sb.toString();
}

It is safe to replace StringBuffer with StringBuilder in this very common case, because every thread has its own stack, in which local variables reside. So, next time you’re typing “StringBuffer sb = “, it’s a good time to reflect whether “StringBuilder sb = ” is more appropriate.

(In fact, I can’t think of a good reason to use StringBuffer now. Have any of you ever come across a case where you just absolutely have to use StringBuffer instead of StringBuilder? If anyone can enlighten me with a good, legit, uncontrived usage of StringBuffer in the comments, I’ll be grateful.)

But the default StringBuilder constructor, which has the initial capacity hardcoded to 16! So it results in a lot of extendCapacity() calls. So provide the reasonable value to StringBuilder(int capacity), instead of using StringBuilder no-arg constructor–BUT spend too much time on this and you’re doing the root of all evil, premature optimization.

Difference between concat and append function

The concat function is present in String class but the append functin is present in StringBuffer/StringBuilder class.
The concat function concats the string on which it is invoked with the string passed as parameter to this function. The result returned is a new String with both the strings concatanated.

The append function appends a String to the String represent by the StringBuffer/StringBuilder object on which the append() method is invoked. The result returned is the same StringBuffer/StringBuilder object on which this method was invoked.

How Many String Objects Are Created ?

Consider the code fragment shown below:

String s1="abc";
String s2="def"
System.out.println(s1 + " " + s2);

The question is how many String objects are created after the last line is compiled by Java.

To solve questions like this one can use Eclipse decompiler (JAD) to see how the Java compiler actually interpreted that third line.

1) For  any java developer it will be very easy to tell that first two lines create one object each and hence two objects in first two line.

2) The third line in the above code is interpreted by JDK 1.5 compiler as:
system.out.println((new StringBuilder(string.valueOf(s1))).append(" ").append(s2).toString());

This clearly tells us that 2 more string objects (" " and "abc def") are created in the last line.
3) Hence we can say that 4 String and 1 String Builder objects are created by that piece of code.

So the following code shows it all:

string s1 = "abc";
string s2 = "def";
system.out.println((new StringBuilder(string.valueOf(s1))).append(" ").append(s2).toString());

Difference between String StringBuffer and StringBuilder

String is immutable whereas StringBuffer and StringBuilder can change their values.
The only difference between StringBuffer and StringBuilder is that StringBuilder is unsynchronized whereas StringBuffer is synchronized. So when the application needs to be run only in a single thread then it is better to use StringBuilder. StringBuilder is more efficient than StringBuffer.
Criteria to choose among String, StringBuffer and StringBuildern :

1. If your text is not going to change use a string Class because a String object is immutable.
2. If your text can change and will only be accessed from a single thread, use a StringBuilder because StringBuilder is unsynchronized.
3. If your text can changes, and will be accessed from multiple threads, use a StringBuffer because StringBuffer is synchronous.