Java that point--stringbuffer and StringBuilder principle and difference _java

Recently looking for a job, the examiner asked me a simple topic: "StringBuffer and StringBuilder differences, what are their application scenarios?" , the following small series of answers to share to everyone, convenient for everyone to learn later, so also make a record.

In fact, as long as the search for Google's great God has the answer: StringBuffer and StringBuilder in the method and function is completely equivalent, but the method in StringBuffer mostly used the synchronized keyword to decorate, So it is thread-safe, and StringBuilder does not have this modification and can be considered thread insecure.

In order to better understand the answer above, or directly to see StringBuffer and StringBuilder of the source code to achieve more really, as a program ape, "There is doubt, look at the source" is the right way, I can responsibly say, of course, have the conditions to do!

In the implementation of JDK, both StringBuffer and StringBuilder are inherited from Abstractstringbuilder, For multithreading security and insecurity see StringBuffer in front of a heap of synchronized is probably understood.

Here is a casual talk about the implementation of Abstractstringbuilder: We know that using StringBuffer is nothing more than a way to improve the efficiency of string concatenation in Java, because the JVM creates multiple string objects by using + directly to concatenate strings. Therefore, a certain amount of overhead is incurred. In Abstractstringbuilder, a char array is used to hold the string that needs to be append, the char array has an initial size, and the char array is dynamically extended when the append string length exceeds the current char array capacity. You can also reapply for a larger amount of memory, and then copy the current char array to a new location, because the overhead of reallocating memory and copying is relatively high, so each time you reapply for the memory space, it is twice times more expensive than the current required memory space.

Next, play some fun!

There are some information coming out of Google:

【
StringBuffer started with JDK 1.0
StringBuilder started with JDK 1.5

Starting with JDK 1.5, a concatenation operation with a string variable (+) is used internally by the JVM
StringBuilder to implement, and the previous operation was implemented by StringBuffer.
】

We look at the process of its execution through a simple program:

Listing 1 Buffer.java

public class Buffer {public 
static void Main (string[] args) { 
String s1 = ' aaaaa '; 
String s2 = "BBBBB"; 
String r = null; 
int i = 3694; 
R = S1 + i + s2; 

for (int j=0;i<10;j++) { 
r+= "23124"; 
} 
} 

Use the command javap-c buffer to view its bytecode implementation:

Listing 2 Buffer class byte code

As with listing 1 and Listing 2, the LDC directive in the bytecode of listing 2 loads the "AAAAA" string from the constant pool to the top of the stack, Istore_1 saves "AAAAA" to the variable 1, followed by sipush a short integer constant value ( -32768~32767) Push to the top of the stack, here is the constant "3694", more Java instruction set see another article "Java instruction set".

Let's see directly that 13,13~17 is a new StringBuffer object and call its initialization method, 20~21 is first by aload_1 the variable 1 to the top of the stack, said in the previous variable 1 is the string constant "AAAAA", Then through the instruction Invokevirtual call StringBuffer Append method will "AAAAA" stitching up, subsequent 24~30 the same. Finally, the 33 call StringBuffer's ToString function gets the string result and saves it to the variable 3 by Astore.

See here may be said, "since the JVM used StringBuffer to connect the string, then we do not use the StringBuffer, directly with the" + "on the line! “。 Are you? No, of course not. As the saying goes, "there is a reason for it", let's continue to look at the byte code corresponding to the loop behind it.

37~42 are some of the preparations before entering the For loop, 37,38 is to set J to 1. 44 here through If_icmpge to compare J with 10, if J is greater than 10 then jump directly to 73, also that return statement exit function, otherwise enter the loop, that is, the 47~66 byte code. Here we only need to look at 47 to 51 to see why we are using StringBuffer in our code to handle string concatenation, because the JVM has to new a StringBuffer object to handle string concatenation each time the "+" operation is performed. This can be expensive when you have a lot of string concatenation operations involved.