在 Java 临界区中，我应该同步什么？

Question

在 Java 中，在代码中声明关键部分的惯用方法如下：

private void doSomething() {
  // thread-safe code
  synchronized(this) {
    // thread-unsafe code
  }
  // thread-safe code
}

几乎所有块都在 this 上同步，但这有什么特殊原因吗？ 还有其他的可能性吗？ 是否有关于同步对象的最佳实践？ （例如 Object 的私有实例？）

Answer 1

正如前面的回答者所指出的，最佳实践是在有限范围的对象上进行同步（换句话说，选择您可以摆脱的最严格的范围，然后使用它。）特别是在 this 是一个坏主意，除非您打算允许您的类的用户获得锁定。

但是，如果您选择在 java.lang.String 上进行同步，就会出现一种特别丑陋的情况。 字符串可以（并且在实践中几乎总是）被保留。 这意味着在整个 JVM 中，每个内容相同的字符串在幕后都是相同的字符串。 这意味着，如果您在任何字符串上进行同步，另一个（完全不同的）代码段也锁定具有相同内容的字符串，实际上也会锁定您的代码。

我曾经对生产系统中的死锁进行故障排除，并且（非常痛苦地）将死锁跟踪到两个完全不同的开源包，每个包在一个 String 实例上同步，其内容都是“LOCK”。

Answer 2

首先，请注意以下代码片段是相同的。

public void foo() {
    synchronized (this) {
        // do something thread-safe
    }
}

并且：

public synchronized void foo() {
    // do something thread-safe
}

做完全相同的事情。 除了代码可读性和风格之外，对其中任何一个都没有偏好。

当您同步方法或代码块时，重要的是要知道为什么要做这样的事情，以及锁定什么对象，以及为什么要锁定目的。

另请注意，在某些情况下，您需要客户端同步代码块，其中您请求的监视器（即同步对象）不一定是this，就像这个例子一样：

Vector v = getSomeGlobalVector();
synchronized (v) {
    // some thread-safe operation on the vector
}

我建议你了解更多关于并发编程的知识，一旦你确切地知道幕后发生了什么，它会对你有很大帮助。 您应该查看 Java 并发编程，这是一本关于该主题的好书。 如果您想快速深入了解该主题，请查看 Java Concurrency @ Sun

Answer 3

我尝试避免在 this 上进行同步，因为这将允许外部引用该对象的每个人阻止我的同步。 相反，我创建一个本地同步对象：

public class Foo {
    private final Object syncObject = new Object();
    …
}

现在我可以使用该对象进行同步，而不必担心任何人“窃取”锁。

Answer 4

只是为了强调一下，Java 中也有可用的 ReadWriteLock，如 java.util.concurrent.locks.ReadWriteLock。

在我的大多数使用中，我将锁定分为“用于阅读”和“用于更新”。 如果您仅使用同步关键字，则对同一方法/代码块的所有读取都将“排队”。 一次只有一个线程可以访问该块。

在大多数情况下，如果您只是进行读取，则永远不必担心并发问题。 当您进行写入时，您需要担心并发更新（导致数据丢失），或者写入期间的读取（部分更新），这是您必须担心的。

因此，在多线程编程期间，读/写锁对我来说更有意义。

Answer 5

您需要在可以充当互斥体的对象上进行同步。 如果当前实例（this 引用）合适（例如，不是单例），您可以使用它，就像在 Java 中任何对象都可以充当互斥体一样。

在其他情况下，如果这些类的实例可能都需要访问相同的资源，您可能希望在多个类之间共享互斥锁。

这在很大程度上取决于您正在工作的环境以及您正在构建的系统类型。 在我见过的大多数 Java EE 应用程序中，实际上并不需要同步......

Answer 6

就我个人而言，我认为那些坚持认为在 this 上同步永远不会或很少正确的答案是错误的。 我认为这取决于你的API。 如果您的类是线程安全实现并且您如此记录它，那么您应该使用 this。 如果同步不是为了使类的每个实例在调用其公共方法时作为一个整体线程安全，那么您应该使用私有内部对象。 可重用的库组件通常属于前一类 - 在禁止用户将您的 API 包装在外部同步中之前，您必须仔细考虑。

在前一种情况下，使用 this 允许以原子方式调用多个方法。 一个例子是 PrintWriter，您可能希望输出多行（例如控制台/记录器的堆栈跟踪）并保证它们一起出现 - 在这种情况下，它在内部隐藏同步对象这一事实是一个真正的痛苦。 另一个这样的例子是同步集合包装器 - 您必须同步集合对象本身才能进行迭代； 由于迭代由多个方法调用组成，因此您无法在内部完全保护它。

在后一种情况下，我使用普通对象：

private Object mutex=new Object();

但是，在看到许多 JVM 转储和堆栈跟踪表明锁是“java.lang.Object() 的一个实例”之后，我不得不说，使用内部类通常可能是正如其他人所建议的那样更有帮助。

无论如何，这就是我的两块钱。

编辑：另一件事，在 this 上同步时，我更喜欢同步方法，并保持方法非常精细。 我认为它更清晰、更简洁。

Answer 7

Java 中的同步通常涉及同一实例上的同步操作。 在 this 上进行同步是非常惯用的，因为 this 是一个共享引用，在类中的不同实例方法（或部分）之间自动可用。

使用另一个专门用于锁定的引用，例如通过声明和初始化私有字段Object lock = new Object()，是我从未需要或使用过的。 我认为只有当您需要对对象内的两个或多个不同步资源进行外部同步时，它才有用，尽管我总是尝试将这种情况重构为更简单的形式。

