In fact, just find Google God has the answer: StringBuffer and StringBuilder in the method and function is completely equivalent, but stringbuffer in most of the methods used in the Synchronized keyword to decorate, It is therefore thread-safe, and StringBuilder does not have this modification and can be considered thread insecure. In order to better understand the above answer, or directly see StringBuffer and StringBuilder the source of the implementation of the actual comparison, as a procedural ape, "there is doubt, look at the source code" is the right path, I can responsibly say, of course, have the conditions! In the implementation of JDK, both StringBuffer and StringBuilder inherit from Abstractstringbuilder, For multi-threaded security and non-security see stringbuffer in front of the method of a heap of synchronized is probably understood. Here is a casual talk about the Abstractstringbuilder principle: we know that the use of stringbuffer is nothing more than to improve the efficiency of string connections in Java, because directly using + for string connections, the JVM creates multiple string objects, Therefore, a certain amount of overhead is incurred. A char array is used in Abstractstringbuilder to hold the string that needs to be append, and the char array has an initial size that dynamically expands the char array when the string length of append exceeds the capacity of the current char array. That is, re-apply a larger memory space, and then copy the current char array to a new location, because the cost of reallocating memory and copying is relatively large, so each re-application of memory space is a request greater than the current need of memory space, here is twice times. Next, play some fun! There's a little bit of information coming out of Google: "StringBuffer starts with JDK 1.0
StringBuilder starts at JDK 1.5
Starting with JDK 1.5, a connection operation with a string variable (+) is used internally by the JVM
StringBuilder, which was implemented by StringBuffer. "We look at the flow of execution through a simple program: Listing 1 Buffer.java
[Java]View Plaincopy
- 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 bytecode corresponds to Listing 1 and listing 2, in the bytecode of Listing 2, the LDC directive loads the "AAAAA" string from the constant pool to the top of the stack, istore_1 "AAAAA" to the variable 1 , as in the following, Sipush is pushing a short integer constant value ( -32768~32767) to the top of the stack, here is the constant "3694", and more Java instruction sets see another article, "Java instruction set". Let us directly see that 13,13~17 is a new StringBuffer object and call its initialization method, 20~21 is the first through the aload_1 the variable 1 to the top of the stack, the previous said that the variable 1 is the string constant "AAAAA", Then through the instruction Invokevirtual call StringBuffer Append method will "AAAAA" splicing together, the subsequent 24~30 the same. Finally, in 33, call StringBuffer's ToString function to get a string result and save it through Astore to variable 3. See here may be said, "since the JVM used StringBuffer to connect strings, then we do not have to 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 corresponding bytecode in the back loop. 37~42 are some of the preparatory work before entering the For loop, 37,38 is to set J to 1. 44 here The J and 10 are compared by IF_ICMPGE, if J is greater than 10 jumps directly to 73, that is, return statement exit Function, otherwise enter the loop, that is, 47~66 bytecode. Here we just need to look at 47 to 51 to see why we're using StringBuffer in our code to handle string connections, because each time we execute a "+" operation, the JVM will have to new a StringBuffer object to handle the string connection. This can be expensive when it involves a lot of string connection operations.
Principle and difference of stringbuffer and StringBuilder
