Difference between concatenating strings and using StringBuffer append
The static content has been hard coded in Java files like this:
String s = "<span class=\"className\">StaticContent</span>";
It has to be externalized using ResourceBundle objects.
A simple method of doing it is:
String s = "<span class=\"className\">" +
ResourceBundleObject.getString("StaticContent.key") + "</span>";
The second method is using StringBuilder object:
StringBu开发者_运维问答ilder sb = new StringBuilder();
sb.append("<span class=\"className\">");
sb.append(ResourceBundleObject.getString("StaticContent.key"));
sb.append("</span>");
String s = sb.toString();
Does second method have advantage over the first one (in terms of resources consumed)?
It's easier to use first method as it involves very less editing.
One concatenation of Strings creates a new String object:
"a" + "b" + "c" + "d" // 4 Strings
"ab" // 1 String
"abc" // 1 String
"abcd" // 1 String
// 7 String instances in total (& in theory / worst case)
StringBuilder creates less objects:
StringBuilder sb = new StringBuilder("a").append("b").append("c").append("d")
// 4 Strings, 1 StringBuilder
= 5 objects (in theory/worst case)
But the compiler is aware of this problem and if you look at the class files byte code, often enough you see that string concatenations have been replaced with StringBuilder and append. Haveing that in mind, you can focus on readable code and leave it to the compiler to find the most performant solution.
Personally, I only use a dedicated StringBuilder if I have to assemble large Strings (like java source or html pages) or if I use loops to assemble the Strings, like this:
String result = "";
for (int i = 0; i < 100; i++)
result += "."; // Ouch - this should be done with StringBuilder
In this case, there is no performance advantage of using an explicit StringBuilder
.
The JLS states that the Java compiler is allowed to compile a sequence of String concatenation subexpressions into an equivalent creation of a temporary StringBuilder
and sequence of append
calls. In this case, the optimization works, and the compiler will generate bytecodes that are effectively the same as the bytecodes you'd get if you used StringBuilder
yourself. In other words, the only net effect of using StringBuilder
is to make your code harder to read.
You are only likely to get a performance advantage by using StringBuilder
explicitly if your code does concatenation in a loop. However, if you build long strings this way, the performance difference can be significant.
Strings are immutable - once they're created they cant be modified.
So if you do string1 + string2, string2 isnt merely copied to the end of string1 - a new string is created that holds the concatenated string. If you do a whole sequence of these operations it can get very expensive.
You should note, howevere, that under the covers, the JVM converts string cncatenation code (using +) into a sequence of stringbuilder calls. So in fact your two snippets should compile to the smae (or very similar) bytecode.
As ever, test and measure if you want optimal performance.
1. First One will create three Instance. // "" will create 2 temp instance , concat using + another instance
2. Second One wil create One Instance.
- the String class is an immutable class.
- It will never really change internally. When you use the operator
it actually do not change the string itself, but rather return a
new String.
- StringBuilder is more efficient as it is designed with no thread-safety in mind.
- Will appends to it the previous value of the string.
- if you are building long strings, then using StringBuilder
- no synchronization is performed.
- StringBuilder lacks some methods split,search
The second method has definitely advantage over the first since in case of first we are creating a new string object with the new operator which is Immutable but in case of String Builder as the name suggests we are appending to the original string,thereby we are not creating extra new String objects,Thereby saving memory in case of String Buiilder.String Builder like String Buffer is also Mutable.
精彩评论