论坛首页 → Java企业应用论坛 →

再谈重入锁--ReentrantLock

浏览 18822 次
锁定老帖子 主题：再谈重入锁--ReentrantLock
精华帖 (2) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
  • tenyears
  • 等级: 初级会员
  • 性别:
  • 文章: 3
  • 积分: 42
  • 来自: 湖北武汉
   发表时间：2007-01-20  
OO

重入锁（ReentrantLock）是一种递归无阻塞的同步机制。以前一直认为它是synchronized的简单替代，而且实现机制也不相差太远。不过最近实践过程中发现它们之间还是有着天壤之别。

以下是官方说明：一个可重入的互斥锁定 Lock，它具有与使用 synchronized 方法和语句所访问的隐式监视器锁定相同的一些基本行为和语义，但功能更强大。ReentrantLock 将由最近成功获得锁定，并且还没有释放该锁定的线程所拥有。当锁定没有被另一个线程所拥有时，调用 lock 的线程将成功获取该锁定并返回。如果当前线程已经拥有该锁定，此方法将立即返回。可以使用 isHeldByCurrentThread() 和 getHoldCount() 方法来检查此情况是否发生。

它提供了lock()方法：
如果该锁定没有被另一个线程保持，则获取该锁定并立即返回，将锁定的保持计数设置为 1。
如果当前线程已经保持该锁定，则将保持计数加 1，并且该方法立即返回。
如果该锁定被另一个线程保持，则出于线程调度的目的，禁用当前线程，并且在获得锁定之前，该线程将一直处于休眠状态，此时锁定保持计数被设置为 1。

最近在研究Java concurrent中关于任务调度的实现时，读了延迟队列DelayQueue的一些代码，比如take()。该方法的主要功能是从优先队列（PriorityQueue）取出一个最应该执行的任务（最优值），如果该任务的预订执行时间未到，则需要wait这段时间差。反之，如果时间到了，则返回该任务。而offer()方法是将一个任务添加到该队列中。

后来产生了一个疑问：如果最应该执行的任务是一个小时后执行的，而此时需要提交一个10秒后执行的任务，会出现什么状况？还是先看看take()的源代码：

<!---->
public E take() throws InterruptedException {
    final ReentrantLock lock = this.lock;
    lock.lockInterruptibly();
    try {
        for (;;) {
            E first = q.peek();
            if (first == null) {
                available.await();
            } else {
                long delay =  first.getDelay(TimeUnit.NANOSECONDS);
                if (delay > 0) {
                    long tl = available.awaitNanos(delay);
                } else {
                    E x = q.poll();
                    assert x != null;
                    if (q.size() != 0)
                        available.signalAll(); // wake up other takers
                    return x;
                }
            }
        }
    } finally {
        lock.unlock();
    }
}

而以下是offer()的源代码:

public boolean offer(E e) {
    final ReentrantLock lock = this.lock;
    lock.lock();
    try {
        E first = q.peek();
        q.offer(e);
        if (first == null || e.compareTo(first) < 0)
            available.signalAll();
        return true;
    } finally {
        lock.unlock();
    }
}

 

如代码所示，take()和offer()都是lock了重入锁。如果按照synchronized的思维（使用诸如synchronized(obj)的方法），这两个方法是互斥的。回到刚才的疑问，take()方法需要等待1个小时才能返回，而offer()需要马上提交一个10秒后运行的任务，会不会一直等待take()返回后才能提交呢？答案是否定的，通过编写验证代码也说明了这一点。这让我对重入锁有了更大的兴趣，它确实是一个无阻塞的锁。

下面的代码也许能说明问题：运行了4个线程，每一次运行前打印lock的当前状态。运行后都要等待5秒钟。

public static void main(String[] args) throws InterruptedException {
  final ExecutorService exec = Executors.newFixedThreadPool(4);
  final ReentrantLock lock = new ReentrantLock();
  final Condition con = lock.newCondition();
  final int time = 5;
  final Runnable add = new Runnable() {
    public void run() {
      System.out.println("Pre " + lock);
      lock.lock();
      try {
        con.await(time, TimeUnit.SECONDS);
      } catch (InterruptedException e) {
        e.printStackTrace();
      } finally {
        System.out.println("Post " + lock.toString());
        lock.unlock();
      }
    }
  };
  for(int index = 0; index < 4; index++)
    exec.submit(add);
  exec.shutdown();
}

 

