Java synchronized 同步锁与ReenTrantLock可重入锁的区别

一、ReenTrantLock可重入锁 与synchronized 同步锁的区别

• 锁的实现

synchronized是Java中的关键字，是依赖于JVM实现的，Java 虚拟机团队在 JDK1.6 为 synchronized 关键字进行了很多的优化，但这些优化都是在虚拟机层面实现的，并没有直接暴露给我们。而ReenTrantLock是JDK API 实现的，有直接的源码可供阅读。ReenTrantLock可以知道线程有没有成功获取到锁。这个是synchronized无法办到的。

• 可重入性

两者都是可重入锁。两者都是同一个线程没进入一次，锁的计数器都自增1，所以要等到锁的计数器下降为0时才能释放锁。

• 锁释放的区别

很明显Synchronized的使用比较方便简洁，并且由编译器去保证锁的加锁和释放，在代码执行时出现异常，JVM会自动释放锁定，因此不会导致死锁现象发生。而ReenTrantLock需要手工声明来加锁和释放锁，为了避免忘记手工释放锁造成死锁，就必须将 unLock()放到finally{} 中。

• 性能的区别

相比 synchronized，ReentrantLock 增加了一些高级功能。主要有：① 等待可中断；② 可实现公平锁；③ 可实现选择性通知（锁可以绑定多个条件）：

1）ReentrantLock 提供了一种能够中断等待锁线程的机制，通过 lock.lockInterruptibly() 来实现这个机制，也就是说正在等待的线程可以选择放弃等待，改为处理其他事情；

2）ReentrantLock 可以指定是公平锁还是非公平，而 synchronized 只能是非公平锁。所谓的公平锁，就是先等待的线程最先获得锁；ReentrantLock 默认是非公平的，可以通过 ReentrantLock 类的 ReentrantLock(boolean fair) 构造方法来制定是否是公平的；

3）synchronized 关键字结合 wait() 和 notify()/notifyAll() 方法使用，可以实现等待/通知机制，ReentrantLock 类则需要借助于 Condition 接口与 newCondition() 方法。

在性能上来说，如果竞争资源不激烈，两者的性能是差不多的，而当竞争资源非常激烈时（即有大量线程同时竞争），此时Lock的性能要远远优于synchronized。所以说，在具体使用时要根据适当情况选择。

 

举个例子：当有多个线程读写文件时，读操作和写操作会发生冲突现象，写操作和写操作会发生冲突现象，但是读操作和读操作不会发生冲突现象。但是采用synchronized关键字来实现同步的话，就会导致一个问题：

如果多个线程都只是进行读操作，所以当一个线程在进行读操作时，其他线程只能等待无法进行读操作。

因此就需要一种机制来使得多个线程都只是进行读操作时，线程之间不会发生冲突，通过Lock就可以办到。

 

二、ReentrantLock获取锁的三种方式

ReentrantLock，意思是“可重入锁”,即：自己可以再次获取自己的内部锁。比如，一个线程获得了某个对象的锁，此时这个对象锁还没有释放，当其再次想要获取这个对象的锁时，还可以再获取的