How and Why Unsafe is Used in Java---reference

By Peter Lawrey

https://www.voxxed.com/blog/2014/12/how-and-why-unsafe-is-used-in-java/

Overview

sun.misc.Unsafe has been in Java from at least as far back as Java 1.4 (2004).  In Java 9, Unsafe will be hidden along with many other, for-internal-use classes. to improve the maintainability of the JVM.  While it is still unclear exactly what will replace Unsafe, and I suspect it will be more than one thing which replaces it, it raises the question, why is it used at all?

Doing things which the Java language doesn’t allow but are still useful.

Java doesn’t allow many of the tricks which are available to lower level languages.  For most developers this is very good thing, and it not only saves you from yourself, it also saves you from your co-workers.  It also makes it easier to import open source code because you know there is limits to how much damage they can do.  Or at least there is limits to how much you can do accidentally. If you try hard enough you can still do damage.

But why would you even try, you might wonder?  When building libraries many (but not all) of the methods in Unsafe are useful and in some cases, there is no other way to do the same thing without using JNI, which is even more dangerous and you lose the “compile once, run anywhere”

Deserialization of objects

When deserializing or building an object using a framework, you make the assumption you want to reconstitute an object which existed before.  You expect that you will use reflection to either call the setters of the class, or more likely set the internal fields directly, even the final fields.  The problem is you want to create an instance of an object, but you don’t really need a constructor as this is likely to only make things more difficult and have side effects.


1

2

3

4

5

6

7

8

9

10

11

public class A implements Serializable {

    private final int num;

    public A(int num) {

        System.out.println("Hello Mum");

        this.num = num;

    }

    public int getNum() {

        return num;

    }

}

In this class, you should be able to rebuild and set the final field, but if you have to call a constructor and it might do things which don’t have anything to do with deserialization.  For these reasons many libraries use Unsafe to create instances without calling a constructor


1

2

3

Unsafe unsafe = getUnsafe();

Class aClass = A.class;

A a = (A) unsafe.allocateInstance(aClass);

Calling allocateInstance avoids the need to call the appropriate constructor, when we don’t need one.

Thread safe access to direct memory

Another use for Unsafe is thread safe access to off heap memory.  ByteBuffer gives you safe access to off heap or direct memory, however it doesn’t have any thread safe operations.  This is particularly useful if you want to share data between processes.


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

import sun.misc.Unsafe;

import sun.nio.ch.DirectBuffer;

import java.io.File;

import java.io.IOException;

import java.io.RandomAccessFile;

import java.lang.reflect.Field;

import java.nio.MappedByteBuffer;

import java.nio.channels.FileChannel;

public class PingPongMapMain {

    public static void main(String... args) throws IOException {

        boolean odd;

        switch (args.length < 1 ? "usage" : args[0].toLowerCase()) {

            case "odd":

                odd = true;

                break;

            case "even":

                odd = false;

                break;

            default:

                System.err.println("Usage: java PingPongMain [odd|even]");

                return;        }

        int runs = 10000000;

        long start = 0;

        System.out.println("Waiting for the other odd/even");

        File counters = new File(System.getProperty("java.io.tmpdir"), "counters.deleteme");        counters.deleteOnExit();

        try (FileChannel fc = new RandomAccessFile(counters, "rw").getChannel()) {

            MappedByteBuffer mbb = fc.map(FileChannel.MapMode.READ_WRITE, 0, 1024);

            long address = ((DirectBuffer) mbb).address();

            for (int i = -1; i < runs; i++) {

                for (; ; ) {

                    long value = UNSAFE.getLongVolatile(null, address);

                    boolean isOdd = (value & 1) != 0;

                    if (isOdd != odd)

                        // wait for the other side.

                        continue;

                    // make the change atomic, just in case there is more than one odd/even process

                    if (UNSAFE.compareAndSwapLong(null, address, value, value + 1))

                        break;

                }

                if (i == 0) {

                    System.out.println("Started");

                    start = System.nanoTime();

                }

            }

        }

        System.out.printf("... Finished, average ping/pong took %,d ns%n",

                (System.nanoTime() - start) / runs);

    }

    static final Unsafe UNSAFE;

    static {

        try {

            Field theUnsafe = Unsafe.class.getDeclaredField("theUnsafe");

            theUnsafe.setAccessible(true);

            UNSAFE = (Unsafe) theUnsafe.get(null);

        } catch (Exception e) {

            throw new AssertionError(e);

        }

    }

}

When you run this in two programs, one with odd and the other with even. You can see that each process is changing data via  persisted shared memory.

In each program it maps the same are of the disks cache into the process.  There is actually only one copy of the file in memory.  This means the memory can be shared, provided you use thread safe operations such as the volatile and CAS operations.

The output on an i7-3970X is

Waiting for the other odd/even
Started
… Finished, average ping/pong took 83 ns

That is 83 ns round trip time between two processes. When you consider System V IPC takes around 2,500 ns and IPC volatile instead of persisted, that is pretty quick.

Is using Unsafe suitable for work?

