Lock锁及获取锁的四种方法

为什么使用LOCK？

传统的Synchronized锁有非常多的缺点：

1. 锁的唤醒和阻塞代价较高，线程的阻塞和唤醒，操作系统需要在用户态与内核态之间切换，会浪费较多的时间，降低运行的性能。
2. synchronized关键字是不可中断的，这也就意味着一个等待的线程如果不能获取到锁将会一直等待，而不能再去做其他的事了。
3. 无法得知是否得到锁，既然无法得知，我们也就很不容易进行改进。

LOCK锁

Lock锁是java.util.concurrent.locks中的一个接口。Lock实现提供比使用synchronized方法和语句可以获得的更广泛的锁定操作。 它们允许更灵活的结构化，可能具有完全不同的属性，并且可以支持多个相关联的对象Condition 。

---

官方文档：

使用synchronized方法或语句提供对与每个对象相关联的隐式监视器锁的访问，但是强制所有锁获取和释放以块结构的方式发生：当获取多个锁时，它们必须以相反的顺序被释放，并且所有的锁都必须被释放在与它们相同的词汇范围内。

虽然synchronized方法和语句的范围机制使得使用监视器锁更容易编程，并且有助于避免涉及锁的许多常见编程错误，但是有时您需要以更灵活的方式处理锁。 例如，用于遍历并发访问的数据结构的一些算法需要使用“手动”或“链锁定”：您获取节点A的锁定，然后获取节点B，然后释放A并获取C，然后释放B并获得D等。 所述的实施方式中Lock接口通过允许获得并在不同范围释放的锁，并允许获得并以任何顺序释放多个锁使得能够使用这样的技术。

随着这种增加的灵活性，额外的责任。 没有块结构化锁定会删除使用synchronized方法和语句发生的锁的自动释放。

种种的缺点使得synchronized的使用收到了极大的限制，所以Lock它出现了。

---

LOCK锁的上锁与解锁

LOCK中声明的所有方法：

Modifier and Type	Method	Description
void	lock()	获得锁
void	lockInterruptibly()	获取锁定，除非当前线程是 interrupted 。
Condition	newCondition()	返回一个新Condition绑定到该实例Lock实例。
boolean	tryLock()	只有在调用时才可以获得锁。
boolean	tryLock(long time, TimeUnit unit)	如果在给定的等待时间内是空闲的，并且当前的线程尚未得到 interrupted，则获取该锁。
void	unlock()	释放锁。

lock()、tryLock()、tryLock(long time, TimeUnit unit) throws InterruptedException和 lockInterruptibly() throws InterruptedException这四种方法是用来获取锁的四种方法，unLock()方法是用来释放锁的。Lock中声明了四个方法来获取锁，那么这四个方法有何区别呢？

1）lock()：lock()方法是平常使用得最多的一个方法，就是用来获取锁。如果锁已被其他线程获取，则进行等待。采用Lock，必须主动去释放锁，并且在发生异常时，不会自动释放锁。因此一般来说，使用Lock必须在try{}catch{}块中进行，并且将释放锁的操作放在finally块中进行，以保证锁一定被被释放，防止死锁的发生。

2）tryLock()：如果可用，则获取锁定，并立即返回值为true 。 如果锁不可用，则此方法将立即返回值为false 。此用法可确保锁定已被取消，如果未获取锁定，则不会尝试解锁。


经典用法：

Lock lock = ...;
  if(lock.tryLock())
   {
       try {
       //    manipulate protected state 操作受保护的状态
       } finally {
           lock.unlock();//解锁
       }
   } else{
       //perform alternative actions 执行替代操作
   }

3）tryLock(long time, TimeUnit unit) throws InterruptedException:tryLock(long time, TimeUnit unit)方法和tryLock()方法是类似的，只不过区别在于这个方法在拿不到锁时会等待一定的时间，在时间期限之内如果还拿不到锁，就返回false。如果如果一开始拿到锁或者在等待期间内拿到了锁，则返回true。

4）lockInterruptibly() throws InterruptedException：lockInterruptibly()方法比较特殊，当通过这个方法去获取锁时，如果线程正在等待获取锁，则这个线程能够响应中断，即中断线程的等待状态。也就说，当两个线程同时通过lock.lockInterruptibly()想获取某个锁时，假若此时线程A获取到了锁，而线程B只有在等待，那么对线程B调用threadB.interrupt()方法能够中断线程B的等待过程。由于lockInterruptibly()的声明中抛出了异常，所以lock.lockInterruptibly()必须放在try块中或者在调用lockInterruptibly()的方法外声明抛出InterruptedException。因此lockInterruptibly()一般的使用形式如下：

Lock lock = ...;
   lock.lockInterruptibly();
   try{
       //    manipulate protected state 操作受保护的状态
   } finally{
       lock.unlock();
   }

注意，当一个线程获取了锁之后，是不会被interrupt()方法中断的。因为单独调用interrupt()方法不能中断正在运行过程中的线程，只能中断阻塞过程中的线程。因此当通过lockInterruptibly()方法获取某个锁时，如果不能获取到，只有进行等待的情况下，是可以响应中断的。而用synchronized修饰的话，当一个线程处于等待某个锁的状态，是无法被中断的，只有一直等待下去。

5）newCondition():获取等待通知组件，该组件和当前的锁绑定，当前线程只有获得了锁，才能调用该组件的wait()方法，而调用后，当前线程将释放锁。

若有错误，请批评指正。

下一篇更新LOCK的实现类：ReentrantReadWriteLock和ReentrantLock，有兴趣的小伙伴可以点个关注不迷路哦。