Parsing the immutable nature of the Java core class string from the point of view of bytecode and JVM

1. Preface

Recently, I've seen several interesting questions about the Java Core class string.

1. The string class is how to implement its immutable attributes, and the benefits of being designed to be immutable.
2. Why is it not recommended to use the + sign to form a new string, it is recommended to use StringBuilder or StringBuffer.

Flip through some of the online blogs and StackOverflow, combined with their own understanding to do a summary.

2. How the string class implements immutable

A major feature of the string class is the use of the final class modifier.

A class can be declared final if it definition is complete and no subclasses is desired or required.

Because a final class never have any subclasses, the methods of a final class is never overridden.

As defined in the official Java SE 7 Manual, if you think that the class has been defined completely and does not require any subclasses, you can declare the class as a method in the Final,final class that will never be overridden.

In Java, string is designed as an immutable (immutable) class, and once created, the string itself cannot be modified by normal means.

PrivateFinalCharValue[];Once initialized, references cannot be modifiedPublicStringSubstring(IntBeginindex,IntEndIndex){if (Beginindex <0) {throw new Stringindexoutofboundsexception (Beginindex); } if (EndIndex > value.length) { throw new stringindexoutofboundsexception (EndIndex);} int Sublen = Endindex-beginindex; if (Sublen < 0) {throw new stringindexoutofboundsexception (Sublen); } return ((beginindex = 0) && (EndIndex = value.length))? this: new String (value, Beginindex, Sublen); } 

The substring method is chosen as a representation, and the other common methods involved in string manipulation are similar, if the contents of your operation are inconsistent with the contents of the current string, then you re-create a new string class return that will not allow you to modify the internal content.

The design of the string class to the final class avoids its method quilt rewrite, which destroys the implementation of its own method, and thus destroys the immutable characteristics.

2.1 String class designed to be an immutable benefit

We are not the Java language designers, do not know why it must be designed to be immutable, try to make some guesses.

1. Multiple variables can be implemented to reference the same string instance in the JVM memory. See the following string pool introduction.
2. Security, the use of string class is too wide, if you can modify it, is not very scary.
3. Performance, string is heavily used in hash processing, because of the immutability of the string, you can only calculate the hash once, and then cached internally, the subsequent direct fetch is good. If the string class is mutable, a large amount of recalculation of the hash value is required at the time of the hashing process.

This is a combination of personal understanding and StackOverflow, and we look at what the Java language dad James Gosling said.

From a strategic point of view, they tend to more often is trouble free. And there is usually things you can does with immutables so can ' t do with mutable things, such as cache the result. If you pass a string to a file open method, or if you pass a string to a constructor for a label in a user interface, in s ome APIs (like in lots of the Windows APIs) your pass in an array of characters. The receiver of that object really have to copy it, because they don ' t know anything about the storage lifetime of it. And they don ' t know what's happening to the object, whether it's being changed under their feet.

You end up getting almost forced to replicate the object because you don't know whether or not your get to own it. And one of the nice things about immutable objects are that the answer are, "Yeah, of course you do." Because the question of ownership, who had the right-to-change it, doesn ' t exist.

One of the things that forced Strings to is immutable was security. You have a file open method. You pass a String to it. And then it's doing all kind of authentication checks before it gets around to doing the OS call. If you manage to does something that effectively mutated the String, after the security check and before the OS call, then B Oom, you're ' re in. But Strings is immutable, so this kind of attack doesn ' t work. That's precise example is the what really demanded the Strings be immutable.

This is James Gosling in an interview in May 2001, talking about immutable classes and strings, to the effect that he will be more inclined to use immutable classes, it can cache the results, when you are in the argument, the use of immutable classes do not need to consider who may modify their internal values, this problem does not exist. If you use a variable class, you may need to remember to re-copy the value inside each time, performance will be a certain loss.

The Don also said that another reason to force the string class to be immutable is security, and when you invoke other methods, such as calling some system-level operations, there may be a series of checks that, in the case of mutable classes, may have changed their internal values after you verify, possibly causing a serious system crash. This is an important reason for forcing the string class to be designed as an immutable class.

2.2 String Pool

As stated above, when the design is immutable, multiple variables can be used to refer to the same address on the JVM, which saves memory space, and the same string does not have to occupy the heap area space again.

test1 = "abc";String test2 = "abc";

Usually we use strings, which are used in this way, so the approximate storage in the JVM is as shown.

?

Two variables also refer to the ABC in the string pool, and if the string class is mutable, there is no such design as String pool. In peacetime we will also use the New keyword to generate a string, then whether the newly created string will also be the same as the example above to share the same string address.

        String test1 = "abc";        String test2 = "abc";        String test3 = new String("abc");

The answer is no, using the New keyword creates a string in the heap area, so using new to create a string is a waste of memory, as shown in the memory structure.

?

2.3 It is not recommended to use + to assemble strings.

First of all, let's look at this piece of code, which should be more common before writing code.

test1 = "abc";String test2 = "abc";String test3 = test1 + test2;

Test3 is stitched together by test1 and Test2, we look at the bytecode in this process.

?

From what we can see, the current JDK7 approach is to complete the operation of this + number by creating a new StringBuilder method. This is the current implementation of a low-level bytecode, then it is not necessary to use StringBuilder or StringBuffer. There are still some, see the next example.

test2 = "abc";String test3 = "abc";for (int i = 0; i < 5; i++) { test3 += test2;}

In the above code, we still use the + number for stitching, but this time we added a loop to see what the bytecode changes.

Each loop creates a StringBuilder, and at the end calls the ToString back to return it with low efficiency. Continue to the next example, we use StringBuilder directly, to do stitching.

test2 = "abc";// 使用StringBuilder进行拼接StringBuilder test4 = new StringBuilder("abc");for (int i = 0; i < 5; i++) { test4.append(test2);}

?

The Append method of the previously created StringBuilder is only called in each loop body, and the efficiency is greatly improved.

As for the internal implementation of StringBuilder, you are interested to look at it yourself, is essentially a char array of operations, and stringbuffer the difference is that StringBuffer is doing synchronous processing, and StringBuilder not.

3. Summary

This paper mainly discusses the reasons why the string class is designed for final and immutable classes, and why it is not recommended to use the + sign for string concatenation in daily work.

Parsing the immutable nature of the Java core class string from the point of view of bytecode and JVM