reentrantlock，synchronized区别 、介绍

synchronized在jdk1.6之前是一个重量级（cpu要从内核态切换到用户态）的锁，线程交替执行时，解决线程安全问题，需要调用操作系统中的函数；jdk1.7之后就尽量使得同步的处理在jvm中解决。

reentrantlock就是围绕着自旋，cas，part-unpart实现的，

加锁过程，根据是否是公平锁调用不同的方法去加锁，先判断锁是不是自由状态，判断自己需不需要排队，不需要排队就调用cas尝试加锁，加锁成功就将当前线程设置为持有这把锁的线程，返回true,后面都是正常返回，就拿到了锁，继续执行下一行代码。

reentrantlock在单个线程，或者线程交替执行时它与队列无关，在jdk级别就解决了同步问题

jvm中的一个个线程就是对应着操作系统中的线程

doug lea 此人写出的reentrantlock锁，他开发了java.util.concurrent这个包

reentrantlock锁，jdk1.6后加的新特性。目的是嫌弃sync的重，代替sync

reentrantlock是公平锁还是非公平锁：

若实例化时使用默认构造方法是非公平锁。

若加上参数true就可以将其变为公平锁

ReentrantLock和synchronized的相同点。

• 1.ReentrantLock和synchronized都是独占锁,只允许线程互斥的访问临界区。但是实现上两者不同:synchronized加锁解锁的过程是隐式的,用户不用手动操作,优点是操作简单，但显得不够灵活。一般并发场景使用synchronized的就够了；ReentrantLock需要手动加锁和解锁,且解锁的操作尽量要放在finally代码块中,保证线程正确释放锁。ReentrantLock操作较为复杂，但是因为可以手动控制加锁和解锁过程,在复杂的并发场景中能派上用场。

• 2.ReentrantLock和synchronized都是可重入的。synchronized因为可重入因此可以放在被递归执行的方法上,且不用担心线程最后能否正确释放锁；而ReentrantLock在重入时要却确保重复获取锁的次数必须和重复释放锁的次数一样，否则可能导致其他线程无法获得该锁。

ReentrantLock相比synchronized的额外功能

.1 ReentrantLock可以实现公平锁。

公平锁是指当锁可用时,在锁上等待时间最长的线程将获得锁的使用权。而非公平锁则随机分配这种使用权。和synchronized一样，默认的ReentrantLock实现是非公平锁,因为相比公平锁，非公平锁性能更好。当然公平锁能防止饥饿,某些情况下也很有用。在创建ReentrantLock的时候通过传进参数true创建公平锁,如果传入的是false或没传参数则创建的是非公平锁

线程会重复获取锁。如果申请获取锁的线程足够多,那么可能会造成某些线程长时间得不到锁。这就是非公平锁的“饥饿”问题。

• 公平锁和非公平锁该如何选择 大部分情况下我们使用非公平锁， 非公平性锁虽然可能造成线程“饥饿”，但极少的线程切换，保证了其更大的吞吐量。 其性能比公平锁好很多。但是公平锁能够避免线程饥饿，某些情况下也很有用。

2 .ReentrantLock可响应中断

当使用synchronized实现锁时,阻塞在锁上的线程除非获得锁否则将一直等待下去，也就是说这种无限等待获取锁的行为无法被中断。而ReentrantLock给我们提供了一个可以响应中断的获取锁的方法lockInterruptibly()。该方法可以用来解决死锁问题。

3. 获取锁时限时等待

ReentrantLock还给我们提供了获取锁限时等待的方法tryLock(),可以选择传入时间参数,表示等待指定的时间,无参则表示立即返回锁申请的结果:true表示获取锁成功,false表示获取锁失败。我们可以使用该方法配合失败重试机制来更好的解决死锁问题。

4. 结合Condition实现等待通知机制

使用synchronized结合Object上的wait和notify方法可以实现线程间的等待通知机制。ReentrantLock结合Condition接口同样可以实现这个功能。而且相比前者使用起来更清晰也更简单。

 总结

ReentrantLock是可重入的独占锁。比起synchronized功能更加丰富，支持公平锁实现，支持中断响应以及限时等待等等。可以配合一个或多个Condition条件方便的实现等待通知机制。