本文已参与「新人创作礼」活动，一起开启掘金创作之路
首先假如说synchronized能满足所有要求，而且性能还好，那么还会出现ReentrantLock么，显然是不会的，ReentrantLock是JDK1.5后JUC并发包下的一个类，这时候的synchronized还没进行优化，所以性能很差，ReentrantLock的出现就是为了解决synchronized的一些诟病，ReentrantLock的所有权在使用者手上，而synchronized呢只有wait和notify能使用
谈谈synchronized与ReentrantLock的区别
如果问的是和Lock锁的区别，那么就要先引入ReentrantLock。Lock是个接口，我们一般都使用它的实现类ReentrantLock
- 底层实现上来说
-
- synchronized 是JVM层面的锁，是Java关键字，是通过对象内部的一个叫做监视器锁（monitor）来实现的,对象只有在同步块或同步方法中才能调用wait/notify方法。锁的实现涉及到了锁的升级，具体为无锁，偏向锁、轻量级锁（自旋锁）和重量级锁，重量级锁是系统锁，需要去OS申请，需要从用户态切换到内核态，代价高，效率低
- ReentrantLock 是jdk1.5以后提供的J.U.C包下的一个类，锁的实现是通过CAS的自旋机制保证线程操作的原子性和通过volatile关键字保证数据的可见性来实现的
- synchronized 不需要用户去手动释放锁，synchronized 代码执行完后系统会自动让线程释放对锁的占用； ReentrantLock则需要用户去手动释放锁，如果没有手动释放锁，就可能导致死锁现象。一般通过lock()和unlock()方法配合try/finally语句块来完成，使用释放更加灵活。
- synchronized是不可中断类型的锁，除非加锁的代码中出现异常或正常执行完成； ReentrantLock则可以中断，可通过trylock(long timeout,TimeUnit unit)设置超时方法，设定时间内拿不到锁自动放弃。或者调用lockInterruptibly方法当线程调用interrupt的时候进行响应。
lockInterruptibly()方法能够中断等待获取锁的线程。当两个线程同时通过lock.lockInterruptibly()获取某个锁时，假若此时线程A获取到了锁，而线程B只有等待，那么对线程B调用threadB.interrupt()方法能够中断线程B的等待过程。
- synchronized为非公平锁 ReentrantLock则即可以选公平锁也可以选非公平锁，通过构造方法new ReentrantLock时传入boolean值进行选择，为空默认false非公平锁，true为公平锁。
- synchronzied锁的是对象，锁是保存在对象头里面的（存在锁对象的对象头的Mark Word中），根据对象头数据来标识是否有线程获得锁/争抢锁；ReentrantLock锁的是线程，根据进入的线程和int类型的state标识锁的获得/争抢。
- synchronized不能绑定condition； ReentrantLock通过绑定Condition结合await()/singal()方法实现线程的精确唤醒，而不是像synchronized通过Object类的wait()/notify()/notifyAll()方法要么随机唤醒一个线程要么唤醒全部线程。
-
- condition本质就是不同的等待队列
