Summary of some practical “tips” in JDK source code

preface

This period of time is relatively idle, I started to look at the JDK source code. Generally, a senior development engineer who can read some source code will greatly improve himself. This article summarizes some "tips" in the JDK source code and shares them for your reference and learning. I won't say much below. Let's take a look at the detailed introduction together.

1 i++ vs i--

Line 985 of the string source code, in the equals method

This code is used to judge whether the strings are equal, but there is a strange place that I --= 0 to judge, don't we usually use I + +? Why use I -? And the number of cycles is the same. The reason is that there will be one more instruction after compilation:

I -- the operation itself will affect CPSR (current program status register). The common flags of CPSR are n (negative result), Z (0 result), C (carry), O (overflow). If I > 0, it can be determined directly through the Z flag.

I + + operation will also affect CPSR (current program status register), but only affect the O (overflow) flag, which is not helpful for the judgment of I < n. therefore, an additional comparison instruction is required, that is, one more instruction should be executed for each loop.

In short, there will be one less instruction compared with 0. Therefore, the recycling i--, high-end atmosphere on the grade.

2 member variable vs local variable

JDK source code almost always uses a local variable to accept member variables in any method, such as

Since local variables are initialized in the method thread stack and member variables are initialized in heap memory, it is obvious that the former is faster. Therefore, we try to avoid using member variables directly in the method, but use local variables.

3 deliberately load into the register & & put the time-consuming operation outside the lock

In concurrenthashmap, the operation of lock segment is very interesting. It is not a direct lock, but is similar to spin lock. It repeatedly tries to obtain the lock, and will traverse the linked list in the process of obtaining the lock, so as to load the data into the register cache first, so as to avoid convenience in the process of locking. At the same time, the operation of generating new objects is also done outside the lock, Avoid time-consuming operations in locks

Scanandlockforput() source code

4. If the objects are equal, it can be used first==

When judging whether objects are equal, you can first use = =, because = = directly compares addresses, which is very fast, and equals will compare the most object values, which is relatively slow. Therefore, if possible, you can use a = = B | A. equals (b) to compare whether objects are equal

5 about transient

Transient is used to prevent serialization, but the internal array in the HashMap source code is defined as transient

The key value pairs inside can't be serialized. Isn't it impossible to transmit with HashMap in the network? In fact, it's not.

Effective Java 2nd, item75, Joshua mentioned:

How do you understand? Take a look at HashMap Get() / put() knows that the map is read and written according to object Hashcode () to determine which bucket to read / write from And object Hashcode () is a native method, which may be different in different JVMs

For example, save an entry to the HashMap. The key is the string "string". In the first Java program, the hashcode () of "string" is 1 and stored in bucket 1; In the second Java program, the hashcode () of "string" may be 2 and stored in bucket 2 If the default serialization is used (entry [] table does not use transient), the memory distribution of this HashMap will be the same after importing the second Java program from the first Java program through serialization, which is wrong

For example, if you save a key value pair entry in HashMap, key = "Mr. Fang", and the hashcode () of "Mr. Fang" is 1 and stored in table [1], well, now transfer it to another JVM program. The hashcode () of "Mr. Fang" may be 2, so go to table [2] to get the result value. The result value does not exist.

The readObject and writeobject of HashMap now output / input the content and regenerate the HashMap

6 do not use char

Char is encoded in utf-16 in Java. It is 2 bytes, and 2 bytes cannot represent all characters. The character represented by 2 bytes is called BMP, and the other character represented by 4 bytes is spliced as high surrogate and low surrogate. For example, indexof in string source code:

Therefore, Java char can only represent BMP characters in utf16. For CJK (CJK unified ideograph), some extended character sets cannot be represented.

For example, in the following figure, char cannot be represented except ext-a.

In addition, another saying is to use char instead of string for password, String is a constant (that is, it cannot be changed after creation) and will be saved to the constant pool. If other processes can dump the memory of this process, the password will be dumped along with the constant pool, and char [] can be changed by writing other information. Even if it is dumped, the risk of password disclosure will be reduced.

But I think you can dump memory. Can a char prevent it? Unless a string is not recycled in the constant pool and read directly from the constant pool by other threads, it is probably very rare.

summary

The above is the whole content of this article. I hope the content of this article has a certain reference value for your study or work. If you have any questions, you can leave a message. Thank you for your support for programming tips.