StringBuffer and StringBuilder principles and differences

StringBuffer and StringBuilder principles and differences
In fact, you only need to find out the answer to Google's big gods: The methods and functions in StringBuffer and StringBuilder are completely equivalent, but most of the methods in StringBuffer are modified using the synchronized keyword, therefore, it is thread-safe, and StringBuilder does not have this modifier and can be considered as thread-safe. In order to better understand the above answer, we should directly look at the source code implementation of StringBuffer and StringBuilder. As a programmer, "If you have doubts, look at the source code" is the right path, I can say it responsibly. Of course, you have to be qualified! In the implementation of jdk, both StringBuffer and StringBuilder inherit from AbstractStringBuilder. For the Security and non-security of multithreading, you can see a bunch of synchronized before the method in StringBuffer. Here, let's talk about the implementation principle of AbstractStringBuilder: We know that using StringBuffer is nothing more than to improve the efficiency of string connection in java, because using + for string connection directly, jvm creates multiple String objects, causing certain overhead. AbstractStringBuilder uses a char array to store the string to be appended. the char array has an initial size. when the length of the append string exceeds the current char array capacity, the char array is dynamically expanded, that is, re-apply for a larger memory space, and then copy the current char array to the new location, because the overhead of re-allocating memory and copying is large, therefore, every time you re-apply for a memory space, you must apply for a memory space that is greater than the memory space you currently need. This is twice the size. Next, have some fun! The following information is displayed in Google: [StringBuffer starts with JDK 1.0.
StringBuilder starts with JDK 1.5

From JDK 1.5, connection operations with string variables (+) are performed.
Implemented by StringBuilder. Previously, this operation was implemented by StringBuffer .] Let's look at the execution process through a simple program: LIST 1 Buffer. java[Java]View plaincopy

1. Public class Buffer {
2. Public static void main (String [] args ){
3. String s1 = "aaaaa ";
4. String s2 = "bbbbb ";
5. String r = null;
6. Int I = 3694;
7. R = s1 + I + s2;
9. For (int j = 0; I <10; j ++ ){
10. R + = "23124 ";
11. }
12. }
13. }

Use the javap-c Buffer command to view its bytecode: List 2 Buffer-class bytecode maps List 1 and list 2, in the bytecode in Listing 2, the ldc command loads the "aaaaa" string from the constant pool to the top of the stack, and istore_1 saves "aaaaa" to variable 1, which is the same as the subsequent one, sipush is a constant value of a short INTEGER (-32768 ~ 32767) push to the top of the stack. Here is the constant "3694". For more Java instruction sets, see another article "Java instruction set ". Let's see 13, 13 ~ 17 is a new StringBuffer object and calls its initialization method, 20 ~ 21 is to press variable 1 to the top of the stack through aload_1. As mentioned above, variable 1 is placed with the string constant "aaaaa ", then, the "aaaaa" is spliced by calling the append method of StringBuffer through the command invokevirtual. The next 24 ~ 30. Finally, call the toString function of StringBuffer in 33 to obtain the String result and store it in variable 3 through astore. Someone may say, "since the JVM uses StringBuffer internally to connect strings, we don't need to use StringBuffer, just use" +! ". Yes? Of course not. As the saying goes, "there are reasons for this". Let's continue to look at the bytecode corresponding to the loop. 37 ~ 42 is some preparations before entering the for loop, 37, 38 is to set j to 1. 44 here, we use if_icmpge to compare j and 10. If j is greater than 10, we will jump to 73 directly, that is, the return Statement will exit the function; otherwise, it will enter the loop, that is, 47 ~ The Byte Code of 66. Here we only need to check 47 to 51 to see why we need to use StringBuffer in the code to process string connections, this is because the jvm requires a new StringBuffer object to process string connections each time the "+" operation is executed, which results in a high overhead when many string connection operations are involved.