Sun. misc. Unsafe opens the door to Java for you. You can use it to do a lot of things that Java does not allow. It is very useful in some very special scenarios. 99% of the time, you should avoid using it, but in some rare cases, only it can solve the problem. This article describes the use cases of OpenHFT and the features I want to see in Java 9. Unsafe is especially suitable if you want to access a large amount of memory without affecting GC. There is only one way in Java to share memory between processes without causing significant overhead.
Allocate and release heap memory
public native long allocateMemory();public native void freeMemory(long address);
You can use these two methods to allocate heap memory of any size. It is not limited by the size of Integer. MAX_VALUE bytes. The original memory is returned to you. You can perform a boundary check if necessary. For example, Bytes. writeUTF (String) calculates the length of the encoded String and checks whether the entire String is contained. Of course, only one check is performed, and not every byte is checked. Java. lang also has a similar Cleaner class, which is used by DirectByteBuffer to ensure that the memory has been released. However, this class should not be placed in such a core place.
Access original memory
public native Xxx getXxx(Object, long offset); // intrinsicpublic native void putXxx(Object, long offset);// intrinsic
In these two methods, when accessing off-heap memory, the Object is empty, and the offset is the actual address. On the JVM that treats them as internal functions, you can use only one machine command to access the original memory. This greatly improves the memory access efficiency. The problem with this access method is that you have to maintain the distribution of each field in your data structure. The solution in the java. lang library is that it allows you to define the getter and setter methods, and then it generates specific implementations at runtime. That is to say, whether the objects are in or out of the heap, you can directly access them through getter and setter.
Threads securely access memory
public native Xxx getVolatileXxx(Object, long offset); // intrinsicpublic native void putOrderedXxx(Object, long offset); // intrinsic
With these two sets of methods, you can simulate a field into a volatile type through a set of lazy loads. The thread uses this set to set the value speed faster, but if the thread reads the value quickly, it may read the old value. The solution is not to read the written value. These two methods are particularly useful when the memory is shared in the process.
CAS operation
public native boolean compareAndSwapXxxx(Object, long offset, Xxx expected, Xxx setTo)
This method is indispensable for creating an off-heap lock. It is also the most efficient way to securely share data between processes. From my tests on the Haswell processor i7-4500, the round-trip communication latency between two processes on the same machine is quite good;
| TCP |
-9 micro-seconds. |
| FileLocks |
-5.5 micro-seconds. |
| CAS |
-0.12 micro-seconds. |
| Ordered write |
-0.02 micro-seconds. |
Heap object allocation
public native Object allocateInstance(Class clazz);
When the class anti-sequence is used, you certainly want the values in the class to be restored as before the sequence. However, in the current constructor method, this may be a small problem, which has been mentioned in JEP 187: Serialization 2.0. One solution is to create a new object without using the constructor. This shows that you have to fully trust the correctness of your data. The advantage is that it is easy to use and does not need to worry about which constructor is used to instantiate the object.
ConclusionBecause embedded databases have no additional network overhead, they are far better than distributed databases in terms of request latency. I believe that the next generation of Low-latency databases can not only achieve the performance of embedded databases, but also share data between processes. At the same time, it can update and query the response time within milliseconds.
Java has no reason not to implement it. For Java users, the performance of the local interface is the best, because it does not require JNI, or a layer conversion between Java and C.
Note: The article assumes that the reader has a certain understanding and understanding of Unsafe. For more details, refer to the subsequent articles in deepinmind or this blog.
For Original article reprinted, please indicate the source: deepinmind