这是它的输出：
Pre ReentrantLock@a59698[Unlocked]
Pre ReentrantLock@a59698[Unlocked]
Pre ReentrantLock@a59698[Unlocked]
Pre ReentrantLock@a59698[Unlocked]
Post ReentrantLock@a59698[Locked by thread pool-1-thread-1]
Post ReentrantLock@a59698[Locked by thread pool-1-thread-2]
Post ReentrantLock@a59698[Locked by thread pool-1-thread-3]
Post ReentrantLock@a59698[Locked by thread pool-1-thread-4]

每一个线程的锁状态都是“Unlocked”,所以都可以运行。但在把con.await改成Thread.sleep(5000)时，输出就变成了：
Pre ReentrantLock@a59698[Unlocked]
Pre ReentrantLock@a59698[Locked by thread pool-1-thread-1]
Pre ReentrantLock@a59698[Locked by thread pool-1-thread-1]
Pre ReentrantLock@a59698[Locked by thread pool-1-thread-1]
Post ReentrantLock@a59698[Locked by thread pool-1-thread-1]
Post ReentrantLock@a59698[Locked by thread pool-1-thread-2]
Post ReentrantLock@a59698[Locked by thread pool-1-thread-3]
Post ReentrantLock@a59698[Locked by thread pool-1-thread-4]

以上的对比说明线程在等待时(con.await)，已经不在拥有（keep）该锁了，所以其他线程就可以获得重入锁了。

有必要会过头再看看Java官方的解释：“如果该锁定被另一个线程保持，则出于线程调度的目的，禁用当前线程，并且在获得锁定之前，该线程将一直处于休眠状态”。我对这里的“保持”的理解是指非wait状态外的所有状态，比如线程Sleep、for循环等一切有CPU参与的活动。一旦线程进入wait状态后，它就不再keep这个锁了，其他线程就可以获得该锁；当该线程被唤醒（触发信号或者timeout）后，就接着执行，会重新“保持”锁，当然前提依然是其他线程已经不再“保持”了该重入锁。

总结一句话：对于重入锁而言，"lock"和"keep"是两个不同的概念。lock了锁，不一定keep锁，但keep了锁一定已经lock了锁。
返回顶楼
         
  • galaxystar
  • 等级: 五钻会员
  • 性别:
  • 文章: 630
  • 积分: 2483
  • 来自: 杭州
   发表时间：2007-01-20  
推荐一下原子操作，更简便，实用！java.concurrent.atomic下的几种常用类型也很全了，性能比lock好！
前提是不会出现race condition!
当然LOCK比synchronized好多了！lock()与unlock()结合在try.finally块中，使用也比较方便！
返回顶楼
          回帖地址
0 请登录后投票
  • 歆渊
  • 等级: 二钻会员
  • 性别:
  • 文章: 424
  • 积分: 1219
   发表时间：2007-01-20  
DelayQueue 实现里面只用到了一个 Lock 和 它的一个 Condition 的组合, 这个没有超出原有 synchronized + Object.wait() + Object.notify() 的范围, 新的同步机制的好处, 比如 公平竞争, 单资源多条件 等等都没有派上用场.

在对一个对象的 synchronized 块中 Object.wait(); 过程中, 同样是不会阻塞其它线程进入该对象的 synchronized 块的. 所以它目前的实现是完全可以用原有机制代替的

现在的代码执行速度方面不知道是不是一定有提升, 但从内存占用角度看, 还不如原有机制效率高.
返回顶楼
          回帖地址
1 请登录后投票
  • YuLimin
  • 等级: 五钻会员
  • 性别:
  • 文章: 506
  • 积分: 2350
  • 来自: 福建莆田@广州
   发表时间：2007-01-20  
推荐一篇我在IBM DW上面看到的不错的文章

《Java 理论与实践: JDK 5.0 中更灵活、更具可伸缩性的锁定机制》

http://www.ibm.com/developerworks/cn/java/j-jtp10264/index.html
返回顶楼
          回帖地址
0 请登录后投票
  • lordhong
  • 等级: 五钻会员
  • 性别:
  • 文章: 4672
  • 积分: 2737
  • 来自: 在野
   发表时间：2007-01-21  
多谢,受益非浅
返回顶楼
          回帖地址
0 请登录后投票
论坛首页 → Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics