- 浏览: 449692 次
- 性别:
- 来自: 杭州
文章分类
最新评论
-
syw19901001:
30多条mysql数据库优化方法,千万级数据库记录查询轻松解决 ...
MYSQL的全表扫描,主键索引(聚集索引、第一索引),非主键索引(非聚集索引、第二索引),覆盖索引四种不同查询的分析 -
gaoyuanyuan121:
直接改成root.war,根路径能访问,项目路径也能访问,赞 ...
jetty 中如何设置root app -
freezingsky:
翻出来,再看一次!
AOP 的简单入门 -
Shen.Yiyang:
inter12 写道Shen.Yiyang 写道我说的不是NI ...
ReentrantLock、sync、ReentrantReadWriteLock性能比较 -
inter12:
Shen.Yiyang 写道我说的不是NIO和BIO的区别,而 ...
ReentrantLock、sync、ReentrantReadWriteLock性能比较
ReentrantLock、sync、ReentrantReadWriteLock性能比较
- 博客分类:
- Java性能调优
今天在处理问题时候,采用了读写锁,之前印象中记得读写锁在读大于写的场景下效率会比较高,但是并不是很明确,所以就乘机测试。具体测试代码如下所示:
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 1662存储模型: 关系数据库中每条数据都是符合一定的格式 ... -
Dtrace初探
2013-01-05 14:35 9DTrace 简介: DTrace:D ... -
Btrace、DTrace实战之Btrace
2013-01-04 18:47 3648Btrace及Dtrace实战之BTRACE ... -
上线性能调优笔记
2012-09-12 21:16 2064普通的性能调优主要从四个方面入手 网络,磁盘IO,内存,C ... -
spring的BeanUtils和cglib的BeanCopier性能比较
2012-07-02 23:34 7436测试环境: JDK1.6.29 CPU:I7 2.8 ... -
cpu的缓存同步机制
2012-02-22 15:40 3931cache同步机制之读写 ... -
mat 使用笔记
2012-02-15 17:52 11968MAT 使用初探 今天线上一个应用的持久区满了,一直没 ... -
JVM参数调整实例--2
2010-07-28 22:31 1604测试二: 设置tomcat内 ... -
JVM参数调整实例--1
2010-07-28 22:31 1446近期在进行一个项目的性能调优, 目标是支撑 1000 的并发数 ... -
记一次代码优化(大数据量处理及存储)
2010-02-13 11:14 7482记一次代码优化过程 --- 大数据量的处理及存储 1. ... -
jconsole设置
2010-01-13 08:59 1242在 catalina.sh中设置 JAVA_OPTS=&qu ...
相关推荐
8. Lock接口 (ReentrantLock 可重入锁) 特性 ReentantLock 继承接口 Lock 并实现了接口中定义的方法, 它是一种可重入锁, 除了能完成 synchronized 所能完成的所有工作外,还提供了诸如可响应中断锁、可轮询锁...
争用分析 ReentrantLock 和 ReentrantReadWriteLock 上的配置文件争用
1.什么是多线程 2.Thread类解析 3.使用多线程需要注意的问题 4.synchronized锁和lock锁 ...6.ReentrantLock和ReentrantReadWriteLock 7.线程池 8.死锁 9.线程常用的工具栏 10.Atomic 11.ThreadLocal
ReentrantLock java除了使用关键字synchronized外,还可以使用ReentrantLock实现独占锁的功能。而且ReentrantLock相比synchronized而言功能更加丰富,使用起来更为灵活,也更适合复杂的并发场景。这篇文章主要是从...
Java并发包源码分析(JDK1.8):囊括了java.util.concurrent包中大部分类的源码分析,其中涉及automic包,locks包(AbstractQueuedSynchronizer、ReentrantLock、ReentrantReadWriteLock、LockSupport等),queue...
java语言 并发编程 ReentrantLock与synchronized区别 详解
ReentrantLock的使用及注意事项
1、ReentrantLock简介 2、ReentrantLock函数列表 3、重入的实现 4、公平锁与非公平锁 5、ReentrantLock 扩展的功能 6
ReentrantReadWriteLock, ReadWriteLock源码] [Condition 条件队列和Object.wait队列] 并发同步工具类 [CountDownLatch] [CyclicBarrier] [Semaphore] [Exchanger] Atomic包 并发集合 [BlockQueue] ...
比较 Locks 框架与传统 synchronized 关键字的不同之处。 ReentrantLock 简介: 详细讲解 ReentrantLock 的概念和特点。解释为什么它被称为“可重入锁”,以及如何解决传统锁可能的问题。 ReentrantLock 的基本用法...
一张图将整个ReentrantLock流程看懂,干货满满 一张图将整个ReentrantLock流程看懂,干货满满 一张图将整个ReentrantLock流程看懂,干货满满 一张图将整个ReentrantLock流程看懂,干货满满 一张图将整个...
ReentrantLock源码剖析
重入锁ReentrantLock 相对来说是synchronized、Object.wait()和Object.notify()方法的替代品(或者说是增强版),在JDK5.0的早期版本,重入锁的性能远远好于synchronized,但从JDK6.0开始,JDK在synchronized上做了...
4种常用Java线程锁的特点,性能比较、使用场景 线程(thread)是操作系统能够进行运算调度的最小单位。它被包含在进程之中,是进程中的实际运作单位。一条线程指的是进程中一个单一顺序的控制流,一个进程中可以并发...
ReentrantLock 实现原理 1
1. ReentrantLock的介绍 ReentrantLock重入锁,是实现Lock接口的一个类,也是在实际编程中使用频率很高的一个锁,支持重入性,表示能够对共享资源能够重复加锁,即当前线程获取该锁再次获取不会被阻塞。在java...
助于理解的例子 博文链接:https://uule.iteye.com/blog/1488356
ReentrantLock lock方法注释
NULL 博文链接:https://patrick002.iteye.com/blog/2170391
近日,阅读jdk并发包源码分析整理笔记。