在java中，除了用synchronized控制线程之外，还可以用ReentLock来控制。
synchronized简单方便，但是适用场景比较单一，局限比较多。ReentrantLock则灵活得多，具有时间锁等待、可中断锁等功能。
synchronized是JVM实现的，而Lock是代码层面实现的。
synchronized封装了线程信息，便于调试，而Lock则并不知道自己当前所在线程是哪一个。
需要注意的是，synchronized自己实现了锁的释放，所以我们执行完操作时，并不需要特意去释放锁，而Lock并没有，所以我们需要在拿到锁之后，需要在finally中执行锁的释放，如果忘记了，很容易出现问题。
另外，从性能方面来说，高并发的情况，Lock的性能好过synchronized。
简单介绍下ReentrantLock的使用
lock
尝试获取锁，如果拿不到，则一直等待，效果等同于synchronized
Lock lock = new ReentrantLock();
//创建一个重入锁
lock.lock();
//申请锁，此步骤往下都是锁住范围
try{
//拿到锁了，执行操作
}finally{
lock.unlock();
//释放锁，在执行完操作之后，手动释放锁
}
tryLock
尝试获取锁，如果拿不到，则不等待锁的释放，直接执行另一操作
Lock lock = new ReentrantLock();
if (lock.tryLock()) {
try {
// 拿到锁了，执行操作
} finally {
lock.unlock();
}
} else {
// 没拿到锁，执行操作
}
tryLock还有一个重载方法，可以传入等待时间
Lock lock = new ReentrantLock();
if (lock(5, TimeUnit.SECONDS)) {
//试图在五秒内获取锁，若获取不到，返回false
try {
// 拿到锁了，执行操作
} finally {
lock.unlock();
}
} else {
// 没拿到锁，执行操作
}
lockInterruptibly
在synchronized中，如果申请的对象锁被其他线程获取了，那么此线程会一直等待直到对象锁被释放，并且无法终止等待。那么在Lock中，lockInterruptibly方法表示，申请锁，并且可以中断申请。
public class SleepThread extends Thread{
private ReentrantLock lock;
public SleepThread(ReentrantLock lock){
this.lock=lock;
}
@Override
public void run() {
super.run();
lock.lock();
try {
sleep(100000);
//拿到锁之后睡觉
} catch (InterruptedException e) {
e.printStackTrace();
}finally{
lock.unlock();
}
}
}
public class InterruptiblyThread extends Thread{
private ReentrantLock lock;
public InterruptiblyThread(ReentrantLock lock){
this.lock=lock;
}
@Override
public void run() {
super.run();
try {
lock.lockInterruptibly();
//申请锁，此过程可以被中断
try{
}finally{
lock.unlock();
}
} catch (InterruptedException e) {
//阻塞被唤醒并被要求处理中断
//抓住或者抛出中断
System.out.println("我被中断啦");
}
}
}
public static void main(String[] args) {
ReentrantLock lock=new ReentrantLock();
Thread sleep=new SleepThread(lock);
Thread inter=new InterruptiblyThread(lock);
sleep.start();
inter.start();
inter.interrupt();
}
我被中断啦
等待与唤醒
在synchronized中，线程通信用Object的wait、notify、notifyAll方法来实现。并且对象锁的唤醒与等待，是一一对应的。这种情况下，如果我只想唤醒其中某部分线程，那就必须用到多个对象锁了。
Lock的本身实现了线程的通信方法，通过Condition的await、signal、signalAll来分别对应Object的方法。并且一个Lock可以和多个Condition关联。
举个栗子：
ReentrantLock lock = new ReentrantLock(true);
Condition empty = lock.newCondition();
Condition full = lock.newCondition();
public void lockConsume() {
// 如果队列空了，则消费者等待
if (TaskQueue.getInstance().isEmpty()) {
lock.lock();
try {
if (TaskQueue.getInstance().isEmpty()) {
// 生产者唤醒，这里只能唤醒由full.await进入等待的线程
full.signal();
try {
//消费者等待
empty.await();
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
} finally {
lock.unlock();
}
} else {
//消费
TaskQueue.getInstance().getTask();
}
}
private void lockProduce() {
// 如果队列满了，生产者暂停
if (TaskQueue.getInstance().isFull()) {
lock.lock();
try {
if (TaskQueue.getInstance().isFull()) {
// 消费者唤醒，这里同样只能唤醒由empty.await进入等待的线程
empty.signal();
try {
//生产者暂停
full.await();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
} finally {
lock.unlock();
}
} else {
//生产
Bean b = new Bean();
TaskQueue.getInstance().addTask(b);
}
}
我用两个Condition控制了多个线程，而Lock却只有一个。Condition的方法和Object并没有什么功能上的不同，只不过更加灵活。
公平性（FIFO）
大家可能注意到上面等待与唤醒中举的栗子，初始化Lock的时候和之前的栗子不同，传入了一个布尔参数，这个参数就是用来控制Lock的公平性，即是否先入先出（默认为false）。
如果Lock是公平的，那么线程执行的顺序会严格按照请求锁的顺序依次获得锁，而如果不是，则线程可能比其他先请求锁的线程先得到锁。
Condition和Lock是绑定的，所以Condition也有Lock的公平性，Condition按照await的顺序一一唤醒。这里Condition按照自己的await队列唤醒之后，添加到Lock申请锁的队列中，依然按照FIFO获得锁。
从性能上来说，公平性比非公平性的性能低，因为JVM无法根据条件调度线程，只能严格执行队列顺序。
