在try块内部放置同步块还是在同步块内部放置try块更好？

Question

在try块内部放置同步块还是在同步块内部放置try块更好？

javamultithreadingtry-catchsynchronized-block

21

例如，这个更好吗？

try {
    synchronized (bean) {
        // Write something              
    }
} catch (InterruptedException e) {
    // Write something
}

或者这样更好：

synchronized (bean) {
    try {           
        // Write something              
    }
    catch (InterruptedException e) {
        // Write something
    }
}

我想知道哪种方法是最佳实践。显然，考虑到我必须同步try块中的所有代码。我不是在谈论只需同步try块中部分代码的情况（在这种情况下，我认为将同步块放在try内会更好）。我的疑问是关于需要同步整个try块的情况。

- user1883212

7个回答

3

并没有最佳实践。这取决于你是否需要在同步块内部处理异常。你可能需要其中之一，并且应该选择使同步块最短的那个，同时仍然保证代码正确和线程安全。

- JB Nizet

2

您似乎认为这只是一个审美问题，但事实并非如此。这是一个功能性问题，答案由每个具体情况的要求来决定。每个同步块应该足够大，以包含需要同步的所有内容，但不应过大。

- user207421

0

这个太老了，但今天我正在审查一位初级同事的代码时，发现一个与使用Java Lock对象类似于同步块有关的巨大错误。我正在寻找一些关于Java同步不完美的文档，并偶然发现了这个问题，想留下我的解决方案给那个家伙：

在同步的情况下，它确实取决于您的逻辑，因为Java保证锁的释放。

但是，当您使用基于对象的锁，例如Java的ReentrantLock时，您必须始终执行以下操作：

private final ReentrantLock lock = new ReentrantLock ();
void foo() {
    lock.lock();
    try {
        // Do your things
    } finally {
        lock.unlock();
    }
}

一旦您有了这个结构来确保锁的释放，您可以将锁和整个try/finally封装到另一个try中，如果您想在锁外处理catch，或者将其放在// Do your things处，如果您想从内部处理它。

此外，请记住，Java锁并不完美，就像在任何编程语言中一样，锁的类型选择取决于底层语言、操作的重要性（如果锁失败，是否会有人死亡，或者控制软件重试一百万次就能解决问题？）以及锁的性能影响。

如果您对锁一无所知，我建议您学习以下概念：

监视器（同步）
互斥
读/写锁模式
读-拷贝-更新
信号量（编程）

大多数情况下，您真正需要的是信号量、多读单写锁或仅监视器，因此了解这些术语将使您更快地搜索所需内容。

- DGoiko

0

你的catch块是否需要同步？由于你在那里写了“写一些东西”，我假设你将会进行一些日志记录，这不应该需要与良好的日志框架同步，这意味着答案可能是否。

总的来说，你的目标应该是尽可能少地使用同步。你的同步块越小，你遇到问题的可能性就越小。

- Jazzepi

0

在这种情况下，InterruptedException 只会发生在 synchronized 块内，您可以在其中调用 wait、sleep 或 notify。

通常最佳实践是将 try/catch 块尽可能靠近可能引发异常的代码，以便更容易识别需要修复的代码。

- Cratylus

0

这与synchronized{try{}}或try{synchronized{}}无关，但与synchronized{catch{}}或synchronized{} catch{}有关。它真正取决于您在catch块中执行的操作。

然而，猜测一下，对于InterruptedException，通常应该在synchronized{}之外使用catch{}。

- irreputable

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Gray · Accepted Answer

除非您明确需要在同步块内使用catch，否则我会尽可能地使同步代码段最小，并将其放置在try/catch内部。因此，第一种模式更好。然后，如果您需要在catch中执行操作（例如记录异常或重新中断线程，请参见下文），这些操作不会阻塞其他线程。

话虽如此，如果同步块包含许多行（通常不是一个好主意），那么我会考虑将try/catch块移动到引发异常的方法附近（很可能是wait或notify）。对于大量的行，您可能会出现使用大型try/catch块处理异常的风险。这在一定程度上取决于这里的参考框架。

顺便说一句，确保至少记录中断异常。永远不要忽略它们。您可能还想重新中断线程：

try {
   ...
} catch (InterruptedException e) {
   // always a good pattern
   Thread.currentThread().interrupt();
   // handle the interrupt here by logging or returning or ...
}