Java下CAS(Compare And Swap)并发操作测试

原创 2016年08月30日 16:51:36

测试目的

据我的了解, 在高并发环境下, 为了减少锁的开销(睡眠, 线程上下文切换), 采用的是无锁编程(lock-free or lockless programming), 而无锁编程的基础是CAS操作, 那么CAS操作在高并发下的效果怎样, 怎么尽量避免并发带来的问题.

测试的Java代码:

package com.lqp.test;

import java.util.concurrent.atomic.AtomicLong;

public class ConcurrentCASTest {

    public static void main(String[] args) throws Exception {
        final AtomicLong value = new AtomicLong();

        final int count = 100 * 10000;
        int threadCount = 1;

        for (int i = 0; i < threadCount; i++) {
            final int id = i;
            new Thread(new Runnable() {

                @Override
                public void run() {
                    long start = System.nanoTime();

                    int failCount = 0;
                    for (int i = 0; i < count; i++) {
                        long initVal = value.get();

                        boolean suc = value.compareAndSet(initVal, initVal + 1);

                        if (!suc) {
                            failCount++;
                        }
                    }

                    long diffMilis = (System.nanoTime() - start) / 1000 / 1000;

                    println("Time = " + diffMilis + " milis" + ", ThreadId = " + id + ", fail count = " + failCount + ", failPercent = " + (failCount * 100) / (double)count);
                }
            }).start();
        }
    }

    public static boolean println(String msg) {
        System.out.println(msg);

        return true;
    }
}

说明:

  • 循环100W次对一个AtomicLong变量, 取值, +1, 然后CAS设置值, 失败则统计失败次数, 结束时记录100W次操作所用的时间
  • threadCount是线程数量, 改变线程数目观察失败情况
  • 虽然测试语言是java, 但底层核心是仍然cpu操作指令 ‘lock cmpxchg’, 不用C测试是因为写起来不太方便
  • CPU配置Intel(R) Core(TM) i7-4710MQ CPU @ 2.50GHz, 8核
  • java版本信息
    • java version “1.8.0_91”
    • Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
    • Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)

测试结果:

threadCount = 1, 即单线程下无并发修改操作, 测试3次:

  1. Time = 16 milis, ThreadId = 0, fail count = 0, failPercent = 0.0
  2. Time = 16 milis, ThreadId = 0, fail count = 0, failPercent = 0.0
  3. Time = 16 milis, ThreadId = 0, fail count = 0, failPercent = 0.0

threadCount = 2, 双线程同时修改, 测试3次:

  1. Time = 62 milis, ThreadId = 1, fail count = 347064, failPercent = 34.7064
    Time = 64 milis, ThreadId = 0, fail count = 463725, failPercent = 46.3725
  2. Time = 65 milis, ThreadId = 1, fail count = 478589, failPercent = 47.8589
    Time = 66 milis, ThreadId = 0, fail count = 477393, failPercent = 47.7393
  3. Time = 66 milis, ThreadId = 0, fail count = 489875, failPercent = 48.9875
    Time = 65 milis, ThreadId = 1, fail count = 490575, failPercent = 49.0575

threadCount = 4, 4线程同时修改, 测试2次:

  1. Time = 150 milis, ThreadId = 0, fail count = 663234, failPercent = 66.3234
    Time = 152 milis, ThreadId = 1, fail count = 747265, failPercent = 74.7265
    Time = 154 milis, ThreadId = 3, fail count = 666898, failPercent = 66.6898
    Time = 154 milis, ThreadId = 2, fail count = 675097, failPercent = 67.5097
  2. Time = 134 milis, ThreadId = 1, fail count = 522787, failPercent = 52.2787
    Time = 148 milis, ThreadId = 3, fail count = 746457, failPercent = 74.6457
    Time = 150 milis, ThreadId = 2, fail count = 744108, failPercent = 74.4108
    Time = 150 milis, ThreadId = 0, fail count = 710502, failPercent = 71.0502

threadCount = 4, 4线程同时修改, 测试1次:

Time = 258 milis, ThreadId = 2, fail count = 753286, failPercent = 75.3286
Time = 269 milis, ThreadId = 6, fail count = 769007, failPercent = 76.9007
Time = 277 milis, ThreadId = 5, fail count = 750360, failPercent = 75.036
Time = 281 milis, ThreadId = 3, fail count = 799387, failPercent = 79.9387
Time = 283 milis, ThreadId = 0, fail count = 790358, failPercent = 79.0358
Time = 285 milis, ThreadId = 1, fail count = 765177, failPercent = 76.5177
Time = 279 milis, ThreadId = 7, fail count = 763133, failPercent = 76.3133
Time = 285 milis, ThreadId = 4, fail count = 791819, failPercent = 79.1819

