Java多线程学习笔记16之Lock的使用

详细代码见:github代码地址

 

本节内容:

1) Lock接口/ReentrantLock类/lock()/unlock()方法文档翻译

    翻译中包含了此重入锁与synchronized方法及语句块之间区别及优缺点

2) 使用ReentrantLock实现同步

第四章

Lock的使用

内容:
Java5中的Lock对象也能实现同步的效果，而且在使用上也更加方便。
本章主要掌握以下两个知识点:
1) ReentrantLock的使用
2) ReentrantReadWriteLock类的使用

1.使用ReentrantLock类
在Java多线程中，可以使用synchronized(重量锁)关键字来实现线程之间的同步互斥，但在
JDK1.5中新增加了ReentrantLock(轻量锁)类也能达到同样的效果，并且在扩展功能上也更加
强大，比如具有嗅探锁定，多路分支通知等。在中等或更高负荷下，ReentrantLock
有更好的性能,并且拥有可轮询和可定时的请求锁等高级功能。
重入锁ReentrantLock:

     也叫作递归锁，顾名思义，就是支持重新进入的锁，它表示该锁能够支持一个线
程对资源的重复加锁，用于占有锁的线程再次获取锁的场景。同一线程中某个外层函数
获得锁之后，其内层代码再次获取该锁，形成递归调用，而不受影响。

(1) 文档翻译(Lock接口和ReentrantLock类及lock()、unlock()方法)
翻译中其实也介绍了重入锁与synchronized加锁的区别

ReentrantLock类
public class ReentrantLock
extends Object
implements Lock, Serializable 可以看到此类实现了Lock及Serializable序列化接口
A reentrant mutual exclusion Lock with the same basic behavior and semantics as 
the implicit monitor lock accessed using synchronized methods and statements,
but with extended capabilities.
A ReentrantLock is owned by the thread last successfully locking, but not yet 
unlocking it. A thread invoking lock will return, successfully acquiring the 
lock, when the lock is not owned by another thread. The method will return 
immediately if the current thread already owns the lock. This can be checked 
using methods isHeldByCurrentThread(), and getHoldCount().
与使用同步方法和语句访问的隐式监视器锁相同的基本行为和语义的可重入互斥锁。但具有可拓展
能力。ReentrantLock对象是由最后一次成功锁定，但尚未解锁它的线程拥有的.当锁没有被其他
线程拥有的时候，一个线程通过调用lock()方法来成功获得锁。当前锁是否被别的线程锁拥有
可以使用isHeldByCurrentThread()和getHoldCount()进行检查。

The constructor for this class accepts an optional fairness parameter. When set 
true, under contention, locks favor granting access to the longest-waiting 
thread. Otherwise this lock does not guarantee any particular access order. 
Programs using fair locks accessed by many threads may display lower overall 
throughput (i.e., are slower; often much slower) than those using the default 
setting, but have smaller variances in times to obtain locks and guarantee lack 
of starvation. Note however, that fairness of locks does not guarantee fairness 
of thread scheduling. Thus, one of many threads using a fair lock may obtain it 
multiple times in succession while other active threads are not progressing and 
not currently holding the lock. Also note that the untimed tryLock() method does 
not honor the fairness setting. It will succeed if the lock is available even if 
other threads are waiting.
此类的构造函数接受可选的公平性参数。如果设置为true,在"争用"情况下，锁将更支持给最长等待
时间的线程。否则，此锁不保证任任何特定的访问顺序。使用由多线程访问的公平锁的程序可能会显示
较低的总体吞吐量(即，速度较慢;通常要慢的多),而不是使用默认的设置(即，默认情况下不指定
默认是非公平锁)，但有时会有较小的差异来获取锁并保证缺乏饥饿。但注意，公平锁并不保证线程调度
的公平性。因此，多线程中使用公平锁中的一个线程可以连续多次获得这个锁，而其他存活的线程没有
进展，并且当前不持有锁。另外要注意的是，tryLock()方法不尊重公平性的设置。如果锁可用，即使
其他线程正在等待，它也会成功

It is recommended practice to always immediately follow a call to lock with a try
block, most typically in a before/after construction such as:
建议的做法总是立即用try-catch代码块在构造之前之后加入，例如:

 
 class X {
   private final ReentrantLock lock = new ReentrantLock();
   // ...

   public void m() {
     lock.lock();  // block until condition holds
     try {