【问题标题】:Force unlocking a reentrant lock强制解锁可重入锁
【发布时间】:2012-10-09 01:47:29
【问题描述】:

我有一个可重入锁,我将它封装在一个自定义类中以满足我自己的需要。但是,由于应用程序的性质,持有可重入锁的锁的线程会卡住(外部故障)并且无法释放可重入锁。

我想知道是否有一种方法可以显式解锁可重入锁?我知道可重入锁的 API 没有这样的方法 - 但是我正在考虑引入一个计时器任务,该任务将在一段时间后解锁可重入锁或杀死持有可重入锁的线程。

在尝试强制解锁我的可重入锁方面还有其他建议吗?我的解决方案很好,所以我问。

【问题讨论】:

  • 你有一些示例代码吗?所有锁都应该包裹在try/catch/finally 块中,在最后一部分中,您应该释放当前持有的所有锁

标签: java multithreading concurrency locking reentrancy


【解决方案1】:

我不会在外部解锁,而是在单独的线程中执行阻塞代码并让它超时

类似的东西

Future<MyTask>future = taskExecutor.submit(myTask)
try {
    future.get(5,TimeUnit.Seconds);
    ...
    }
    catch (Exception e)
    {
        future.cancel(true); // attempt to interupt the thread
        throw new Exception();
    }

【讨论】:

  • 我最终选择了这个解决方案 :)
【解决方案2】:

根据我的评论,任何锁都应该包裹在 try/finally 块周围,以确保在出现问题时释放锁

_lock.lock(); // will wait until this thread gets the lock
try
{
    // critical section
}
finally
{
    //releasing the lock so that other threads can get notifies
    _lock.unlock();
}       

这在Lock Objects 线索中得到了证明

【讨论】:

  • 感谢您的回复,但是,我正在寻找按照您的示例强制解锁“_lock”。同意持有者应该解锁它持有的锁,但是,持有者线程偶尔会由于一些外部依赖而进入一个时髦的状态,并且永远不会放弃锁。除非我以某种方式杀死线程或强制解锁“_lock”,否则其他线程不会继续前进,这就是我考虑强制解锁机制的原因。
  • 我不认为你能达到你想要的。这实际上会破坏锁定的目的
  • 在某些方面我完全同意你的看法——但本质上,我正在寻找一种智能的方法来摆脱由于外部故障而导致应用程序无法进一步进展并且未能放弃的状态锁。顺便说一句,_lock.unlock() 也会抛出 IllegalMontiorStateException,对 unlock() 的调用是否也应该包含在 try/catch 中?是否有相当于 for lock unlocks() 的 closeQuietly()?
  • 对 unlock() 的调用是否也应该被包装,是的,你是对的,它应该被包装在 try/catch 中(除非你想把它扔掉) .我能想到的最好的解决方案(这确实是一个 hack),是提供一种进入方式世界线程的方法,允许您解锁锁
  • 否决票的任何理由?很高兴从别人的角度学习
猜你喜欢
  • 2016-04-16
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多