可以看到, 在两个线程竞争的情况下, 失败率就已经到达近50%了, 这也好理解, 一人一半的概率成功. 对于高并发下来说, 性能比没有竞争下下降了4倍左右. 4线程竞争的情况下, 下降10倍左右; 8线程下, 下降接近20倍. 在实际情况中, 失败的时候很可能选择继续尝试, 直至成功, 除了时间上的进一步增加, 由于失败而进一步尝试也导致了CPU周期的浪费.

什么具体场景下可能会遇到上述的情况呢? 在我的认知领域里, JVM在分配内存的时候就有可能遇到. 我们知道heap是线程共同访问的, java里面分配对象是很常见的操作, 当线程很多, 分配的时候就很可能产生竞争. 尽管hotspot里的分配可以由一条CAS的操作搞定, 但竞争激烈情况下, 仍然会发生性能退化.

怎么去减少这种不良效应呢? 一个方法就是采用线程本地化, 让操作尽量不去参加竞争. 比如在hotspot中, 每个线程会一次性从heap中申请一块稍大的内存TLAB(thread local allocation buffer), 然后对象分配时, 优先从这块thread local的内存分配, 由于是线程私有的, 因此不需要CAS的操作即可完成分配, 只有当TLAB中不能满足时, 才会使用CAS的方式分配. 在其他需要减少竞争的地方, 也可用借鉴这种思路来解决.

版权声明:本文为博主原创文章,未经博主允许不得转载。

相关文章推荐

java并发 非阻塞同步算法与CAS(Compare and Swap)无锁算法

锁(lock)的代价 锁是用来做并发最简单的方式,当然其代价也是最高的。内核态的锁的时候需要操作系统进行一次上下文切换,加锁、释放锁会导致比较多的上下文切换和调度延时,等待锁的线程会被挂起直至锁释放...

【Java并发编程】9、非阻塞同步算法与CAS(Compare and Swap)无锁算法

锁是用来做并发最简单的方式,当然其代价也是最高的。内核态的锁的时候需要操作系统进行一次上下文切换,加锁、释放锁会导致比较多的上下文切换和调度延时,等待锁的线程会被挂起直至锁释放。在上下文切换的时候,c...

无锁的数据结构(Lock-Free)及CAS(Compare-and-Swap)机制

当同时存在读写线程时,默认情况下是不保证线程安全的,因而需要利用信号量来进行线程同步(Synchronization),如关键代码段、互斥体等,同时操作系统也提供了相应的API。然而同步并不总是满足条...

Compare And Swap(CAS)实现无锁多生产者

struct node{ struct node *next; int data; }struct node *queue;//队列头多个消费者(多线程)都需要向这个queue插入数据 为了说明...

非阻塞同步算法与CAS(Compare and Swap)无锁算法

参考文献:http://www.cnblogs.com/Mainz/p/3546347.html?utm_source=tuicool&utm_medium=referral 锁(lock)的代...

非阻塞同步算法与CAS(Compare and Swap)无锁算法

锁(lock)的代价 锁是用来做并发最简单的方式,当然其代价也是最高的。内核态的锁的时候需要操作系统进行一次上下文切换,加锁、释放锁会导致比较多的上下文切换和调度延时,等待锁的线程会被挂起直至锁释放...

非阻塞同步算法与CAS(Compare and Swap)无锁算法

锁(lock)的代价 锁是用来做并发最简单的方式,当然其代价也是最高的。内核态的锁的时候需要操作系统进行一次上下文切换,加锁、释放锁会导致比较多的上下文切换和调度延时,等待锁的线程会被挂起直至锁释放...

非阻塞同步算法与CAS(Compare and Swap)无锁算法

锁(lock)的代价 锁是用来做并发最简单的方式,当然其代价也是最高的。内核态的锁的时候需要操作系统进行一次上下文切换,加锁、释放锁会导致比较多的上下文切换和调度延时,等待锁的线程会被挂起直至锁...

非阻塞同步算法与CAS(Compare and Swap)无锁算法

锁(lock)的代价 锁是用来做并发最简单的方式,当然其代价也是最高的。内核态的锁的时候需要操作系统进行一次上下文切换,加锁、释放锁会导致比较多的上下文切换和调度延时,等待锁的线程会被挂起直至锁释放。...

非阻塞同步算法与CAS(Compare and Swap)无锁算法

锁(lock)的代价 锁是用来做并发最简单的方式,当然其代价也是最高的。内核态的锁的时候需要操作系统进行一次上下文切换,加锁、释放锁会导致比较多的上下文切换和调度延时,等待锁的线程会被挂起直至锁...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)