为什么不建议从 finally 子句中调用二进制信号量的 release() 方法？答案

【问题标题】：Why it isn't advised to call the release() method of a binary semaphore from inside a finally-clause?为什么不建议从 finally 子句中调用二进制信号量的 release() 方法？
【发布时间】：2012-02-25 09:15:53
【问题描述】：

为了确保 Lock 被解锁，建议从 finally 子句中调用 unlock() 方法：

lock.lock();
try{
  // critical section which may throw exceptions
} finally {
  lock.unlock();
}

这是为了避免可能的死锁，以防临界区的代码抛出异常。

为什么不建议在等效场景中对二进制信号量采用相同的做法？

mutex.acquire();
try{
  // critical section which may throw exceptions
} finally {
  mutex.release();
}

【问题讨论】：

标签： java multithreading concurrency deadlock semaphore

【解决方案1】：

我会说这通常是处理它们的最佳方式。然而，信号量可以由单独的线程释放，因此在一些高级用例中，这种模式是不可能的。（也就是说，Lock lock() 和 unlock() 调用可能在不同的方法中，因此也无法使用 finally 块）。

【讨论】：

【解决方案2】：

因为在二进制信号量上等待成功的线程不一定是发出信号的线程。线程不像获取互斥锁那样拥有信号量单元——任何线程都可以发出信号量信号（因此它们通常用于生产者-消费者队列）。

【讨论】：

【解决方案3】：

我建议这样做。但是信号量和锁的主要区别在于信号量没有所有者。这意味着获取信号量的线程可能不是释放它的线程，这没关系。我建议总是在某个时候在 finally 块中发布

【讨论】：