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

This article mainly explains "how to use Unsafe class". The content of the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn how to use Unsafe class.

Unsafe Foundation

First of all, let's try to get an instance of Unsafe. If you create an object in the way of new, sorry, the compiler will notify you with an error:

Unsafe () has private access in 'sun.misc.Unsafe'

Looking at the source code of the Unsafe class, we can see that it is modified by final and is not allowed to be inherited, and the constructor is of type private, that is, we are not allowed to call the constructor manually for instantiation. Only in the static static code block, a Unsafe object is initialized as a singleton:

Public final class Unsafe {private static final Unsafe theUnsafe;... Private Unsafe () {}... Static {theUnsafe = new Unsafe ();}}

In the Unsafe class, a static method getUnsafe is provided that looks like you can use it to get an instance of Unsafe:

@ CallerSensitive public static Unsafe getUnsafe () {Class var0 = Reflection.getCallerClass (); if (! VM.isSystemDomainLoader (var0.getClassLoader () {throw new SecurityException ("Unsafe");} else {return theUnsafe;}

But if we call this static method directly, an exception will be thrown:

Exception in thread "main" java.lang.SecurityException: Unsafe at sun.misc.Unsafe.getUnsafe (Unsafe.java:90) at com.cn.test.GetUnsafeTest.main (GetUnsafeTest.java:12)

This is because in the getUnsafe method, the caller's classLoader is checked to determine whether the current class is loaded by Bootstrap classLoader, and if not, a SecurityException exception is thrown. That is, only classes that start the classloader can call methods in the Unsafe class to prevent them from being called in untrusted code.

So, why is it necessary to impose such cautious restrictions on the use of the Unsafe class? in the final analysis, it is because the functions it implements are too low-level, such as performing memory operations directly, bypassing jvm security checks to create objects, and so on. In a nutshell, Unsafe class implementation functions can be divided into the following eight categories:

Create an instance

Seeing the above features, you can't wait to give it a try. So if we insist on calling a method of the Unsafe class in our code, how should we get an instance object of it? the answer is to use reflection to get the singleton object that has been instantiated in the Unsafe class:

Public static Unsafe getUnsafe () throws IllegalAccessException {Field unsafeField = Unsafe.class.getDeclaredField ("theUnsafe"); / / Field unsafeField = Unsafe.class.getDeclaredFields () [0]; / / it works the same as unsafeField.setAccessible (true); Unsafe unsafe = (Unsafe) unsafeField.get (null); return unsafe;}

After getting the instance object of Unsafe, we can use it to do whatever we want, first try to use it to read and write the properties of an object:

Public void fieldTest (Unsafe unsafe) throws NoSuchFieldException {User user=new User (); long fieldOffset = unsafe.objectFieldOffset (User.class.getDeclaredField ("age")); System.out.println ("offset:" + fieldOffset); unsafe.putInt (user,fieldOffset,20); System.out.println ("age:" + unsafe.getInt (user,fieldOffset)); System.out.println ("age:" + user.getAge ());}

The output of the running code is as follows. You can see that the offset address of the field in the object is obtained through the objectFieldOffset method of the Unsafe class. This offset address is not an absolute address in memory but a relative address, and then read and write the attribute value of the int type field through this offset address. Through the results, you can also see that the value obtained by the Unsafe method is the same as that obtained by the get method in the class.

Offset:12 age:20 age:20

In the above example, you called the putInt and getInt methods of the Unsafe class to take a look at the methods in the source code:

Public native int getInt (Object o, long offset); public native void putInt (Object o, long offset, int x)

First of all, getInt is used to read an int,putInt from the specified offset address of the object, to write an int at the specified offset address of the object, and to read and write to it even if the property in the class is of the private private type. But a careful partner may find that these two methods are modified by an native keyword compared to the ordinary methods we usually write, and there is no specific method logic, so how is it implemented?

Native method

In java, this kind of method is called native method (Native Method). To put it simply, java calls the interface of non-java code, and the called method is implemented by non-java language, for example, it can be implemented by C or C++ language, and compiled into DLL, and then directly called by java. The native method is called through the JNI (Java Native Interface) implementation, and the JNI standard has been part of the java platform since java1.1, which allows java code to interact with code in other languages.

Many of the basic methods in the Unsafe class are native methods, so why use the native method? The reasons can be summarized as follows:

It is necessary to use the operating system-dependent features that are not available in java. In order to achieve cross-platform control at the same time, java needs other languages to play a role.

For some off-the-shelf functions that have been done in other languages, you can use java to call the

When a program is time-sensitive or has very high performance requirements, it is necessary to use a lower-level language, such as Cpicard + or even assembly.

When implementing the concurrency mechanism, many concurrent utility classes in the juc package call native methods, which break the boundaries of the java runtime and can get in touch with some functions at the bottom of the operating system. For the same native method, different operating systems may be implemented in different ways, but it is transparent to users and will eventually get the same result. As for how java implements code that calls other languages through JNI, it is not the focus of this article and will be learned in detail in subsequent articles.

Unsafe application

With some understanding of the basics of Unsafe, let's take a look at its basic applications. Due to the limited space, we can not introduce all the methods. If you need to learn, you can download the source code of openJDK to learn.

1. Memory operation

If you are a programmer who has written c or C++, you must be familiar with memory operations, but in java you are not allowed to operate directly on memory. The allocation and collection of object memory are realized by jvm itself. However, in Unsafe, the following interfaces are provided for direct memory operations:

/ / allocate new local space public native long allocateMemory (long bytes); / / resize memory space public native long reallocateMemory (long address, long bytes); / / set memory to the specified value public native void setMemory (Object o, long offset, long bytes, byte value); / / memory copy public native void copyMemory (Object srcBase, long srcOffset,Object destBase, long destOffset,long bytes); / / clear memory public native void freeMemory (long address)

Test with the following code:

Private void memoryTest () {int size = 4; long addr = unsafe.allocateMemory (size); long addr3 = unsafe.reallocateMemory (addr, size * 2); System.out.println ("addr:" + addr); System.out.println ("addr3:" + addr3); try {unsafe.setMemory (null,addr, size, (byte) 1); for (int I = 0; I

< 2; i++) { unsafe.copyMemory(null,addr,null,addr3+size*i,4); } System.out.println(unsafe.getInt(addr)); System.out.println(unsafe.getLong(addr3)); }finally { unsafe.freeMemory(addr); unsafe.freeMemory(addr3); } } 先看结果输出： addr: 2433733895744 addr3: 2433733894944 16843009 72340172838076673 分析一下运行结果，首先使用allocateMemory方法申请4字节长度的内存空间，在循环中调用setMemory方法向每个字节写入内容为byte类型的1，当使用Unsafe调用getInt方法时，因为一个int型变量占4个字节，会一次性读取4个字节，组成一个int的值，对应的十进制结果为16843009，可以通过图示理解这个过程：

Calling the reallocateMemory method in the code reallocates a block of 8-byte memory, and by comparing addr and addr3, you can see that the memory address is different from that requested before. In the second for loop in the code, the copyMemory method is called to copy the memory twice, each time the four bytes starting with the memory address addr are copied to the memory space starting with addr3 and addr3+4:

After the copy is completed, the getLong method is used to read 8 bytes at a time, and the value of type long is 72340172838076673.

It should be noted that the memory allocated in this way belongs to out-of-heap memory and cannot be garbage collected. We need to use this memory as a resource to manually call the freeMemory method to release it, otherwise there will be a memory leak. The common way to operate memory is to perform operations on memory in try, and finally release memory in finally blocks.

2. Memory barrier

Before introducing the memory barrier, it is important to know that the compiler and CPU will reorder the code to improve performance from the perspective of instruction optimization while ensuring that the program output is consistent. Instruction reordering may lead to a bad result, which leads to the inconsistency between CPU cache and memory data, while memory barrier (Memory Barrier) avoids incorrect optimization of compiler and hardware by organizing instruction reordering on both sides of the barrier.

At the hardware level, memory barriers are instructions provided by CPU to prevent code reordering, and different hardware platforms may have different ways to implement memory barriers. In java8, three memory barrier functions are introduced, which shield the differences at the bottom of the operating system and allow the memory barrier instructions to be defined in the code and uniformly generated by jvm to realize the memory barrier function. The following three memory barrier related methods are available in Unsafe:

/ / prohibit read reordering public native void loadFence (); / / prohibit write reordering public native void storeFence (); / / prohibit read and write reordering public native void fullFence ()

The memory barrier can be seen as a synchronization point in the operation of random access to memory, so that all read and write operations before this point can be performed before the operation after this point can be started. The loadFence method, for example, disables read reordering, ensures that all reads before this barrier have been completed, and sets the cached data to invalid and reloads from main memory.

Seeing this, it is estimated that many friends will think of the volatile keyword. If you add the volatile keyword to the field, you can achieve the visibility of the field under multi-threading. Based on the read memory barrier, we can achieve the same function. Let's define a thread method to modify the flag flag bit in the thread. Note that the flag here is not modified by volatile:

@ Getter class ChangeThread implements Runnable {/ * * volatile**/ boolean flag=false; @ Override public void run () {try {Thread.sleep (3000);} catch (InterruptedException e) {e.printStackTrace ();} System.out.println ("subThread change flag to:" + flag); flag= true;}}

In the while loop of the main thread, add a memory barrier to test whether the changes to flag can be sensed:

Public static void main (String [] args) {ChangeThread changeThread = new ChangeThread (); new Thread (changeThread). Start (); while (true) {boolean flag = changeThread.isFlag (); unsafe.loadFence (); / / add read memory barrier if (flag) {System.out.println ("detected flag changed"); break }} System.out.println ("main thread end");}

Running result:

SubThread change flag to:false detected flag changed main thread end

If you delete the loadFence method from the above code, the main thread will not be aware of the change in the flag and will loop through the while all the time. The above process can be represented by a diagram:

Friends who understand the java memory model (JMM) should know that running threads do not directly read variables in main memory, but can only manipulate variables in their own working memory and then synchronize them into main memory, and thread working memory cannot be shared. The flow in the figure above is that the child thread synchronizes the modified result to the main thread with the help of the main memory, and then modifies the workspace in the main thread and jumps out of the loop.

3. Object operation

A, the memory offset acquisition of the object member property, and the modification of the field property value, which we have tested in the above example. In addition to the previous putInt and getInt methods, Unsafe provides all eight basic data types as well as Object's put and get methods, and all put methods can modify data in memory directly beyond access. Read the comments in the openJDK source code and found that the basic data type and Object read and write slightly different, the basic data type is the direct operation of the attribute value (value), while the operation of Object is based on the reference value (reference value). Here is how to read and write Object:

/ / get an object reference public native Object getObject (Object o, long offset) at the specified offset address of the object; / / write an object reference public native void putObject (Object o, long offset, Object x) at the specified offset address of the object

In addition to normal reading and writing of object properties, Unsafe also provides volatile read and write and sequential write methods. The coverage of volatile read and write method is the same as that of normal read and write, including all basic data types and Object types. Take the int type as an example:

/ / read an int value at the specified offset address of the object, support volatile load semantic public native int getIntVolatile (Object o, long offset); / / write an int at the specified offset address of the object, and support volatile store semantic public native void putIntVolatile (Object o, long offset, int x)

Compared to normal reading and writing, volatile reading and writing is more expensive because it needs to ensure visibility and order. When performing a get operation, the property value is forced to be obtained from main memory, and when the property value is set using the put method, the value is forced to be updated to main memory, ensuring that these changes are visible to other threads.

There are three ways to write sequentially:

Public native void putOrderedObject (Object o, long offset, Object x); public native void putOrderedInt (Object o, long offset, int x); public native void putOrderedLong (Object o, long offset, long x)

The cost of orderly writing is lower than that of volatile because it only guarantees order at the time of writing, not visibility, that is, the value written by one thread does not guarantee that other threads are immediately visible. In order to solve the difference here, we need to further supplement the knowledge of the memory barrier, first of all, we need to understand the concepts of two instructions:

Load: copy data from the main memory to the processor's cache

Store: flushes processor cached data to main memory

The difference between sequential writes and volatile writes is that the type of memory barrier added when writing sequentially is StoreStore, while the type of memory barrier added when writing to volatile is StoreLoad, as shown in the following figure:

In the sequential write method, the StoreStore barrier is used, which ensures that Store1 immediately flushes data into memory, which precedes Store2 and subsequent storage instruction operations. In volatile writes, the StoreLoad barrier is used, which ensures that the Store1 immediately flushes data into memory, which precedes the Load2 and subsequent load instructions, and the StoreLoad barrier causes all memory access instructions before the barrier, including storage instructions and access instructions, to be executed.

To sum up, in the above three types of writing methods, in terms of writing efficiency, the efficiency gradually decreases in the order of put, putOrder and putVolatile.

B. Using Unsafe's allocateInstance method allows us to instantiate objects in an unconventional way, first defining an entity class and assigning its member variables in the constructor:

@ Data public class A {private int b; public A () {this.b = 1;}}

Compare different ways to create objects based on constructors, reflections, and Unsafe methods:

Public void objTest () throws Exception {An a1=new A (); System.out.println (a1.getB ()); Aa2 = A.class.newInstance (); System.out.println (a2.getB ()); Aa3 = (A) unsafe.allocateInstance (A.class); System.out.println (a3.getB ());}

The print results are 1, 1, and 0, respectively, indicating that the constructor of the class will not be called during the creation of the object through the allocateInstance method. When you create an object in this way, only the Class object is used, so you can use this method if you want to skip the initialization phase of the object or skip the security check of the constructor. In the above example, if you change the constructor of class A to type private, you will not be able to create an object through the constructor and reflection, but the allocateInstance method is still valid.

4. Array operation

In Unsafe, you can use the arrayBaseOffset method to get the offset address of the first element in the array, and the arrayIndexScale method to get the offset address increment between the elements in the array. Test with the following code:

Private void arrayTest () {String [] array=new String [] {"str1str1str", "str2", "str3"}; int baseOffset = unsafe.arrayBaseOffset (String [] .class); System.out.println (baseOffset); int scale = unsafe.arrayIndexScale (String [] .class); System.out.println (scale); for (int I = 0; I

< array.length; i++) { int offset=baseOffset+scale*i; System.out.println(offset+" : "+unsafe.getObject(array,offset)); } } 上面代码的输出结果为： 16 4 16 : str1str1str 20 : str2 24 : str3 通过配合使用数组偏移首地址和各元素间偏移地址的增量，可以方便的定位到数组中的元素在内存中的位置，进而通过getObject方法直接获取任意位置的数组元素。需要说明的是，arrayIndexScale获取的并不是数组中元素占用的大小，而是地址的增量，按照openJDK中的注释，可以将它翻译为元素寻址的转换因子(scale factor for addressing elements)。在上面的例子中，第一个字符串长度为11字节，但其地址增量仍然为4字节。 那么，基于这两个值是如何实现的寻址和数组元素的访问呢，这里需要借助一点在前面的文章中讲过的Java对象内存布局的知识，先把上面例子中的String数组对象的内存布局画出来，就很方便大家理解了： 在String数组对象中，对象头包含3部分，mark word标记字占用8字节，klass point类型指针占用4字节，数组对象特有的数组长度部分占用4字节，总共占用了16字节。第一个String的引用类型相对于对象的首地址的偏移量是就16，之后每个元素在这个基础上加4，正好对应了我们上面代码中的寻址过程，之后再使用前面说过的getObject方法，通过数组对象可以获得对象在堆中的首地址，再配合对象中变量的偏移量，就能获得每一个变量的引用。 5、CAS操作 在juc包的并发工具类中大量地使用了CAS操作，像在前面介绍synchronized和AQS的文章中也多次提到了CAS，其作为乐观锁在并发工具类中广泛发挥了作用。在Unsafe类中，提供了compareAndSwapObject、compareAndSwapInt、compareAndSwapLong方法来实现的对Object、int、long类型的CAS操作。以compareAndSwapInt方法为例： public final native boolean compareAndSwapInt(Object o, long offset,int expected,int x); 参数中o为需要更新的对象，offset是对象o中整形字段的偏移量，如果这个字段的值与expected相同，则将字段的值设为x这个新值，并且此更新是不可被中断的，也就是一个原子操作。下面是一个使用compareAndSwapInt的例子： private volatile int a; public static void main(String[] args){ CasTest casTest=new CasTest(); new Thread(()->

{for (int I = 1; I)

< 5; i++) { casTest.increment(i); System.out.print(casTest.a+" "); } }).start(); new Thread(()->

{for (int I = 5; I {try {TimeUnit.SECONDS.sleep (5); System.out.println ("subThread try to unpark mainThread"); unsafe.unpark (mainThread);} catch (InterruptedException e) {e.printStackTrace ();}}) .start (); System.out.println ("park main mainThread") Unsafe.park (false,0L); System.out.println ("unpark mainThread success");}

The program output is:

Park main mainThread subThread try to unpark mainThread unpark mainThread success

The process of running the program is also easy to understand. After the child thread starts to run, it sleeps first to ensure that the main thread can call the park method to block itself. After 5 seconds of sleep, the child thread calls the unpark method to wake up the main thread, so that the main thread can continue to execute downward. The whole process is shown in the following figure:

In addition, the three monitor-related methods in the Unsafe source code have been marked as deprecated and are not recommended:

/ / get the object lock @ Deprecated public native void monitorEnter (Object var1); / / release the object lock @ Deprecated public native void monitorExit (Object var1); / / attempt to acquire the object lock @ Deprecated public native boolean tryMonitorEnter (Object var1)

The monitorEnter method is used to obtain the object lock, and monitorExit is used to release the object lock, and if this method is executed on an object that is not locked by monitorEnter, an IllegalMonitorStateException exception is thrown. The tryMonitorEnter method attempts to acquire the object lock and returns true if successful, or false if it succeeds.

7. Class operation

Unsafe's related operations on Class mainly include class loading and static variable operation methods.

A, static attribute reading related methods:

/ / get the offset of the static attribute public native long staticFieldOffset (Field f); / / get the object pointer public native Object staticFieldBase (Field f) of the static attribute; / / determine whether the class needs to be instantiated (used to detect before getting the static attribute of the class) public native boolean shouldBeInitialized (Class c)

Create a class that contains static properties and test it:

Data public class User {public static String name= "Hydra"; int age;} private void staticTest () throws Exception {User user=new User (); System.out.println (unsafe.shouldBeInitialized (User.class)); Field sexField = User.class.getDeclaredField ("name"); long fieldOffset = unsafe.staticFieldOffset (sexField); Object fieldBase = unsafe.staticFieldBase (sexField); Object object = unsafe.getObject (fieldBase, fieldOffset); System.out.println (object);}

Running result:

False Hydra

In the object operation of Unsafe, we learned to obtain the attribute offset of the object through the objectFieldOffset method and access the value of the variable based on it, but it is not suitable for static properties in the class, so we need to use the staticFieldOffset method. In the above code, Class is only relied on when getting the Field object, while getting the properties of static variables is no longer dependent on Class.

In the above code, first create a User object, because if a class is not instantiated, its static property will not be initialized, and the final field property will be null. So before getting the static property, you need to call the shouldBeInitialized method to determine whether the class needs to be initialized before getting it. If you delete the statement that creates the User object, the result of the run will be:

True null

B. using the defineClass method allows the program to create a class dynamically at run time, as defined as follows:

Public native Class defineClass (String name, byte [] b, int off, int len, ClassLoader loader,ProtectionDomain protectionDomain)

In actual use, you can pass in only the byte array, the subscript of the starting byte, and the byte length read. By default, the class loader (ClassLoader) and protection domain (ProtectionDomain) come from the instance that called this method. The decompiled generated class file is implemented in the following example:

Private static void defineTest () {String fileName= "F:\\ workspace\\ unsafe-test\ target\\ classes\\ com\\ cn\\ model\\ User.class"; File file = new File (fileName); try (FileInputStream fis = new FileInputStream (file)) {byte [] content=new byte [(int) file.length ()]; fis.read (content); Class clazz = unsafe.defineClass (null, content, 0, content.length, null, null) Object o = clazz.newInstance (); Object age = clazz.getMethod ("getAge") .invoke (o, null); System.out.println (age);} catch (Exception e) {e.printStackTrace ();}}

In the above code, you first read a class file and convert it to a byte array through the file stream, then create a class dynamically using the defineClass method, and then instantiate it later, as shown in the following figure, and classes created in this way skip all JVM security checks.

In addition to the defineClass method, Unsafe provides a defineAnonymousClass method:

Public native Class defineAnonymousClass (Class hostClass, byte [] data, Object [] cpPatches)

This method can be used to dynamically create an anonymous class. In Lambda expressions, ASM is used to generate bytecode dynamically, and then this method is used to define anonymous classes that implement the corresponding functional interface. In the new features released by jdk15, in the section Hidden classes (Hidden classes), it is indicated that the defineAnonymousClass method of Unsafe will be deprecated in future releases.

8. System information

The addressSize and pageSize methods provided in Unsafe are used to get system information. Calling the addressSize method returns the size of the system pointer, 8 by default on a 64-bit system and 4 on a 32-bit system. Calling the pageSize method returns the size of the memory page, which is an integer power of 2. You can print directly using the following code:

Private void systemTest () {System.out.println (unsafe.addressSize ()) System.out.println (unsafe.pageSize ());}

Execution result:

8 4096

There are few application scenarios for these two methods. In the java.nio.Bits class, when using pageCount to calculate the number of memory pages required, the pageSize method is called to get the memory page size. In addition, when using the copySwapMemory method to copy memory, the addressSize method is called to detect the condition of the 32-bit system.

Thank you for your reading, the above is the content of "how to use the Unsafe class", after the study of this article, I believe you have a deeper understanding of how to use the Unsafe class, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.