Shulou(Shulou.com)06/03 Report--

This article mainly introduces "whether the ThreadLocalRandom in the code is safe". In the daily operation, I believe that many people have doubts about the security of the ThreadLocalRandom in the code. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful for you to answer the doubt of "whether the ThreadLocalRandom in the code is safe or not." Next, please follow the editor to study!

Performance problems of Random

When using the Random class, in order to avoid the overhead of repeated creation, we generally set the instantiated Random object to the property or static property of the service object we use, which is not a problem when the thread competition is not fierce, but in a highly concurrent web service, using the same Random object may cause thread blocking.

Random's random principle is to perform fixed arithmetic and bit operations on a "random seed" to get a random result, and then use this result as the next random seed. When solving thread safety issues, Random uses CAS to update the next random seed, and it is conceivable that if multiple threads use this object at the same time, some threads will surely fail to execute CAS successively, resulting in thread blocking.

ThreadLocalRandom

The developers of jdk naturally considered this problem and added the ThreadLocalRandom class to the concurrent package. When I saw the class name for the first time, I thought it was implemented through ThreadLocal, and then thought of the horrible memory leak problem, but there was no shadow of ThreadLocal in the input source code, but there was a lot of Unsafe-related code.

Let's take a look at its core code:

UNSAFE.putLong (t = Thread.currentThread (), SEED, r = UNSAFE.getLong (t, SEED) + GAMMA)

Translating into more intuitive Java code is like:

Thread t = Thread.currentThread (); long r = UNSAFE.getLong (t, SEED) + GAMMA; UNSAFE.putLong (t, SEED, r)

It looks very familiar, just like we usually get/set in Map, using the key in the current object obtained by Thread.currentThread () and the random seed of SEED as value.

However, using objects as key may cause memory leaks. Because a large number of Thread objects may be created, if the value in the remove Map is not recycled, the Map will become larger and larger, and the memory will eventually overflow.

Unsafe

Function

However, if we take a closer look at the core code of the ThreadLocalRandom class, we can find that it is not a simple Map operation. Its getLong () method needs to pass in two parameters, while the putLong () method needs three parameters. Looking at the source code, we find that they are all native methods, and we cannot see the specific implementation. The two method signatures are:

Public native long getLong (Object var1, long var2); public native void putLong (Object var1, long var2, long var4)

Although we can't see the specific implementation, we can find out their functions. Here are the functional descriptions of the two methods:

PutLong (object, offset, value) can set the next four bytes of the object object memory address offset from offset to value.

GetLong (object, offset) reads four bytes from the location where the memory address of the object object is offset from offset as a long type.

Unsafe

As a method within the Unsafe class, it also reveals a breath of "Unsafe". The concrete manifestation is that it can directly manipulate memory without doing any security check. if there is a problem, it will throw a Fatal Error at run time, resulting in the exit of the entire virtual machine.

In our common sense, the get method is the easiest place to throw exceptions, such as null pointers, type conversions, etc., but the Unsafe.getLong () method is a very safe way to read four bytes from a certain memory location, and no matter what those four bytes are, it can always be successfully converted to long, but whether the long result matches the business is another matter. The set method is also relatively safe. It overwrites the four bytes after a memory location into a long-type value, and it is almost error-free.

So where are these two methods "unsafe"?

Their insecurity is not that errors are reported during the execution of these two methods, but that unprotected changes in memory can cause other methods to make errors in using this section of memory.

Public static void main (String [] args) throws NoSuchFieldException, IllegalAccessException {/ / Unsafe set constructor private, getUnsafe gets instance method package private, and Field field = Unsafe.class.getDeclaredField ("theUnsafe"); field.setAccessible (true); Unsafe unsafe = (Unsafe) field.get (null) outside the package / / the Test class is a handwritten test class with only one test class of type String Test test = new Test (); test.ttt = "12345"; unsafe.putLong (test, 12L, 2333L); System.out.println (test.value);}

Run the above code and you will get a fatal error with the error message "A fatal error has been detected by the Java Runtime Environment:... Process finished with exit code 134( interrupted by signal 6: SIGABRT)".

You can see from the error message that the virtual machine exited because of this fatal error abort, and the reason is very simple. I used unsafe to set the location of the value property of the Test class to a long value of 2333. When I used the value property, the virtual machine parsed this piece of memory into a String object, the structure of the original String object object header was disturbed, and an error was thrown when parsing the object failed. A more serious problem is that there is no information such as class name and line number in the error message. Troubleshooting such problems in complex projects is like looking for a needle in a haystack.

However, Unsafe's other methods are not necessarily like this pair, and you may need to pay attention to other security issues when using them.

The realization of ThreadLocalRandom

So is ThreadLocalRandom secure? let's go back and take a look at its implementation.

The implementation of ThreadLocalRandom requires the cooperation of the Thread object. There is a property threadLocalRandomSeed in the Thread object, which holds the random seed specific to this thread, and this property is determined in the offset of the Thread object when the ThreadLocalRandom class is loaded, the specific method is SEED = UNSAFE.objectFieldOffset (Thread.class.getDeclaredField ("threadLocalRandomSeed")).

We know that the amount of memory occupied by an object is determined after the class is loaded, so using Unsafe.objectFieldOffset (class, fieldName) can get the offset of a property in the class, and when finding the offset and determining the data type, it is safe to use ThreadLocalRandom.

Doubt

In the process of finding these problems, I also had two question points.

Working with scen

First of all, why does ThreadLocalRandom have to use Unsafe to modify the random seeds in the Thread object? wouldn't it be more convenient to add the get/set method to the Thread object?

Someone on stackOverFlow who asked the same question as me, why is threadlocalrandom implemented so bizarrely, explained in the adopted answer that both Unsafe and get/set methods are like ordinary tools for jdk developers, and there are no guidelines for which to use.

This answer did not convince me, so I opened another question, in which I agree with a comment, the main idea is that ThreadLocalRandom and Thread are not in the same package, if you add the get/set method, the get/set method must be set to public, which violates the closure principle of the class.

Memory layout

Another doubt is that after I saw that Unsafe.objectFieldOffset can get the offset of the attribute in the object memory, I used the main method in IDEA to try the Test class mentioned above, and found that the only property of the Test class, value, relative to the object memory offset is 12, so I am more confused about the composition of these 12 bytes.

We know that the object header of the Java object is placed at the beginning of the memory of the Java object, while the MarkWord of an object is at the beginning of the object header, which takes up 4 bytes in a 32-bit system and 8 bytes in a 64-bit system. I use a 64-bit system, which undoubtedly takes up an offset of 8 bytes.

MarkWord should be followed by the Test class pointer and the length of the array object, the array length is 4 bytes, but the Test class is not an array, there are no other attributes, data length can be excluded, but in a 64-bit system, the pointer should also be 8 bytes, why only occupy 4 bytes?

The only possibility is that the virtual machine has pointer compression enabled, pointer compression can only be enabled on 64-bit systems, and the pointer type only takes 4 bytes when enabled, but I do not show that pointer compression has been specified. It turns out that pointer compression is on by default after 1.8. after using the-XX:-UseCompressedOops parameter when enabled, the offset of value becomes 16.

At this point, the study on "whether the ThreadLocalRandom in the code is safe or not" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.