多线程学习------05Lock显示锁

在 JDK5 中 增 加 了 Lock 锁 接 口 , 有 ReentrantLock 实 现 类,ReentrantLock 锁称为可重入锁, 它功能比 synchronized 多

Lock 有 4 种加锁方法，其中 lock 是最基础的。Lock 获取锁和释放锁都是显式的，不像 synchronized 是隐式的。所以 synchronized 会在抛异常时自动释放锁，而 Lock 只能是主动释放，加解锁都必须有显式的代码控制

一、 锁的可重入性

锁的可重入是指,当一个线程获得一个对象锁后,再次请求该对象锁时，还是可以获得该对象的锁的.

synchronized关键字所使用的锁也是可重入的

二、 ReentrantLock（Lock锁接口的实现类）

1、ReentrantLock 的基本使用

**调用 lock()方法获得锁, 调用 unlock()释放锁 **

2、 ReentrantLock 锁有可重入性

synchronized关键字所使用的锁也是可重入的

3、解决死锁

首先你得了解为什么Lock要提供tryLock和tryInterruptibly方法因为它要破坏死锁中的“不可抢占条件”。synchronized没办法破坏“不可抢占条件”，synchronized申请资源的时候，如果申请不到，线程直接进入阻塞状态，无法释放已经占有的锁。但我们希望的是：如果占用部分资源的线程进一步申请其他资源时，如果申请不到，可以主动释放它占有的资源，这样不可抢占条件被破坏掉了。

所以，Lock提供了三种方法，均可以破坏不可抢占条件。这也是为什么有了synchronized还要搞一个Lock的原因之一。

lock () 方法是阻塞加锁，加不到锁就会验证阻塞，而且有个缺点就是它不能被中断，所以一旦陷入死锁，lock () 就会陷入永久等待

tryLock：表示尝试加锁，立即返回，获得锁返回true，没获得锁返回false，不会阻塞线程；当它获取不到锁的时候，就会释放自己的资源，让其他线程得到资源从而完成任务释放锁，此时在尝试加锁；

我们通过返回值的不同执行不同的代码，并且可以让他自旋，获取不到则隔段时间重试成为自旋锁

tryLock避免死锁的产生:

想象这样一个场景：比如有两个线程同时调用以下这个方法，传入的 lock1 和 lock2 恰好是相反的。如果第一个线程获取了 lock1，第二个线程获取了 lock2，两个线程都需要获取对方的锁才能工作。如果用 lock 这就很容易陷入死锁

这个时候 tryLock 就发挥作用了：其中一个线程尝试获取锁 lock1，获取不到，则隔段时间重试（这样做的目的在于等另一个获取到锁的线程在这段时间内完成任务，释放锁）。获取到了，则继续获取 lock2 ，获取到就操作共享资源，获取不到则释放 lock1，继续进入重试。

tryLock(long time, TimeUint unit)： 一段时间内没有获取锁，不是进入阻塞状态，而是返回一个异常；从而释放锁资源

lockInterruptibly：在锁上等待，直到获取锁，但是会响应中断，这个方法优先考虑响应中断，而不是响应锁的普通获取或重入获取。 中断会抛出一个中断的异常，从而释放锁

同步过程中线程出现异常, 会自动释放锁对象.并不会影响其他线程的执行

4、newCondition()方法

• 关键字 synchronized 与 wait()/notify()这两个方法一起使用可以实现等待/通知模式. Lock 锁的 newContition()方法返回 Condition 对象,Condition 类也可以实现等待/通知模式.

• 使用 notify()通知时, JVM 会随机唤醒某个等待的线程. 使用 Condition 类可以进行选择性通知. Condition 比较常用的两个方法:

• await()会使当前线程等待,同时会释放锁,
• 当其他线程调用 signal() 时,线程会重新获得锁并继续执行. signal()用于唤醒一个等待的线程

注意:

• 在调用 Condition 的 await()/signal()方法前,也需要线程持有相关的 Lock 锁. 调用 await()后线程会释放这个锁,在 singal()调用后会从当前 Condition 对象的等待队列中,唤醒 一个线程,唤醒的线程尝试获得锁, 一旦获得锁成功就继续执行

5、多个 Condition 实现通知部分线程, 使用更灵活

6、公平锁与非公平锁（底层：AQS排队）