I wouldn’t recommend you use Unsafe directly.  It requires far more testing than natural Java development.  For this reason I suggest you use a library where it’s usage has been tested already.  If you wan to use Unsafe yourself, I suggest you thoughly test it’s usage in a stand alone library.  This limits how Unsafe is used in your application and give syou a safer, Unsafe.

Conclusion

It is interesting that Unsafe exists in Java, and you might to play with it at home.  It has some work applications especially in writing low level libraries, but in general it is better to use a library which uses Unsafe which has been tested than use it directly yourself.

时间: 12-21

How and Why Unsafe is Used in Java---reference的相关文章

Java Reference &amp; ReferenceQueue一览

Overview The java.lang.ref package provides more flexible types of references than are otherwise available, permitting limited interaction between the application and the Java Virtual Machine (JVM) garbage collector. It is an important package, centr

理解java reference

Java世界泰山北斗级大作<Thinking In Java>切入Java就提出“Everything is Object”.在Java这个充满Object的世界中,reference是一切谜题的根源,所有的故事都是从这里开始的. Reference是什么? 如果你和我一样在进入Java世界之前曾经浪迹于C/C++世界,就一定不会对指针陌生.谈到指针,往日种种不堪回首的经历一下子涌上心头,这里不是抱怨的地方,让我们暂时忘记指针的痛苦,回忆一下最初接触指针的甜蜜吧!还记得你看过的教科书中,如何讲

Java Reference Types

References Java provides two different types/classes of Reference Objects: strong and weak. Weak Reference Objects can be further divided into soft and phantom. Strong Reference StringBuilder builder = new StringBuilder(); This is the default type/cl

java reference(转)

http://blog.163.com/[email protected]/blog/static/112987702200962211145825/ 在Java中的引用类型,是指除了基本的变量类型之外的所有类型,所有的类型在内存中都会分配一定的存储空间(形参在使用的时候也会分配存储空间,方法调用完成之后,这块存储空间自动消失), 基本的变量类型只有一块存储空间(分配在stack中), 而引用类型有两块存储空间(一块在stack中,一块在heap中), 方法形参的值传递(引用)是指形参和传进来的

Java Reference 源码分析

Reference对象封装了其它对象的引用,可以和普通的对象一样操作,在一定的限制条件下,支持和垃圾收集器的交互.即可以使用Reference对象来引用其它对象,但是最后还是会被垃圾收集器回收.程序有时候也需要在对象回收后被通知,以告知对象的可达性发生变更.  Java提供了四种不同类型的引用,引用级别从高到低分别为FinalReference,SoftReference,WeakReference,PhantomReference.其中FinalReference不对外提供使用.每种类型对应着

What Influences Method Call Performance in Java?--reference

reference from:https://www.voxxed.com/blog/2015/02/too-fast-too-megamorphic-what-influences-method-call-performance-in-java/ Whats this all about then? Let’s start with a short story. I proposed a change on the a Java core libs mailing list to overri

[java] java 中Unsafe类学习

java不能直接访问操作系统底层,而是通过本地方法来访问.Unsafe类提供了硬件级别的原子操作,主要提供了以下功能: 1.通过Unsafe类可以分配内存,可以释放内存: 类中提供的3个本地方法allocateMemory.reallocateMemory.freeMemory分别用于分配内存,扩充内存和释放内存,与C语言中的3个方法对应. 2.可以定位对象某字段的内存位置,也可以修改对象的字段值,即使它是私有的: public native long allocateMemory(long l

Java中的sun.misc.Unsafe包

chronicle项目:https://github.com/peter-lawrey/Java-Chronicle 这个项目是利用mmap机制来实现高效的读写数据,号称每秒写入5到20百万条数据. 作者有个测试,写入1百万条log用时0.234秒,用java自带的logger,用时7.347秒. 在看chronicle的源代码,发现一个牛B的利用Unsafe来直接读写内存,从而提高效率的例子. 详细见这个类:https://github.com/peter-lawrey/Java-Chroni

Java Magic. Part 4: sun.misc.Unsafe

原文地址 译文地址 译者:许巧辉 校对:梁海舰 Java是一门安全的编程语言,防止程序员犯很多愚蠢的错误,它们大部分是基于内存管理的.但是,有一种方式可以有意的执行一些不安全.容易犯错的操作,那就是使用Unsafe类. 本文是sun.misc.Unsafe公共API的简要概述,及其一些有趣的用法. Unsafe 实例 在使用Unsafe之前,我们需要创建Unsafe对象的实例.这并不像Unsafe unsafe = new Unsafe()这么简单,因为Unsafe的构造器是私有的.它也有一个静

Java sun.misc.unsafe类的使用

Java是一个安全的开发工具,它阻止开发人员犯很多低级的错误,而大部份的错误都是基于内存管理方面的.如果你想搞破坏,可以使用Unsafe这个类.这个类是属于sun.*API中的类,并且它不是J2SE中真正的一部份,因此你可能找不到任何的官方文档,更可悲的是,它也没有比较好的代码文档. 1.实例化sun.misc.Unsafe 如果你尝试创建Unsafe类的实例,基于以下两种原因是不被允许的. 1).Unsafe类的构造函数是私有的: 2).虽然它有静态的getUnsafe()方法,但是如果你尝试