Java Explain: why String immutable make StringBuffer MORE efficient

Because Strings are immutable, to manipulate Strings, such as to concatenate Strings, you have to create new String objects, since obviously, you can't change the state of existing String objects. Whereas with a StringBuffer or StringBuilder, you create one object and simply change its state. If you're doing some major String concatenation in a for loop for instance, this object creation can get very expensive.

That being said, I see many posts here critical of simple String concatenation that don't involve large-scale concatenation, and in that situation using a StringBuffer or StringBuilder is an example of premature and unnecessary optimization.

Also note that you should use StringBuilder preferentially over StringBuffer unless your application needs to access the object in multiple threads and doesn't mind the extra overhead that this incurs.

What it meant to say to is that since String is immutable therefore it is better to use StringBuffer (or StringBuilder) for String manipulation since you're not creating new object every time you change underlying String.

All the other posts definitely answer the question. I would add that you should always choose StringBuilder over StringBuffer. StringBuffer has built-in thread synchronization, which is a whole lot of locking overhead that you will almost never need. StringBuilder does not have this, and is therefore faster.

In fact, even if you want thread safety, here are some very good reasons not to use StringBuffer.

The concept of immutable can easily be explained with this example

String s1 = "Hello";
String s2 = "Hi";
String s3 = "Hello";

if (s1 == s2){ System.out.println("s1==s2");}
if (s1 == s3){ System.out.println("s1==s3");}

s1 = "Hi";

if (s1 == s2){ System.out.println("s1==s2");}
if (s1 == s3){ System.out.println("s1==s3");}

If you execute this piece of code you would get s1==s3 and s1==s2. What does this example explains?

When you created s1, the compiler created a string "Hello" in its string table (i dun remember its exact name). When you created s2, it create new object "Hi". Now when you created s3, compiler knows that there is an object "Hello" already in its string table, so why not just refer s3 to it. So s1=s3 (memory vise). Same happened when you assigned value "hi" to s1, compiler could see that "hi" is already in the memory being pointed by s3, so it pointed it to s1 as well.

In case of StringBuffer, Compiler allocates memory to the object, which you can manipulate rather "pool" as in case of String.