详谈Lock与synchronized 的区别
投稿：jingxian
字体：[ ] 类型：转载 时间：
下面小编就为大家带来一篇详谈Lock与synchronized 的区别。小编觉得挺不错的，现在就分享给大家，也给大家做个参考。一起跟随小编过来看看吧
1、lock是可中断锁，而synchronized 不是可中断锁
线程A和B都要获取对象O的锁定，假设A获取了对象O锁，B将等待A释放对O的锁定，
如果使用 synchronized ，如果A不释放，B将一直等下去，不能被中断
如果 使用ReentrantLock，如果A不释放，可以使B在等待了足够长的时间以后，中断等待，而干别的事情
ReentrantLock获取锁定与三种方式：
a)& lock()，如果获取了锁立即返回，如果别的线程持有锁，当前线程则一直处于休眠状态，直到获取锁
b) tryLock()，如果获取了锁立即返回true，如果别的线程正持有锁，立即返回false；
c) tryLock(long timeout,TimeUnit unit)，如果获取了锁定立即返回true，如果别的线程正持有锁，会等待参数给定的时间，在等待的过程中，如果获取了锁定，就返回true，如果等待超时，返回false；
d) lockInterruptibly：如果获取了锁定立即返回，如果没有获取锁定，当前线程处于休眠状态，直到或者锁定，或者当前线程被别的线程中断
2、synchronized是在JVM层面上实现的，lock是通过代码实现的，JVM会自动释放锁定（代码执行完成或者出现异常），但是使用Lock则不行，要保证锁定一定会被释放，就必须将unLock()放到finally{}中。
3、在资源竞争不是很激烈的情况下，Synchronized的性能要优于ReetrantLock，但是在资源竞争很激烈的情况下，Synchronized的性能会下降几十倍，但是ReetrantLock的性能能维持常态；
以上这篇详谈Lock与synchronized 的区别就是小编分享给大家的全部内容了，希望能给大家一个参考，也希望大家多多支持脚本之家。
您可能感兴趣的文章:
大家感兴趣的内容
12345678910
最近更新的内容
常用在线小工具3172人阅读
Android（36）
记得当初看教程的时候大家都说lock性能比好不少，最近需要自己设计一个缓存终于要自己尝试一番了。
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
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() {
public void run() {
int i = rw_
while (i & 0){
map.get(i);
System.out.println("read-mapsize="+map.size());
if(count.decrementAndGet() == 0)
System.out.println("time="+ (System.currentTimeMillis() - starttime +"ms"));
Runnable writerun = new Runnable() {
public void run() {
int i = rw_
while (i & 0){
map.put(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{
public Object get(Object key) {
synchronized (this) {
return super.get(key);
public synchronized Object put(Object key, Object value) {
synchronized (this) {
return super.put(key, value);
用读写锁实现的Map代理类，有些粗糙，没加try finally
public class SyncMapProxy&K,V& implements Map&K,V&{
private Map&K,V&
private ReadWriteLock lock;
public SyncMapProxy(Map&K, V& origin) {
this.origin =
lock = new ReentrantReadWriteLock();
public static
&K,V& SyncMapProxy&K,V& SyncMap(Map&K,V& map){
return new SyncMapProxy&K,V&(map);
public void clear() {
lock.writeLock().lock();
origin.clear();
lock.writeLock().unlock();
public boolean containsKey(Object key) {
lock.readLock().lock();
boolean res = origin.containsKey(key);
lock.readLock().unlock();
public boolean containsValue(Object value) {
lock.readLock().lock();
boolean res = origin.containsKey(value);
lock.readLock().unlock();
public Set&Entry&K, V&& entrySet() {
lock.readLock().lock();
Set&Entry&K, V&& res = origin.entrySet();
lock.readLock().unlock();
public V get(Object key) {
lock.readLock().lock();
V res = origin.get(key);
lock.readLock().unlock();
public boolean isEmpty() {
return origin.isEmpty();
public Set&K& keySet() {
lock.readLock().lock();
Set&K& res = origin.keySet();
lock.readLock().unlock();
public V put(K key, V value) {
lock.writeLock().lock();
V v = origin.put(key, value);
lock.writeLock().unlock();
public void putAll(Map&? extends K, ? extends V& map) {
lock.writeLock().lock();
origin.putAll(map);
lock.writeLock().unlock();
public V remove(Object key) {
lock.writeLock().lock();
V v = origin.remove(key);
lock.writeLock().unlock();
public int size() {
return origin.size();
public Collection&V& values() {
lock.readLock().lock();
Collection&V& res = origin.values();
lock.readLock().unlock();
并发量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还是需要考虑其性能差距的。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：59060次
积分：1069
积分：1069
排名：千里之外
原创：44篇
评论：25条
文章：39篇
阅读：54710
(1)(8)(1)(1)(2)(10)(5)(5)(11)(1)
(window.slotbydup = window.slotbydup || []).push({
id: '4740887',
container: s,
size: '250,250',
display: 'inlay-fix'关于synchronized与lock的性能比较
记得当初看教程的时候大家都说lock性能比好不少，最近需要自己设计一个缓存终于要自己尝试一番了。
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 map = new ConcurrentHashMap&&();
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() {
public void run() {
int i = rw_
while (i & 0){
map.get(i);
System.out.println(&read-mapsize=&+map.size());
if(count.decrementAndGet() == 0)
System.out.println(&time=&+ (System.currentTimeMillis() - starttime +&ms&));
Runnable writerun = new Runnable() {
public void run() {
int i = rw_
while (i & 0){
map.put(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{
public Object get(Object key) {
// TODO Auto-generated method stub
synchronized (this) {
return super.get(key);
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 implements Map{
private Map
private ReadWriteL
public SyncMapProxy(Map origin) {
this.origin =
lock = new ReentrantReadWriteLock();
public static
SyncMapProxy SyncMap(Map map){
return new SyncMapProxy(map);
public void clear() {
lock.writeLock().lock();
origin.clear();
lock.writeLock().unlock();
public boolean containsKey(Object key) {
lock.readLock().lock();
boolean res = origin.containsKey(key);
lock.readLock().unlock();
public boolean containsValue(Object value) {
lock.readLock().lock();
boolean res = origin.containsKey(value);
lock.readLock().unlock();
public Set<entry& entrySet() {
lock.readLock().lock();
Set<entry& res = origin.entrySet();
lock.readLock().unlock();
public V get(Object key) {
lock.readLock().lock();
V res = origin.get(key);
lock.readLock().unlock();
public boolean isEmpty() {
return origin.isEmpty();
public Set keySet() {
lock.readLock().lock();
Set res = origin.keySet();
lock.readLock().unlock();
public V put(K key, V value) {
lock.writeLock().lock();
V v = origin.put(key, value);
lock.writeLock().unlock();
public void putAll(Map map) {
lock.writeLock().lock();
origin.putAll(map);
lock.writeLock().unlock();
public V remove(Object key) {
lock.writeLock().lock();
V v = origin.remove(key);
lock.writeLock().unlock();
public int size() {
return origin.size();
public Collection values() {
lock.readLock().lock();
Collection res = origin.values();
lock.readLock().unlock();
</entry</entry
并发量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).下面看另外一种环境
6.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还是需要考虑其性能差距的。Java锁Synchronized和Lock锁比较
对于Lock与synchronized的区别
1.Lock能够完成synchronized所实现的所有功能，并且提供了多样化的同步，比如有时间限制的同步，可以被Interrupt的同步（synchronized的同步是不能Interrupt的）等。
如果使用 synchronized
，如果A不释放，B将一直等下去，不能被中断。
如果使用ReentrantLock，如果A不释放，可以使B在等待了足够长的时间以后，中断等待，而干别的事情。
2、synchronized是在JVM层面上实现的，不但可以通过一些监控工具监控synchronized的锁定，而且在代码执行时出现异常，JVM会自动释放锁定。但Lock不能，只能手动释放，并且在finally从句中unLock()释放。
3、性能：在jdk1.5中Synchronized是使用的独占悲观锁，资源竞争不激烈的情况下synchronized性能略高，资源竞争激烈 的情况下性能要远低于Lock。jdk1.6以后synchronized和lock一样都是使用CAS乐观锁操作，所以性能差不多，对于具体使用哪一个 要看具体的系统应用需要，Synchronized相对简单易用，若需要精细的灵活控制则可以考虑选择lock。
void lock(); ---获取锁。执行此方法时，如果锁处于空闲状态，当前线程将获取到锁。相反，如果锁已经被其他线程持有，将禁用当前线程并处于休眠状态，直到当前线程获取到锁。
void unlock(); ----执行此方法时，当前线程将释放持有的锁。锁只能由持有者释放，如果线程并不持有锁，却执行该方法，可能导致异常的发生。
boolean tryLock(); ----如果锁可用, 则获取锁, 并立即返回true, 否则返回false. 该方法和lock()的 区别在于, tryLock()只是"试图"获取锁,
如果锁不可用,
不会导致当前线程被禁用,
当前线程仍然继续往下执行代码.
而lock()方法则是一定要获取到锁, 如果锁不可用,
就一直等待,
在未获得锁之前,当前线程并不继续向下执行. 通常采用如下的代码形式调用tryLock()方法:
&void lockInterruptibly() throws
InterruptedE ----如果当前线程未被中断且可用，则获取锁并立即返回。
如果锁不可用，将禁用当前线程，并且在发生以下两种情况之一以前，该线程将一直处于休眠状态：
锁由当前线程获得；或者
其他某个线程中断当前线程，并且支持对锁获取的中断
Synchronized内部锁，可以在线程转储时，记录哪些调用框架获得了哪些锁，并能够识别发生死锁的线程。但jvm不知道哪些线程持有重入锁。这个问题在JDK6中得到解决。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。}