无论如何，隐式（同步方法）或显式 synchronized(this) 被大量使用，在 Java 库中也是如此。 这是一个很好的习语，如果适用的话，应该始终是您的首选。

Answer 8

同步的内容取决于可能与此方法调用发生冲突的其他线程可以同步的内容。

如果 this 是一个仅由一个线程使用的对象，并且我们正在访问在线程之间共享的可变对象，那么一个好的候选方法是同步该对象 - 在 this 上同步code> 没有意义，因为修改该共享对象的另一个线程可能甚至不知道 this，但确实知道该对象。

另一方面，如果许多线程同时调用此对象的方法（例如，如果我们处于单例中），则通过 this 进行同步是有意义的。

请注意，同步方法通常不是最佳选择，因为我们在方法运行的整个过程中都持有锁。 如果它包含耗时但线程安全的部分，以及不太耗时的线程不安全部分，则在方法上进行同步是非常错误的。

Answer 9

几乎所有区块都在此同步，但这有什么特殊原因吗？ 还有其他可能吗？

该声明同步整个方法。

private synchronized void doSomething() {

该声明同步了代码块的一部分而不是整个方法。

private void doSomething() {
  // thread-safe code
  synchronized(this) {
    // thread-unsafe code
  }
  // thread-safe code
}

从oracle文档页面中

，使这些方法同步有两个效果：

首先，同一对象上的同步方法的两次调用不可能交错。 当一个线程正在执行对象的同步方法时，调用同一对象的同步方法的所有其他线程都会阻塞（挂起执行），直到第一个线程完成该对象。

还有其他的可能性吗？ 是否有关于同步对象的最佳实践？ （比如Object的私有实例？）

同步有很多可能性和替代方案。 您可以使用高级并发 API（自 JDK 1.5 版本起可用）

Lock objects
Executors
Concurrent collections
Atomic variables
ThreadLocalRandom

请参阅以下 SE 问题了解更多详细信息：

同步与锁定

避免在 Java 中同步（this）？

Answer 10

最佳实践是创建一个仅提供锁的对象：

private final Object lock = new Object();

private void doSomething() {
  // thread-safe code
  synchronized(lock) {
    // thread-unsafe code
  }
  // thread-safe code
}

通过这样做，您是安全的，任何调用代码都不会因无意的 synchronized(yourObject) 行而使您的方法死锁。

（感谢 @jared 和 @yuval-adam，他们在上面对此进行了更详细的解释。）

我的猜测是，在教程中使用 this 的流行来自于早期的 Sun javadoc： https://docs.oracle.com/javase/tutorial/essential/并发/locksync.html

Answer 11

同步包括3个部分：原子性、可见性和排序

同步块是非常粗粒度的同步。 它按照您的预期强制执行可见性和排序。 但对于原子性来说，并没有提供太多的保护。 原子性需要程序的全局知识而不是局部知识。 （这使得多线程编程非常困难）

假设我们有一个类 Account ，它有方法 deposit 和 withdraw。 它们都基于私有锁进行同步，如下所示：

class Account {
    private Object lock = new Object();

    void withdraw(int amount) {
        synchronized(lock) {
            // ...
        }
    }

    void deposit(int amount) {
        synchronized(lock) {
            // ...
        }
    }
}

考虑到我们需要实现一个处理转账的更高级别的类，如下所示：

class AccountManager {
    void transfer(Account fromAcc, Account toAcc, int amount) {
        if (fromAcc.getBalance() > amount) {
            fromAcc.setBalance(fromAcc.getBalance() - amount);
            toAcc.setBalance(toAcc.getBalance + amount);
        }
    }
}

假设我们现在有 2 个帐户，

Account john;
Account marry;

如果 Account.deposit()和 Account.withdraw() 仅使用内部锁锁定。 当我们有 2 个线程工作时，这会导致问题：

// Some thread
void threadA() {
    john.withdraw(500);
}

// Another thread
void threadB() {
    accountManager.transfer(john, marry, 100);
}

因为 threadA 和 threadB 可能同时运行。 并且线程B完成条件检查，线程A退出，线程B再次退出。 这意味着即使约翰的账户没有足够的钱，我们也可以从约翰那里提取 100 美元。 这会破坏原子性。

您可能会提出：为什么不将 withdraw() 和 deposit() 添加到 AccountManager 中呢？ 但根据这个建议，我们需要创建一个多线程安全的Map，它将不同的帐户映射到它们的锁。 我们需要在执行后删除锁（否则会泄漏内存）。 我们还需要确保没有其他人直接访问Account.withdraw()。 这将引入许多微妙的错误。

正确且最惯用的方法是公开帐户中的锁。 并让AccountManager使用锁。 但在这种情况下，为什么不直接使用对象本身呢？

class Account {
    synchronized void withdraw(int amount) {
        // ...
    }

    synchronized void deposit(int amount) {
        // ...
    }
}

class AccountManager {
    void transfer(Account fromAcc, Account toAcc, int amount) {
        // Ensure locking order to prevent deadlock
        Account firstLock = fromAcc.hashCode() < toAcc.hashCode() ? fromAcc : toAcc;
        Account secondLock = fromAcc.hashCode() < toAcc.hashCode() ? toAcc : fromAcc;

        synchronized(firstLock) {
            synchronized(secondLock) {
                if (fromAcc.getBalance() > amount) {
                    fromAcc.setBalance(fromAcc.getBalance() - amount);
                    toAcc.setBalance(toAcc.getBalance + amount);
                }
            }
        }
    }
}

简而言之，私有锁不适用于稍微复杂的多线程程序。