- 浏览: 461131 次
- 性别:
- 来自: 杭州
文章分类
最新评论
-
syw19901001:
30多条mysql数据库优化方法,千万级数据库记录查询轻松解决 ...
MYSQL的全表扫描,主键索引(聚集索引、第一索引),非主键索引(非聚集索引、第二索引),覆盖索引四种不同查询的分析 -
gaoyuanyuan121:
直接改成root.war,根路径能访问,项目路径也能访问,赞 ...
jetty 中如何设置root app -
freezingsky:
翻出来,再看一次!
AOP 的简单入门 -
Shen.Yiyang:
<div class="quote_title ...
ReentrantLock、sync、ReentrantReadWriteLock性能比较 -
inter12:
<div class="quote_title ...
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资源设计的。
串行我也只是直接用了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资源设计的。
串行我也只是直接用了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资源设计的。
串行我也只是直接用了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消耗,性能马上就来了
所以串行的话是: 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消耗,性能马上就来了
所以串行的话是: 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却可以并发。
发表评论
-
个人对于关系数据和NOSQL的看法
2013-01-30 18:00 1703存储模型: 关系数据库中每条数据都是符合一定的格式 ... -
Dtrace初探
2013-01-05 14:35 9DTrace 简介: DTrace:D ... -
Btrace、DTrace实战之Btrace
2013-01-04 18:47 3721Btrace及Dtrace实战之BTRACE ... -
上线性能调优笔记
2012-09-12 21:16 2116普通的性能调优主要从四个方面入手 网络,磁盘IO,内存,C ... -
spring的BeanUtils和cglib的BeanCopier性能比较
2012-07-02 23:34 7523测试环境: JDK1.6.29 CPU:I7 2.8 ... -
cpu的缓存同步机制
2012-02-22 15:40 4039cache同步机制之读写 ... -
mat 使用笔记
2012-02-15 17:52 12145MAT 使用初探 今天线上一个应用的持久区满了,一直没 ... -
JVM参数调整实例--2
2010-07-28 22:31 1655测试二: 设置tomcat内 ... -
JVM参数调整实例--1
2010-07-28 22:31 1490近期在进行一个项目的性能调优, 目标是支撑 1000 的并发数 ... -
记一次代码优化(大数据量处理及存储)
2010-02-13 11:14 7553记一次代码优化过程 --- 大数据量的处理及存储 1. ... -
jconsole设置
2010-01-13 08:59 1334在 catalina.sh中设置 JAVA_OPTS=&qu ...
相关推荐
`ReentrantLock`和`ReentrantReadWriteLock`是Java并发包`java.util.concurrent.locks`中的两个重要工具,它们提供了比标准`synchronized`关键字更高级别的锁控制机制。本文将深入探讨这两个类,以及如何通过配置...
8. Lock接口 (ReentrantLock 可重入锁) 特性 ReentantLock 继承接口 Lock 并实现了接口中定义的方法, 它是一种可重入锁, 除了能完成 synchronized 所能完成的所有工作外,还提供了诸如可响应中断锁、可轮询锁...
在 ReentrantReadWriteLock 中,读锁和写锁是通过 Sync 内部类实现的,Sync 是一个同步器,负责管理锁的状态。 ReentrantReadWriteLock 的构造方法 ReentrantReadWriteLock 有两个构造方法:无参数构造方法和带有...
四、性能比较 通过实验,可以看到使用 Lock 的性能比使用 Synchronized 关键字要提高 4~5 倍;使用信号量实现同步的速度大约比 Synchronized 要慢 10~20%;使用 Atomic 包的 AtomicInteger 速度是比 Lock 要快 1 个...
Java并发之ReentrantLock类源码解析 ReentrantLock是Java并发包中的一种同步工具,它可以实现可重入锁的功能。ReentrantLock类的源码分析对理解Java并发机制非常重要。本文将对ReentrantLock类的源码进行详细分析,...
在Java多线程编程中,`ReentrantLock`和`synchronized`都是用于实现线程同步的重要工具,确保在并发环境中数据的一致性和正确...例如,`TestLock.java`中的示例可能就是比较了两种锁在特定场景下的使用效果和性能差异。
在实际应用中,ReentrantLock 和 ReentrantReadWriteLock 都可以用于解决多线程之间的资源竞争问题,但是 ReentrantReadWriteLock 可以提供更高的并发度。在选择锁机制时,需要根据实际情况选择合适的锁机制。 锁...
`ReentrantLock`是Java并发编程中的一种高级锁机制,它是`java.util.concurrent.locks`包中的类,提供了比`...了解并熟练使用`ReentrantLock`能帮助开发者更好地解决并发问题,提高程序的并发性能和健壮性。
《ReentrantLock源码详解与应用》 ReentrantLock,可重入锁,是Java并发编程中一个重要的锁实现,它提供了比...理解ReentrantLock的源码有助于我们更好地掌握并发编程中的锁机制,以优化并发性能和避免死锁等问题。
但在JDK 6.0及以后的版本中,synchronized的性能得到了显著提升,与ReentrantLock的性能差距已经不大。尽管如此,ReentrantLock仍然有其独特之处,比如它可以提供公平锁和非公平锁的选择,支持中断锁等待,以及更细...
6. ReentrantLock和ReentrantReadWriteLock:ReentrantLock是可重入锁,允许多次进入同一线程,保证了线程安全。ReentrantReadWriteLock是读写锁,允许多个读线程同时访问,但写线程独占资源,提高了并发性能。 7. ...
《ReentrantLock深度解析》 在Java并发编程中,ReentrantLock是JDK提供的一个可...在实际开发中,可以根据需求选择使用synchronized还是ReentrantLock,或者其他的并发控制手段,以达到最佳的并发性能和资源利用效率。
ReentrantLock通过AQS提供了强大的锁管理能力,尤其在非公平锁模式下,即使在高并发场景下也能表现出良好的性能。通过对上述流程的分析可以看出,ReentrantLock的设计充分考虑了各种实际应用场景的需求,在保证线程...
`ReentrantLock`是Java并发编程中非常重要的一种锁,它提供了比`synchronized`关键字更细粒度的控制,并且在高竞争条件下的性能更优。在本文中,我们将深入分析`ReentrantLock`的`lock()`方法,理解其内部机制,包括...
Java并发包源码分析(JDK1.8):囊括了java.util.concurrent包中大部分类的源码分析,其中涉及automic包,locks包(AbstractQueuedSynchronizer、ReentrantLock、ReentrantReadWriteLock、LockSupport等),queue...
首先,ReentrantLock 会调用 sync 的 lock 方法,而这个方法是一个抽象方法,具体是由其子类(FairSync)来实现的。在公平锁的实现中,lock 方法会调用 acquire 方法,而 acquire 方法会尝试获取锁(tryAcquire),...
java语言 并发编程 ReentrantLock与synchronized区别 详解
ReentrantLock的使用及注意事项
总之,`ReentrantLock`是Java并发编程中的强大工具,它提供了丰富的功能和灵活性,使得开发者能够根据具体需求调整锁的行为,提高并发代码的性能和安全性。在设计和实现多线程程序时,了解和正确使用`ReentrantLock`...
### ReentrantLock 与 synchronized 的比较 #### 一、引言 在Java中,多线程和并发控制一直是程序员关注的重点。随着Java的发展,其语言本身及标准库提供了丰富的工具来帮助开发者处理并发问题。其中,`...