• 大多数情况下,锁的申请都是非公平的. 如果线程1与线程2都在请求锁 A, 当锁 A 可用时, 系统只是会从阻塞队列中随机的选择一个线程, 不能保证其公平性
• 公平的锁会按照时间先后顺序,保证先到先得, 公平锁的这一特点不会出现线程饥饿现象.
• synchronized 内部锁就是非公平的. ReentrantLock 重入锁提供了一个构造方法**:ReentrantLock(boolean fair)** ,当在创建锁对象时实参传递 true 可以把该锁设置为公平锁.
• 公平锁看起来很公平,但是要实现公平锁必须要求系统维护一个有序队列,公平锁的实现成本较高,性能也低. 因此默认情况下锁是非公平的. 不是特别的需求,一般不使用公 平锁.

/*
1)如果是非公平锁, 系统倾向于让一个线程再次获得已经持有的锁, 这种分配策略是高效的,非公平的
2)如果是公平锁, 多个线程不会发生同一个线程连续多次获得锁的可能,保证了公平性
*/

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RZw31YBK-1658755744972)(resources/1.png)]

三、 ReentrantLock（它很重点）

• synchronized内部锁与ReentrantLock,锁都是独占锁(排它锁),同一时间只允许一个线程执行同步代码块,可以保证线程的安全性,但是执行效率低.

• ReentrantReadWriteLock读写锁是一种改进的排他锁,也可以称作共享/排他锁.允许多个线程同时读取共享数据,但是一次只允许一个线程对共享数据进行更新!

• 读写锁通过读锁与写锁来完成读写操作. 线程在读取共享数据前 必须先持有读锁,该读锁可以同时被多个线程持有,即它是共享的.线程在修改共享数据前必须先持有写锁,写锁是排他的, 一个线程持有写锁时其他线程无法获得相应的锁

• 读锁只是在读线程之间共享,任何一个线程持有读锁时,其他线程都无法获得写锁, 保证线程在读取数据期间没有其他线程对数据进行更新,使得读线程能够读到数据的最新值,保证在读数据期间共享变量不被修改

	获得条件	排他性	作用
读锁	写锁未被任意线程持有	对读线程是共享的, 对写线程是排他的	允许多个读线程可以同时读 取共享数据,保证在读共享数 据时,没有其他线程对共享数 据进行修改
写锁	该写锁未被其他线程持有,并且相应的读锁也未被其他线程持有	对读线程或者写线程都是排他的	保证写线程以独占的方式修 改共享数据

• 读写锁允许读读共享, 读写互斥,写写互斥

• 读写锁的特点如下：

  1）如果有其它线程读数据，则允许其它线程执行读操作，但不允许写操作。

  2）如果有其它线程写数据，则其它线程都不允许读、写操作。

  读写锁分为读锁和写锁，规则如下：

  1）如果某线程申请了读锁，其它线程可以再申请读锁，但不能申请写锁。

  2）如果某线程申请了写锁，其它线程不能申请读锁，也不能申请写锁。

• 在java.util.concurrent.locks包中定义了ReadWriteLock接口,该接口中定义readLock()返回读锁,定义 writeLock()方法返回写锁. 该接口 的实现类ReentrantReadWriteLock. 注意 readLock()与 writeLock()方法返回的锁对象是同一个锁的两个不同的角色, 不是分别获得两个不同的锁. ReadWriteLock 接口实例可 以充当两个角色.读写锁的其他使用方法

• ReadWriteLock rwLock = new ReentrantReadWriteLock(); //定义读写锁 
  Lock readLock = rwLock.readLock();//获得读锁
  Lock writeLock = rwLock.writeLock(); //获得写锁
  readLock.lock(); //读数据 ,//申请读锁
  try{读取共享数据 }
  finally{readLock.unlock(); //总是在 finally 子句中释放锁 }
  writeLock.lock(); //写数据,//申请写锁 
  try{更新修改共享数据 }
  finally{ writeLock.unlock(); //总是在 finally 子句中释放锁 }
  

1、 读读共享

ReadWriteLock 读写锁可以实现多个线程同时读取共享数据,即读 读共享,可以提高程序的读取数据的效率

/** ReadWriteLock读写锁可以实现读读共享,允许多个线程同时获得读锁*/

2、 写写互斥

通过 ReadWriteLock 读写锁中的写锁,只允许有一个线程执行 lock() 后面的代码.

3、读写互斥

写锁是独占锁,是排他锁,读线程与写线程也是互斥的

/**一个线程获得读锁时,写线程等待; 一个线程获得写锁时,其他线程等待 **/