synchronized和ReenTrantLock有什么区别和联系？
synchronized是Java内建的同步机制，它提供了互斥的语义和可见性，当一个线程已经获取当前的锁时，其他试图获取的线程只能等待或者阻塞在那里。ReentrantLock和synchronized类似，都是可重入锁，但是ReentrantLock内部有提供了许多方法，使用起来相对灵活，比如需要通过.lock()实现加锁，通过.unlock()释放锁，不然会一直上锁。
synchronized和ReenTrantLock都是可重入锁
可重入锁：自己可以再次获取自己的内部锁就叫可重入锁。比如线程A获得了对象B的锁，此时这个B对象的锁还未释放，当线程A想要再次获取这个对象锁的时候，还是可以获取的，如果不可锁重入的话，就会造成死锁。同一个线程每次获取锁，锁计数器都自增1，所以要等到锁的计数器下降为0时才能释放锁。
>>>>>区别<<<<<
1）synchronized依赖于Jvm而ReenTrantLock依赖于API(ReenTrantLock是JDK层面实现的,需要lock()和unlock()配合try/finally语句块来完成）
2）ReenTrantLock比synchronized多了以下高级功能：
①等待可中断；
②可实现公平锁；
③可实现选择性通知（锁可以绑定多个条件）
| SynChronized | ReentrantLock（实现了 Lock接口） | |
| 释义 | 原生语法层面的互斥（Jvm实现） | 提供的API层面的互斥锁类 |
| 实现 | 通过JVM加锁解锁 | API层面的加解锁(手动释放) |
| 代码 | synchronized修饰的方法或代码块执行完之后，会自动释放 | ReentrantLock则必须手动释放锁（.unlock()），否则会导致死锁现象 |
| 灵活性 | 锁范围是synchronized修饰部分（方法或者代码块） | 可以跨方法（lock()调用），灵活性更大 |
| 等待可中断 | 不可中断，除非抛异常，释放锁方式有： 1）代码正常执行结束，正常释放 2）抛异常，由JVM退出等待 |
持有锁的线程长期不释放的，正在等待的线程可以主动选择放弃等待： 1）设置超时方法 tryLock(long timeout, TimeUnit unit)，超时则放弃等待 2）lockInterruptibly()放代码块中，调用interrupt()方法可中断 |
| 是否公平锁 | 非公平锁（先到先得） | 默认公平锁，可通过设置boolean值，true为公平锁，false为非公平锁 |
| 条件 | 通过多次newCondition可以获得多个Condition对象，可以简单的实现比较复杂的线程同步的功能 | |
| 高级功能 | getHoldCount() getQueueLength() isFair() isHeldByCurrentThread() isLocked() |
|
| 便利性 | 使用方便，由Jvm自动进行加锁和释放 | 手工进行加锁和锁释放 |
| 适用情况 | 资源竞争不是很激烈的情况下，synchronized比较合适，因为Jvm会尽可能优化synchronize，而且代码可读性好 | ReentrantLock提供了多样化的同步，比如有时间限制的同步，所以在资源竞争很激烈的情况下，可以考虑使用ReentrantLock |