ReentrantLock、sync、ReentrantReadWriteLock性能比较

 

今天在处理问题时候，采用了读写锁，之前印象中记得读写锁在读大于写的场景下效率会比较高，但是并不是很明确，所以就乘机测试。具体测试代码如下所示：

 

package com.zhaming.lock;

import java.util.Random;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.CyclicBarrier;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReadWriteLock;
import java.util.concurrent.locks.ReentrantLock;
import java.util.concurrent.locks.ReentrantReadWriteLock;

public class ConcurrentObject {

    private static Random    random    = new Random();

    private final static int READ_NUM  = 100;

    private final static int WRITE_NUM = 100;

    private int              value;

    private ReadWriteLock    lock      = new ReentrantReadWriteLock();

    private Lock             locknew   = new ReentrantLock();

    public static void main(String[] args) throws InterruptedException {

        // int maxProcessor = Runtime.getRuntime().availableProcessors() * 2; 防止线程池大小过大，CPU过多的上下文切换导致的开销影响
        int maxProcessor = READ_NUM + WRITE_NUM;// 线程池大小必须同 总共开启的对象
        final ExecutorService newFixedThreadPool = Executors.newFixedThreadPool(maxProcessor);

        final CountDownLatch latch = new CountDownLatch(READ_NUM + WRITE_NUM);// 最后关闭线程池
        final CyclicBarrier barrier = new CyclicBarrier(READ_NUM + WRITE_NUM);// 等待所有线程启动后并发读写

        final ConcurrentObject concurrentObject = new ConcurrentObject();

        for (int i = 0; i < READ_NUM; i++) {
            newFixedThreadPool.execute(new Runnable() {

                @Override
                public void run() {
                    try {
                        barrier.await();
                    } catch (Exception e) {
                        e.printStackTrace();
                    }

                    TimeCostUtils.start(TimeCostUtils.READ);
                    concurrentObject.getValueLock();
                    TimeCostUtils.end();

                    latch.countDown();
                }
            });
        }

        for (int i = 0; i < WRITE_NUM; i++) {
            newFixedThreadPool.execute(new Runnable() {

                @Override
                public void run() {

                    int nextInt = random.nextInt(1000);
                    try {
                        barrier.await();
                    } catch (Exception e) {
                        e.printStackTrace();
                    }

                    TimeCostUtils.start(TimeCostUtils.WRITE);
                    concurrentObject.setValueLock(nextInt);
                    TimeCostUtils.end();

                    latch.countDown();
                }
            });
        }

        latch.await();

        newFixedThreadPool.shutdown();

        // 系统推出前，关闭线程池及计算平均耗时、总耗时
        Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() {

            @Override
            public void run() {

                display();
            }
        }));

    }

    public static void display() {
        System.out.println("read cost average:" + (TimeCostUtils.getReadLong().get() / READ_NUM) + " ns");

        System.out.println("write cost average:" + (TimeCostUtils.getWriteLong().get() / WRITE_NUM) + " ns");
    }

    public int getValue() {

        lock.readLock().lock();

        try {
            return value;
        } finally {

            lock.readLock().unlock();
        }
    }

    public void setValue(int value) {
        locknew.lock();

        try {
            this.value = value;
        } finally {
            locknew.unlock();
        }

    }

    public int getValueLock() {

        locknew.lock();

        try {
            return value;
        } finally {

            locknew.unlock();
        }
    }

    public void setValueLock(int value) {
        lock.writeLock().lock();

        try {
            this.value = value;
        } finally {
            lock.writeLock().unlock();
        }

    }

    public synchronized int getValueSyn() {
        return value;
    }

    public synchronized void setValueSyn(int value) {
        this.value = value;
    }

}

 

辅助工具类：

 

package com.zhaming.lock;

import java.util.concurrent.atomic.AtomicLong;

public class TimeCostUtils {

    private static AtomicLong        readLong  = new AtomicLong();

    private static AtomicLong        writeLong = new AtomicLong();

    public final static String       WRITE     = "write";

    public final static String       READ      = "read";

    static ThreadLocal<TimesRecords> recordMap = new ThreadLocal<TimesRecords>();

    public static void start(String prefix) {

        TimesRecords timesRecords = new TimesRecords(prefix, System.nanoTime());
        recordMap.set(timesRecords);
    }

