Difference between String and StringBuffer in java
Yes, new String objects get created for "try"
and "this"
. The benefit here is that the StringBuffer stores the string of characters internally as a dynamically resized array.
It's more obviously beneficial if we were to concatenate more than two Strings:
"try" + "this" + "test"
This would potentially create 5 String objects because you need intermediate values. (Technically concatenation of literals is performed at compile time so this is just a conceptual example.) It would also be typical for a compiler to refactor the above snippet in to using StringBuilder
anyway if they were not literals.
StringBuilder
is a newer and non-synchronized version of StringBuffer
. In general, you should prefer StringBuilder
. The difference between these two classes is covered in "StringBuilder and StringBuffer in Java".
Difference between String , StringBuilder & StringBuffer?
I will clarify the thread-safety point. The other points are well described in older questions.
It's quite rare case when StringBuffer
suits your needs. While it's thread-safe it doesn't mean you will get what expected when using it from different threads. For example, suppose you have the following code:
StringBuffer buf = new StringBuffer();
public void appendMessage(String message) {
buf.append("INFO: ").append(message).append(System.lineSeparator());
}
If you are using it in multithread environment it will not fail, but you may end up having content like this:
INFO: INFO: thread1 message
thread2 message
That's because individual append
calls are synchronized, but the whole sequence is not.
In order to ensure that your messages are separately added, you must have an external synchronization like this:
Object lock = new Object();
StringBuilder buf = new StringBuilder();
public void appendMessage(String message) {
synchronized(lock) {
buf.append("INFO: ").append(message).append(System.lineSeparator());
}
}
Here the whole sequence of calls is synchronized, so you will have the whole message appended at once. And as you are using the external synchronization, StringBuilder
will work fine as well.
So in general StringBuffer
should not be used in the most of situations.
What is the difference between String and StringBuffer in Java?
String
is used to manipulate character strings that cannot be changed (read-only and immutable).
StringBuffer
is used to represent characters that can be modified.
Performance wise, StringBuffer
is faster when performing concatenations. This is because when you concatenate a String
, you are creating a new object (internally) every time since String
is immutable.
You can also use StringBuilder
which is similar to StringBuffer
except it is not synchronized. The maximum size for either of these is Integer.MAX_VALUE
(231 - 1 = 2,147,483,647) or maximum heap size divided by 2 (see How many characters can a Java String have?).
More information here.
Difference between StringBuilder and StringBuffer
StringBuffer
is synchronized, StringBuilder
is not.
String, StringBuffer, and StringBuilder
Mutability Difference:
String
is immutable, if you try to alter their values, another object gets created, whereas StringBuffer
and StringBuilder
are mutable so they can change their values.
Thread-Safety Difference:
The difference between StringBuffer
and StringBuilder
is that StringBuffer
is thread-safe. 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
.
Situations:
- If your string is not going to change use a String class because a
String
object is immutable. - If your string can change (example: lots of logic and operations in the construction of the string) and will only be accessed from a single thread, using a
StringBuilder
is good enough. - If your string can change, and will be accessed from multiple threads, use a
StringBuffer
becauseStringBuffer
is synchronous so you have thread-safety.
Where to use StringBuffer/StringBuilder than String
Below is the main difference between these three most commonly used classes.
- String class objects are immutable whereas StringBuffer and
StringBuilder objects are mutable. - StringBuffer is synchronized while StringBuilder is not synchronized.
- Concatenation operator "+" is internal implemented using either
StringBuffer or StringBuilder.
Criteria to choose among String, StringBuffer and StringBuilder
- If the Object value is not going to change use String Class because a
String object is immutable. - If the Object value can change and will only be accessed from a
single thread, use a StringBuilder because StringBuilder is
unsynchronized. - In case the Object value can change, and will be modified by multiple
threads, use a StringBuffer because StringBuffer is synchronized.
Differences between these two sets of code (String x Stringbuffer)
StringBuffer would be used as follows:
StringBuffer str = new StringBuffer ("Stanford ");
str.append("Lost!!");
for a "private static final String" you can't really use a StringBuffer or at least there isn't any performance gain, or possibly even performance loss!
StringBuffer is for use inside methods.
Also, as your variable is a private static final, all the '+' modifiers will happen at compile time and will be optimised anyway so you will be highly optimised. No need to change anything here.
Related Topics
Configuration Using Annotation @Springbootapplication
Efficiently Finding the Intersection of a Variable Number of Sets of Strings
Hashcode and Equals for Hashset
Favor Composition Over Inheritance
Adding New Paths for Native Libraries at Runtime in Java
Why Aren't Integers Cached in Java
How to Compress a String in Java
Rethrowing an Exception: Why Does the Method Compile Without a Throws Clause
Why Is "Out of Range" Not Thrown for 'Substring(Startindex, Endindex)'
Java: Infinite Loop Using Scanner In.Hasnextint()
How to Calculate the Elapsed Time of an Event in Java
Java: Global Exception Handler
Jackson Change JSONignore Dynamically
JSON Parameter in Spring MVC Controller
Java.Rmi.Connectexception: Connection Refused to Host: 127.0.1.1;
Parsing a Hexadecimal String to an Integer Throws a Numberformatexception