`

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)

 

 

 

1
2
分享到:
评论
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却可以并发。

相关推荐

    contention-profiling:ReentrantLock 和 ReentrantReadWriteLock 上的配置文件争用

    `ReentrantLock`和`ReentrantReadWriteLock`是Java并发包`java.util.concurrent.locks`中的两个重要工具,它们提供了比标准`synchronized`关键字更高级别的锁控制机制。本文将深入探讨这两个类,以及如何通过配置...

    JUC知识点总结(三)ReentrantLock与ReentrantReadWriteLock源码解析

    8. Lock接口 (ReentrantLock 可重入锁) 特性 ReentantLock 继承接口 Lock 并实现了接口中定义的方法, 它是一种可重入锁, 除了能完成 synchronized 所能完成的所有工作外,还提供了诸如可响应中断锁、可轮询锁...

    ReadWriteLock接口及其实现ReentrantReadWriteLock方法

    在 ReentrantReadWriteLock 中,读锁和写锁是通过 Sync 内部类实现的,Sync 是一个同步器,负责管理锁的状态。 ReentrantReadWriteLock 的构造方法 ReentrantReadWriteLock 有两个构造方法:无参数构造方法和带有...

    Lock、Synchoronized和ReentrantLock的使用

    四、性能比较 通过实验,可以看到使用 Lock 的性能比使用 Synchronized 关键字要提高 4~5 倍;使用信号量实现同步的速度大约比 Synchronized 要慢 10~20%;使用 Atomic 包的 AtomicInteger 速度是比 Lock 要快 1 个...

    Java并发之ReentrantLock类源码解析

    Java并发之ReentrantLock类源码解析 ReentrantLock是Java并发包中的一种同步工具,它可以实现可重入锁的功能。ReentrantLock类的源码分析对理解Java并发机制非常重要。本文将对ReentrantLock类的源码进行详细分析,...

    ReentrantLock与synchronized

    在Java多线程编程中,`ReentrantLock`和`synchronized`都是用于实现线程同步的重要工具,确保在并发环境中数据的一致性和正确...例如,`TestLock.java`中的示例可能就是比较了两种锁在特定场景下的使用效果和性能差异。

    浅谈多线程中的锁的几种用法总结(必看)

    在实际应用中,ReentrantLock 和 ReentrantReadWriteLock 都可以用于解决多线程之间的资源竞争问题,但是 ReentrantReadWriteLock 可以提供更高的并发度。在选择锁机制时,需要根据实际情况选择合适的锁机制。 锁...

    java ReentrantLock详解.docx

    `ReentrantLock`是Java并发编程中的一种高级锁机制,它是`java.util.concurrent.locks`包中的类,提供了比`...了解并熟练使用`ReentrantLock`能帮助开发者更好地解决并发问题,提高程序的并发性能和健壮性。

    ReentrantLock源码的使用问题详解.docx

    《ReentrantLock源码详解与应用》 ReentrantLock,可重入锁,是Java并发编程中一个重要的锁实现,它提供了比...理解ReentrantLock的源码有助于我们更好地掌握并发编程中的锁机制,以优化并发性能和避免死锁等问题。

    Java中ReentrantLock的使用.docx

    但在JDK 6.0及以后的版本中,synchronized的性能得到了显著提升,与ReentrantLock的性能差距已经不大。尽管如此,ReentrantLock仍然有其独特之处,比如它可以提供公平锁和非公平锁的选择,支持中断锁等待,以及更细...

    Java多线程源码笔记.pdf

    6. ReentrantLock和ReentrantReadWriteLock:ReentrantLock是可重入锁,允许多次进入同一线程,保证了线程安全。ReentrantReadWriteLock是读写锁,允许多个读线程同时访问,但写线程独占资源,提高了并发性能。 7. ...

    ReentrantLock解析

    《ReentrantLock深度解析》 在Java并发编程中,ReentrantLock是JDK提供的一个可...在实际开发中,可以根据需求选择使用synchronized还是ReentrantLock,或者其他的并发控制手段,以达到最佳的并发性能和资源利用效率。

    ReentrantLock源码分析

    ReentrantLock通过AQS提供了强大的锁管理能力,尤其在非公平锁模式下,即使在高并发场景下也能表现出良好的性能。通过对上述流程的分析可以看出,ReentrantLock的设计充分考虑了各种实际应用场景的需求,在保证线程...

    ReentrantLock代码剖析之ReentrantLock_lock

    `ReentrantLock`是Java并发编程中非常重要的一种锁,它提供了比`synchronized`关键字更细粒度的控制,并且在高竞争条件下的性能更优。在本文中,我们将深入分析`ReentrantLock`的`lock()`方法,理解其内部机制,包括...

    Java并发包源码分析(JDK1.8)

    Java并发包源码分析(JDK1.8):囊括了java.util.concurrent包中大部分类的源码分析,其中涉及automic包,locks包(AbstractQueuedSynchronizer、ReentrantLock、ReentrantReadWriteLock、LockSupport等),queue...

    ReentrantLock 实现原理 1

    首先,ReentrantLock 会调用 sync 的 lock 方法,而这个方法是一个抽象方法,具体是由其子类(FairSync)来实现的。在公平锁的实现中,lock 方法会调用 acquire 方法,而 acquire 方法会尝试获取锁(tryAcquire),...

    ReentrantLock与synchronized区别

    java语言 并发编程 ReentrantLock与synchronized区别 详解

    ReentrantLock的使用及注意事项

    ReentrantLock的使用及注意事项

    Java多线程之ReentrantLock与Condition - 平凡希 - 博客园1

    总之,`ReentrantLock`是Java并发编程中的强大工具,它提供了丰富的功能和灵活性,使得开发者能够根据具体需求调整锁的行为,提高并发代码的性能和安全性。在设计和实现多线程程序时,了解和正确使用`ReentrantLock`...

    ReentrantLock 与 synchronized 简介

    ### ReentrantLock 与 synchronized 的比较 #### 一、引言 在Java中,多线程和并发控制一直是程序员关注的重点。随着Java的发展,其语言本身及标准库提供了丰富的工具来帮助开发者处理并发问题。其中,`...

Global site tag (gtag.js) - Google Analytics