    public static void end() {
        TimesRecords timesRecords = recordMap.get();
        long cost = System.nanoTime() - timesRecords.getCost();

        // 计算每次的开销时间
        if (timesRecords.getName().equals(WRITE)) {
            writeLong.addAndGet(cost);
        } else {
            readLong.addAndGet(cost);
        }
    }

    public static AtomicLong getReadLong() {
        return readLong;
    }

    public static AtomicLong getWriteLong() {
        return writeLong;
    }

    static class TimesRecords {

        private String name;

        private long   cost;

        public TimesRecords(String name, long cost) {
            this.name = name;
            this.cost = cost;
        }

        public String getName() {
            return name;
        }

        public void setName(String name) {
            this.name = name;
        }

        public long getCost() {
            return cost;
        }

        public void setCost(long cost) {
            this.cost = cost;
        }

    }
}

 

 

 

测试的JDK版本：

java version "1.6.0_29"

Java(TM) SE Runtime Environment (build 1.6.0_29-b11)

Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02, mixed mode)

 

 

 

评论

7 楼 Shen.Yiyang 2013-01-15  

inter12 写道

Shen.Yiyang 写道

我说的不是NIO和BIO的区别，而是所有现代操作系统的IO设计，即IO和CPU是并行的；仅仅用BIO测试一下100K，1M, 3M, 5M的这些场景，就知道只要是IO，读写锁肯定有性能优势。我始终想说明的是，只要你的过程里面不仅仅是赋值（CPU），而是有体现了read、write含义的IO过程，读写锁的性能就会提交，而提交的程度取决于IO和CPU时间对比。

串行我也只是直接用了synchronized这个词，表示代码块的顺序执行；关注的是读写过程的串行化执行，而不是获取锁的过程中CPU的调度，这个差异太小了；真正的读写场景，代码块的顺序执行带来的时间损耗，比单纯的锁消耗的CPU时间要大多了。

至于没有IO的过程，或者你声称的“时间极短”的过程，其实都用不到读写锁来实现读写安全，拿文中例子来说，读不需要读锁，写的时候CAS就可以了；读写锁反而多做了CAS。换句话说，读写锁根本就不是为了竞争CPU资源设计的。

想请教下是何种设计是你所描述的架构。SMP ? 还是NUMA? 亦或是MPP？

IO和CPU的并行，与SMP NUMA有什么关系。。。你说的这几种架构是处理器和其他资源的关系，但是IO控制机制跟你的IO设备如何划分给CPU没有关系；你随便找一本计算机组成原理，或者操作系统也可以顺带会讲，现代计算机系统的IO就是和CPU并行的；可以是中断驱动IO，DMA或者IO通道，它们在需要CPU干预的地方会有所不同，但是干预点以外，CPU可以和IO并行是一定的。

6 楼 inter12 2013-01-15  

Shen.Yiyang 写道

我说的不是NIO和BIO的区别，而是所有现代操作系统的IO设计，即IO和CPU是并行的；仅仅用BIO测试一下100K，1M, 3M, 5M的这些场景，就知道只要是IO，读写锁肯定有性能优势。我始终想说明的是，只要你的过程里面不仅仅是赋值（CPU），而是有体现了read、write含义的IO过程，读写锁的性能就会提交，而提交的程度取决于IO和CPU时间对比。

串行我也只是直接用了synchronized这个词，表示代码块的顺序执行；关注的是读写过程的串行化执行，而不是获取锁的过程中CPU的调度，这个差异太小了；真正的读写场景，代码块的顺序执行带来的时间损耗，比单纯的锁消耗的CPU时间要大多了。

至于没有IO的过程，或者你声称的“时间极短”的过程，其实都用不到读写锁来实现读写安全，拿文中例子来说，读不需要读锁，写的时候CAS就可以了；读写锁反而多做了CAS。换句话说，读写锁根本就不是为了竞争CPU资源设计的。

想请教下是何种设计是你所描述的架构。SMP ? 还是NUMA? 亦或是MPP？

5 楼 Shen.Yiyang 2013-01-10  

我说的不是NIO和BIO的区别，而是所有现代操作系统的IO设计，即IO和CPU是并行的；仅仅用BIO测试一下100K，1M, 3M, 5M的这些场景，就知道只要是IO，读写锁肯定有性能优势。我始终想说明的是，只要你的过程里面不仅仅是赋值（CPU），而是有体现了read、write含义的IO过程，读写锁的性能就会提交，而提交的程度取决于IO和CPU时间对比。

串行我也只是直接用了synchronized这个词，表示代码块的顺序执行；关注的是读写过程的串行化执行，而不是获取锁的过程中CPU的调度，这个差异太小了；真正的读写场景，代码块的顺序执行带来的时间损耗，比单纯的锁消耗的CPU时间要大多了。

至于没有IO的过程，或者你声称的“时间极短”的过程，其实都用不到读写锁来实现读写安全，拿文中例子来说，读不需要读锁，写的时候CAS就可以了；读写锁反而多做了CAS。换句话说，读写锁根本就不是为了竞争CPU资源设计的。

4 楼 inter12 2013-01-09  

Shen.Yiyang 写道

同志啊，就算考虑单CPU，读写锁消耗的时间也不完全是串行相加的啊，IO过程CPU只发出指令啊，还是有通道（或者I/O设备，名称取决于操作系统的IO控制机制）完成IO的，通道操作和CPU是并发的。

所以串行的话是： MAX（（单个线程通道时间）*N ， 总CPU时间），多线程并发的话是 MAX（多线程一起走IO通道时间，总CPU时间），这里多线程同时走通道是比单线程一个个走通道快的，因为你带宽允许。

所以这里看出，IO通道时间越长，读写锁优势越大，你考虑web程序的网络IO消耗，性能马上就来了

我这里说的串行是你在第一个回复的串行的概念，至于你现在提到的CPU时间切换，对于一些进程进行睡眠并切换执行另一个线程完全是令一个层面的问题，简单的说你所描述是NIO和BIO的区别，并不是我们要讨论的问题关键，关键是：
sync完全就是串行时间，readwrite却可以并发
这句话里面sync并不是串行的，它不过是在争取锁的时候自旋了一段时间，后面还是并行的(注意，这里的并行只的是多CPU情况的并行，单CPU那叫并发)而读写锁是直接进等待队列，再去并行的争取锁。

这样我说的够明白不？

3 楼 Shen.Yiyang 2013-01-09  

同志啊，就算考虑单CPU，读写锁消耗的时间也不完全是串行相加的啊，IO过程CPU只发出指令啊，还是有通道（或者I/O设备，名称取决于操作系统的IO控制机制）完成IO的，通道操作和CPU是并发的。

所以串行的话是： MAX（（单个线程通道时间）*N ， 总CPU时间），多线程并发的话是 MAX（多线程一起走IO通道时间，总CPU时间），这里多线程同时走通道是比单线程一个个走通道快的，因为你带宽允许。

所以这里看出，IO通道时间越长，读写锁优势越大，你考虑web程序的网络IO消耗，性能马上就来了

2 楼 inter12 2013-01-09  

Shen.Yiyang 写道

你只测试了锁本身 挂起/唤醒(或自旋)的性能，并没有考虑读写的时间；假设你把读写从一个赋值改成10ms, 100ms, 500ms的过程，这个测试结果肯定会不一样；sync完全就是串行时间，readwrite却可以并发。

确实，这里只是单纯的挂起、唤醒，因为sync的contentionList采用的自旋锁，所以在当前线程执行很短的时间下能获得很大的性能，而ReentrantLock采用的是非公平的偏向锁，故会有稍微的性能差异，而读写锁的实现是读写两个共同持有一个Sync对象，具体实现同ReentrantLock，也是非公平偏向锁，在这种场景下性能比ReentrantLock弱。
sync和读写锁在针对单CPU上都是串行的，区别在于sync在添加到contentionList时，自选了一段时间，因为若我们设定了睡眠10ms或是100ms的话，那这段自选时间肯定是浪费了，自旋失败后，才进入等待队列。而ReentrantLock和读写锁的实现是先将线程放入队列，而不是自选，然后通过一个for(;;){} 循环调用CAS指令来获取锁，故在读写分离上效率高于单纯的使用sync

1 楼 Shen.Yiyang 2013-01-07  

你只测试了锁本身 挂起/唤醒(或自旋)的性能，并没有考虑读写的时间；假设你把读写从一个赋值改成10ms, 100ms, 500ms的过程，这个测试结果肯定会不一样；sync完全就是串行时间，readwrite却可以并发。