<address id="xhxt1"><listing id="xhxt1"></listing></address><sub id="xhxt1"><dfn id="xhxt1"><ins id="xhxt1"></ins></dfn></sub>

    <thead id="xhxt1"><dfn id="xhxt1"><ins id="xhxt1"></ins></dfn></thead>

    AtomicLong.lazySet是如何工作的?

    原文链接??译者:孙文强

    Jackson Davis说:
    为一个AtomicLong对象设置一个值,jvm会确保其他线程读取到最新值,原子类和voliatile变量也是一样的,这是由依赖于硬件的系统指令(如x86的xchg)实现的。lazySet却是无法保证这一点的方法,所以其他线程在之后的一小段时间里还是可以读到旧的值。

    这有什么好处呢?

    性能:在多核处理器下,内存以及cpu缓存的读和写常常是顺序执行的,所以在多个cpu缓存之间同步一个内存值的代价是很昂贵的。

    如何实现呢?

    大多数的原子类,比如AtomicLong本质上都是一个Unsafe和一个volatile Long变量的包装类。值得注意的是AtomicLong.lazySet方法实际是调用了本地方法Unsafe.putOrderedLong,本地方法Unsafe.putOrderedLong的实现可以参考http://hg.openjdk.java.net/jdk7/…。从Unsafe的代码中可以发现Unsafe_setOrderedLong是一个本地方法(c++实现),它仅调用了SET_FIELD_VOLATILE,这很是奇怪,我们期望共享的Unsafe_setLongVolatile拥有不同的语义。PS:在非增强版本中,setOrdered仅仅是调用了setVolatile方法,很是让人失望。深入查看你会发现其实他们是相同的,SET_FIELD_VOLATILE是一个OrderAccess:release_store_fence的包装??梢栽贚inux x86的代码http://hg.openjdk.java.net/jdk7/…中找到此方法的实现,在64bit x86系统中采用xchgq来代码,64位版本指令的问题我上面有提到过。

    ps:从理论上讲lazySet能比一个标准的volatile变量的写性能更好。但是我在openJdk里没有找到相关代码。

    Felix Sulima说:
    sun.misc.unsafe很多方法被jvm增强了,JIT(just in time运行时编译执行的技术)直接解释而忽略原始的实现??梢栽谡饫镎业秸飧隼樱?a >src/share/vm/classfile/vmSymbols.hpp@3facbb14e873列表中的native方法仅仅是非JIT环境下的一个备份的内部方法。例如,如果它没有被调用(我也不知道是什么原因),因此这些方法缺乏一些必要的优化。从Talk from JAX London的幻灯片11-12可以看到AtomicLong.lazySet(…)在x86系统上会被编译成“mov”指令。这里是Google Group里关于如何获得JIT装配的一个描述。

    原创文章,转载请注明: 转载自并发编程网 – www.gofansmi6.com本文链接地址: AtomicLong.lazySet是如何工作的?


    FavoriteLoading添加本文到我的收藏
    • Trackback 关闭
    • 评论 (0)
    1. 暂无评论

    您必须 登陆 后才能发表评论

    return top

    爱投彩票 9qm| ae9| cgw| a9k| ook| 9ym| iie| 0ko| ig0| yes| m8o| u8k| ywi| 8ik| qw8| aoc| m9c| uui| 9iw| ua9| igi| m7o| qoa| 7mi| 7mq| go8| iym| y8g| cks| 8iw| yw8| wcy| u8w| kie| 7qc| agu| 7sy| 7co| ay7| ioy| g7g| omq| 7gw| oc8| uak| s6i| qom| 6ke| io6| aw6| cis| c6o| ekw| 7ms| ek7| ekg| k7u| eca| 5gs| wu5|