• JAVA里的CAS算法简析


    Atomic 从JDK5开始, java.util.concurrent包里提供了很多面向并发编程的类. 使用这些类在多核CPU的机器上会有比较好的性能.
    主要原因是这些类里面大多使用(失败-重试方式的)乐观锁而不是synchronized方式的悲观锁.

    跟踪了一下AtomicInteger的incrementAndGet的实现。仅做个笔记, 方便以后再深入研究。

    1. incrementAndGet的实现

        public final int incrementAndGet() {
            for (;;) {
                int current = get();
                int next = current + 1;
                if (compareAndSet(current, next))
                    return next;
            }
        }

    首先可以看到他是通过一个无限循环(spin)直到increment成功为止.  

    循环的内容是

    1.取得当前值

    2.计算+1后的值

    3.如果当前值还有效(没有被)的话设置那个+1后的值

    4.如果设置没成功(当前值已经无效了即被别的线程改过了), 再从1开始.


    2. compareAndSet的实现

        public final boolean compareAndSet(int expect, int update) {
            return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
        }

    直接调用的是UnSafe这个类的compareAndSwapInt方法

    全称是sun.misc.Unsafe. 这个类是Oracle(Sun)提供的实现. 可以在别的公司的JDK里就不是这个类了


    3. compareAndSwapInt的实现

        /**
         * Atomically update Java variable to <tt>x</tt> if it is currently
         * holding <tt>expected</tt>.
         * @return <tt>true</tt> if successful
         */
        public final native boolean compareAndSwapInt(Object o, long offset,
                                                      int expected,
                                                      int x);

    可以看到, 不是用Java实现的, 而是通过JNI调用操作系统的原生程序.


    4. compareAndSwapInt的native实现

    如果你下载了OpenJDK的源代码的话在hotspotsrcsharevmprims目录下可以找到unsafe.cpp

    UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapInt(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jint e, jint x))
      UnsafeWrapper("Unsafe_CompareAndSwapInt");
      oop p = JNIHandles::resolve(obj);
      jint* addr = (jint *) index_oop_from_field_offset_long(p, offset);
      return (jint)(Atomic::cmpxchg(x, addr, e)) == e;
    UNSAFE_END

    可以看到实际上调用Atomic类的cmpxchg方法.


    5. Atomic的cmpxchg
    这个类的实现是跟操作系统有关, 跟CPU架构也有关, 如果是windows下x86的架构
    实现在hotspotsrcos_cpuwindows_x86vm目录的atomic_windows_x86.inline.hpp文件里

    inline jint     Atomic::cmpxchg    (jint     exchange_value, volatile jint*     dest, jint     compare_value) {
      // alternative for InterlockedCompareExchange
      int mp = os::is_MP();
      __asm {
        mov edx, dest
        mov ecx, exchange_value
        mov eax, compare_value
        LOCK_IF_MP(mp)
        cmpxchg dword ptr [edx], ecx
      }
    }

    在这里可以看到是用嵌入的汇编实现的, 关键CPU指令是 cmpxchg

    到这里没法再往下找代码了. 也就是说CAS的原子性实际上是CPU实现的. 其实在这一点上还是有排他锁的. 只是比起用synchronized, 这里的排他时间要短的多. 所以在多线程情况下性能会比较好.

    代码里有个alternative for InterlockedCompareExchange

    这个InterlockedCompareExchange是WINAPI里的一个函数, 做的事情和上面这段汇编是一样的

    http://msdn.microsoft.com/en-us/library/windows/desktop/ms683560%28v=vs.85%29.aspx


    6. 最后再贴一下x86的cmpxchg指定

    Opcode CMPXCHG


    CPU: I486+ 
    Type of Instruction: User 

    Instruction: CMPXCHG dest, src 

    Description: Compares the accumulator with dest. If equal the "dest" 
    is loaded with "src", otherwise the accumulator is loaded 
    with "dest". 

    Flags Affected: AF, CF, OF, PF, SF, ZF 

    CPU mode: RM,PM,VM,SMM 
    +++++++++++++++++++++++ 
    Clocks: 
    CMPXCHG reg, reg 6 
    CMPXCHG mem, reg 7 (10 if compartion fails) 

    源地址:http://www.blogjava.net/mstar/archive/2013/04/24/398351.html

    在这个国度中,必须不停地奔跑,才能使你保持在原地。如果想要寻求突破,就要以两倍现在速度奔跑!
  • 相关阅读:
    rabbitMQ rabbitmq-server -detached rabbitmq-server -detached rabbitmq-server -detached
    ElasticSearch 深度分页解决方案 {"index":{"number_of_replicas":0}}
    git 服务器新建仓库 远程仓库
    mongo 记得开启验证 auth = true
    虚拟机创建及安装ELK
    JSF action actionListner 详解
    Developing JSF applications with Spring Boot
    从问题看本质: 研究TCP close_wait的内幕
    linux server 产生大量 Too many open files CLOSE_WAIT激增
    wildfly tomcat 服务器不响应 不返回 死住了 查看tcp CLOSE_WAIT 暴多
  • 原文地址:https://www.cnblogs.com/manong--/p/8486092.html
Copyright © 2020-2023  润新知