在尝试之前lock.lock()

时间:2012-06-03 06:40:08

标签: java locking java.util.concurrent

之间有什么区别:

private Lock lock = new ReentrantLock(true);

public void getIn (int direction) throws InterruptedException {

     lock.lock();
     try {
         ...

...

public void getIn (int direction) throws InterruptedException {

      try {
          lock.lock();
          ...

编译顺利进行,程序也正常工作(我的意思是相同的输出)

我应该把lock.lock();在尝试之前或之后?...

感谢您的帮助

4 个答案:

答案 0 :(得分:14)

假设lockReentrantLock,那么它没有什么区别,因为lock()不会抛出任何已检查的异常。

然而,Java文档将lock()留在try示例中的ReentrantLock块之外。原因是lock()中的未经检查的异常不应导致unlock()被错误地调用。在所有事情的lock()中存在未经检查的异常时,正确性是否是一个问题,这是另一个讨论。

一般来说,将try块之类的内容尽可能精细化是一种很好的编码实践。

答案 1 :(得分:9)

如果是1号案例,在finally中您可以说unlock()。在No2中你需要检查你是否在unlock()之前持有锁,否则你可以获得IllegalMonitorStateException

答案 2 :(得分:4)

try语句还包含:

 } finally {
     lock.unlock();
 }

也就是说,如果您在lock.lock()之后放置try,则lock.lock()引发的异常会导致 lock.unlock(),这是错误的,因为没有获得锁定,解锁会导致另一个异常。所以第一个变体是正确的。要处理lock.lock()引发的异常,您必须使用另一个try语句。

答案 3 :(得分:0)

在第一种情况下:如果lock.lock()抛出InterruptedExceptiongetIn将对其进行管理。但是对于任何其他异常,它会抛出一个异常,getIn不处理:运行时异常

在第二种情况下:除了InterruptedException之外,try-catch块也在进行一些异常处理,这里没有显示。这应该抛出较少的异常,因为内部块也捕获了一些异常。

整体运行取决于lock.lock()引发的异常?