[置顶] 关于synchronized与lock的性能比较
2016-09-09 13:41
204 查看
记得当初看教程的时候大家都说lock性能比好不少,最近需要自己设计一个缓存终于要自己尝试一番了。
B).lock实现原理则是依赖于硬件,现代处理器都支持CAS指令,所谓CAS指令简单的来说Compare And Set,CPU循环执行指令直到得到所期望的结果,换句话来说就是当变量真实值不等于当前线程调用时的值的时候(说明其他线程已经将这个值改变),就不会赋予变量新的值。这样就保证了变量在多线程环境下的安全性。
然而,现实情况是当JDK版本高于1.6的时候,synchronized已经被做了CAS的优化:具体是这样的,当执行到synchronized代码块时,先对对象头的锁标志位用lock cmpxchg的方式设置成“锁住“状态,释放锁时,在用lock cmpxchg的方式修改对象头的锁标志位为”释放“状态,写操作都立刻写回主内存。JVM会进一步对synchronized时CAS失败的那些线程进行阻塞操作(调用操作系统的信号量)(此段来摘自别处)。也就是先CAS操作,不行的话继而阻塞线程。
除此之外,系统环境,CPU架构,虚拟机环境都会影响两者的性能关系。
测试代码
测试对某Map对象高并发下的读写线程安全测试
测试对比有synchronized,ReadWriteLock,ConcurrentHashMap,
HashMap 用synchronized重写
用读写锁实现的Map代理类,有些粗糙,没加try finally
并发量100000,每个线程对Map执行读写100次,总耗时
ConcurrentHashMap:6112ms
synchronized:6121ms
ReadWriteLock:6182ms
Collections.synchronizedMap:6175ms
并发量10000,每个线程对Map执行读写1000次,总耗时
ConcurrentHashMap:1126ms
synchronized:1145ms
ReadWriteLock:2086ms
Collections.synchronizedMap:1170ms
并发量5000,每个线程对Map执行读写10000次,总耗时
ConcurrentHashMap:1206ms
synchronized:4896ms
ReadWriteLock:8505ms
Collections.synchronizedMap:4883ms
并发量1000,每个线程对Map执行读写100000次,总耗时
ConcurrentHashMap:1748ms
synchronized:9341ms
ReadWriteLock:18720ms
Collections.synchronizedMap:8945ms
并发量100,每个线程对Map执行读写1000000次,总耗时
ConcurrentHashMap:1922ms
synchronized:8417ms
ReadWriteLock:16110ms
Collections.synchronizedMap:9604ms
事实证明在以上的配置环境JDK1.8 X86 Windows10下,高并发下这几种方式性能都相差无几,较高和较低并发下,synchronized都比ReadWriteLock来的快,基本是两倍的关系。ConcurrentHashMap作为同步的Map还是时间性能还是最高的。总之在hotspot下都是一个数量级的。
2).下面看另外一种环境
Android6.0 X86_64模拟器镜像,ART Runtime
并发量20,每个线程对Map执行读写1000000次,总耗时
ConcurrentHashMap:10841ms
synchronized:239452ms
ReadWriteLock:16450ms
Collections.synchronized:213429ms
并发量200,每个线程对Map执行读写10000次,总耗时
ConcurrentHashMap:973ms
synchronized:57047ms
ReadWriteLock:1274ms
Collections.synchronized:52746ms
**难以置信的性能差距,synchronized和Lock在Android的Art环境下确实有着一个数量级的差距,可达数十倍之多,但是在Hotspot环境下却恰恰相反,lock在多数情况下反而不如synchronized。
这里估计是Android Art虚拟机尚未对synchronized进行CAS优化,主要还是因为Android现在作为客户端操作系统,对高并发的资源竞争并无必要做优化,以上结果尚不能下定论,看来要去扒一扒Art的源码才能知道具体的原因了。**
1.关于两者的实现的比较
A).一般认为synchronized关键字的实现是源自于像信号量之类的线程同步机制,涉及到线程运行状态的切换,在高并发状态下,CPU消耗过多的时间在线程的调度上,从而造成了性能的极大浪费。然而真的如此么?B).lock实现原理则是依赖于硬件,现代处理器都支持CAS指令,所谓CAS指令简单的来说Compare And Set,CPU循环执行指令直到得到所期望的结果,换句话来说就是当变量真实值不等于当前线程调用时的值的时候(说明其他线程已经将这个值改变),就不会赋予变量新的值。这样就保证了变量在多线程环境下的安全性。
然而,现实情况是当JDK版本高于1.6的时候,synchronized已经被做了CAS的优化:具体是这样的,当执行到synchronized代码块时,先对对象头的锁标志位用lock cmpxchg的方式设置成“锁住“状态,释放锁时,在用lock cmpxchg的方式修改对象头的锁标志位为”释放“状态,写操作都立刻写回主内存。JVM会进一步对synchronized时CAS失败的那些线程进行阻塞操作(调用操作系统的信号量)(此段来摘自别处)。也就是先CAS操作,不行的话继而阻塞线程。
除此之外,系统环境,CPU架构,虚拟机环境都会影响两者的性能关系。
2.用数据说话
1).X86_64 cpu i7 4910mq @4.0ghz ,Windows10 64bit,JDK1.8 hotspot 64bit虚拟机环境测试代码
测试对某Map对象高并发下的读写线程安全测试
测试对比有synchronized,ReadWriteLock,ConcurrentHashMap,
public class MapTest { private Map<Integer,String> map = new ConcurrentHashMap<>(); private long starttime; private AtomicInteger count = new AtomicInteger(t_count); private final static int t_count = 5000; private final static int rw_count = 10000; Runnable readrun = new Runnable() { @Override public void run() { int i = rw_count; while (i > 0){ map.get(i); i--; } System.out.println("read-mapsize="+map.size()); if(count.decrementAndGet() == 0) System.out.println("time="+ (System.currentTimeMillis() - starttime +"ms")); } }; Runnable writerun = new Runnable() { @Override public void run() { int i = rw_count; while (i > 0){ map.put(i,i+""); i--; } System.out.println("write-mapsize="+map.size()); if(count.decrementAndGet() == 0) System.out.println("time="+ (System.currentTimeMillis() - starttime + "ms")); } }; public void run(){ starttime = System.currentTimeMillis(); for(int i = 0;i < t_count/2;i ++){ new Thread(writerun).start(); new Thread(readrun).start(); } } }
HashMap 用synchronized重写
public class SyncHashMap extends HashMap{ @Override public Object get(Object key) { // TODO Auto-generated method stub synchronized (this) { return super.get(key); } } @Override public synchronized Object put(Object key, Object value) { // TODO Auto-generated method stub synchronized (this) { return super.put(key, value); } } }
用读写锁实现的Map代理类,有些粗糙,没加try finally
public class SyncMapProxy<K,V> implements Map<K,V>{ private Map<K,V> origin; private ReadWriteLock lock; public SyncMapProxy(Map<K, V> origin) { this.origin = origin; lock = new ReentrantReadWriteLock(); } public static <K,V> SyncMapProxy<K,V> SyncMap(Map<K,V> map){ return new SyncMapProxy<K,V>(map); } @Override public void clear() { lock.writeLock().lock(); origin.clear(); lock.writeLock().unlock(); } @Override public boolean containsKey(Object key) { lock.readLock().lock(); boolean res = origin.containsKey(key); lock.readLock().unlock(); return res; } @Override public boolean containsValue(Object value) { lock.readLock().lock(); boolean res = origin.containsKey(value); lock.readLock().unlock(); return res; } @Override public Set<Entry<K, V>> entrySet() { lock.readLock().lock(); Set<Entry<K, V>> res = origin.entrySet(); lock.readLock().unlock(); return res; } @Override public V get(Object key) { lock.readLock().lock(); V res = origin.get(key); lock.readLock().unlock(); return res; } @Override public boolean isEmpty() { return origin.isEmpty(); } @Override public Set<K> keySet() { lock.readLock().lock(); Set<K> res = origin.keySet(); lock.readLock().unlock(); return res; } @Override public V put(K key, V value) { lock.writeLock().lock(); V v = origin.put(key, value); lock.writeLock().unlock(); return v; } @Override public void putAll(Map<? extends K, ? extends V> map) { lock.writeLock().lock(); origin.putAll(map); lock.writeLock().unlock(); } @Override public V remove(Object key) { lock.writeLock().lock(); V v = origin.remove(key); lock.writeLock().unlock(); return v; } @Override public int size() { return origin.size(); } @Override public Collection<V> values() { lock.readLock().lock(); Collection<V> res = origin.values(); lock.readLock().unlock(); return res; } }
并发量100000,每个线程对Map执行读写100次,总耗时
ConcurrentHashMap:6112ms
synchronized:6121ms
ReadWriteLock:6182ms
Collections.synchronizedMap:6175ms
并发量10000,每个线程对Map执行读写1000次,总耗时
ConcurrentHashMap:1126ms
synchronized:1145ms
ReadWriteLock:2086ms
Collections.synchronizedMap:1170ms
并发量5000,每个线程对Map执行读写10000次,总耗时
ConcurrentHashMap:1206ms
synchronized:4896ms
ReadWriteLock:8505ms
Collections.synchronizedMap:4883ms
并发量1000,每个线程对Map执行读写100000次,总耗时
ConcurrentHashMap:1748ms
synchronized:9341ms
ReadWriteLock:18720ms
Collections.synchronizedMap:8945ms
并发量100,每个线程对Map执行读写1000000次,总耗时
ConcurrentHashMap:1922ms
synchronized:8417ms
ReadWriteLock:16110ms
Collections.synchronizedMap:9604ms
事实证明在以上的配置环境JDK1.8 X86 Windows10下,高并发下这几种方式性能都相差无几,较高和较低并发下,synchronized都比ReadWriteLock来的快,基本是两倍的关系。ConcurrentHashMap作为同步的Map还是时间性能还是最高的。总之在hotspot下都是一个数量级的。
2).下面看另外一种环境
Android6.0 X86_64模拟器镜像,ART Runtime
并发量20,每个线程对Map执行读写1000000次,总耗时
ConcurrentHashMap:10841ms
synchronized:239452ms
ReadWriteLock:16450ms
Collections.synchronized:213429ms
并发量200,每个线程对Map执行读写10000次,总耗时
ConcurrentHashMap:973ms
synchronized:57047ms
ReadWriteLock:1274ms
Collections.synchronized:52746ms
**难以置信的性能差距,synchronized和Lock在Android的Art环境下确实有着一个数量级的差距,可达数十倍之多,但是在Hotspot环境下却恰恰相反,lock在多数情况下反而不如synchronized。
这里估计是Android Art虚拟机尚未对synchronized进行CAS优化,主要还是因为Android现在作为客户端操作系统,对高并发的资源竞争并无必要做优化,以上结果尚不能下定论,看来要去扒一扒Art的源码才能知道具体的原因了。**
总结
如果开发的是服务器程序,并且使用的是最新的hotspot虚拟机,synchronized和lock其实已经相差无几,其底层实现已经差不多了。但是如果你是Android开发者,使用synchronized还是需要考虑其性能差距的。相关文章推荐
- 线程同步方法、性能比较(synchronized,ReentrantLock,Atomic)
- 各种同步方法性能比较(synchronized,ReentrantLock,Atomic)
- Synchronized与ReentrantReadWriteLock性能比较
- 各种同步方法性能比较(synchronized,ReentrantLock,Atomic)
- 比较ReentrantLock和synchronized和信号量Semaphore实现的同步性能
- 各种同步方法性能比较(synchronized,ReentrantLock,Atomic)
- 各种同步方法性能比较(synchronized,ReentrantLock,Atomic)
- 各种同步方法性能比较(synchronized,ReentrantLock,Atomic)
- 各种同步方法性能比较(synchronized,ReentrantLock,Atomic)
- 比较ReentrantLock和synchronized和信号量Semaphore实现的同步性能
- synchronized与lock之间的性能比较
- 各种同步方法性能比较(synchronized,ReentrantLock,Atomic)
- 各种同步方法性能比较(synchronized,ReentrantLock,Atomic)
- 对于Synchronized、ReentrantLock、Atomic、CAS在并发下面的性能比较测试
- 一个不错的关于CPU和GPU(CUDA)的性能比较讨论话题
- 关于LinkedList和ArrayList 插入元素的性能比较疑惑,知道的请指教......
- 转载网上已篇关于linq to sq,entityframework,ado.net性能比较的文章
- 多线程下Lock、Level-Lock、Lock-Free、ReaderWriterLock、ReaderWriterLockSlim性能比较
- 关于性能比较的应用误区
- JAVA的synchronized关键字与concurrent并发包的性能比较。