Lcok锁

1.Lock (lock的源码)

public interface Lock {
    void lock();
void lockInterruptibly() throws InterruptedException;
    boolean tryLock();
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
    void unlock();
Condition newCondition();
}

lock得在try{}catch{}中使用，必须主动去释放锁，并且在发生异常的时候也不会去主动释放锁

tryLock的方法是有返回值的，它表示用来尝试获取锁，如果获取成功，则返回true，如果获取失败则返回false。也就是说方法方法无论如何都会有返回值，在拿不到锁的时候也不会一直等待

tryLock(long time,TimeUnit unit)区别于上面的方法是，在拿不到锁会等待一会，如果还是拿不到就会返回false

lockInterruptibly这个方法比较特殊，但沟通过这个方法获取锁时，如果线程正在等待获取锁，则这个线程能够响应中断，即中断的等待状态，也就是说，当两个线程同时通过lock.lockInterruptibly想获取某个锁时，假若此时线程A获取到了锁，而线程B只有在等待，那么对线程B调用threadB.Interrup方法能够中断线程B的等待过程

注意：当一个线程获取了锁之后，是不会被**interrupt()方法中断的。因为本身在前面的文章中讲过单独调用interrupt()**方法不能中断正在运行过程中的线程，只能中断阻塞过程中的线程

因此当通过lockInterruptibly()方法获取某个锁时，如果不能获取到，只有进行等待的情况下，是可以响应中断的。
而用synchronized修饰的话，当一个线程处于等待某个锁的状态，是无法被中断的，只有一直等待下去。

ReentrantLock（可重入锁）

因为这个是局部变量，每一个线程都是独立运行的，所有不受影响，改的话就是将红的地方放外面

Lock和synchronized的选择：

1）Lock是一个接口，而synchronized是Java中的关键字，synchronized是内置的语言实现；
2）synchronized在发生异常时，会自动释放线程占有的锁，因此不会导致死锁现象发生；而Lock在发生异常时，如果没有主动通过unLock()去释放锁，则很可能造成死锁现象，因此使用Lock时需要在finally块中释放锁；
3）Lock可以让等待锁的线程响应中断，而synchronized却不行，使用synchronized时，等待的线程会一直等待下去，不能够响应中断；
4）通过Lock可以知道有没有成功获取锁，而synchronized却无法办到。 5）Lock可以提高多个线程进行读操作的效率。

1.可重入锁

可重入性在我看来实际上表明了锁的分配机制：基于线程的分配，而不是基于方法调用的分配。举个简单的例子，当一个线程执行到某个synchronized方法时，比如说method1，而在method1中会调用另外一个synchronized方法method2，此时线程不必重新去申请锁，而是可以直接执行方法method2。

2.可中断锁

在Java中，synchronized就不是可中断锁，而Lock是可中断锁
----lockInterruptibly()的用法时已经体现了Lock的可中断性

3.公平锁

公平锁即尽量以请求锁的顺序来获取锁。比如同是有多个线程在等待一个锁，当这个锁被释放时，等待时间最久的线程（最先请求的线程）会获得该所，这种就是公平锁。
非公平锁即无法保证锁的获取是按照请求锁的顺序进行的。这样就可能导致某个或者一些线程永远获取不到锁
—synchronized就是非公平锁
—而对于ReentrantLock和ReentrantReadWriteLock，它默认情况下是非公平锁，但是可以设置为公平锁

4.读写锁

读写锁将对一个资源（比如文件）的访问分成了2个锁，一个读锁和一个写锁。 正因为有了读写锁，才使得多个线程之间的读操作不会发生冲突。
ReadWriteLock就是读写锁，它是一个接口，ReentrantReadWriteLock实现了这个接口。
可以通过readLock()获取读锁，通过writeLock()获取写锁。