每当在SO上出现关于Java同步的问题时,有些人都急于指出应该避免同步(这一点)。相反,他们声称,对私有引用的锁定是首选的。

其中一些原因是:

一些邪恶的代码可能会偷你的锁(这个很流行,也有一个“意外”变体) 同一类中的所有同步方法都使用完全相同的锁,这降低了吞吐量 你(不必要地)暴露了太多信息

包括我在内的其他人认为,synchronized(this)是一个被大量使用的习语(在Java库中也是如此),是安全的,而且很容易理解。它不应该被避免,因为你有一个错误,你不知道你的多线程程序中发生了什么。换句话说:如果它是适用的,那么就使用它。

我感兴趣的是看到一些现实世界的例子(没有foobar的东西),避免锁定在这是可取的,当同步(这)也会做的工作。

因此:您应该总是避免synchronized(this),并将其替换为私有引用上的锁吗?


一些进一步的信息(随着答案的更新):

we are talking about instance synchronization both implicit (synchronized methods) and explicit form of synchronized(this) are considered if you quote Bloch or other authorities on the subject, don't leave out the parts you don't like (e.g. Effective Java, item on Thread Safety: Typically it is the lock on the instance itself, but there are exceptions.) if you need granularity in your locking other than synchronized(this) provides, then synchronized(this) is not applicable so that's not the issue


当前回答

如果你已经决定:

你要做的就是锁定目标 当前对象;而且 你想要 锁定粒度小于 整体方法;

那么我就不认为synchronizezd是一个禁忌。

Some people deliberately use synchronized(this) (instead of marking the method synchronized) inside the whole contents of a method because they think it's "clearer to the reader" which object is actually being synchronized on. So long as people are making an informed choice (e.g. understand that by doing so they're actually inserting extra bytecodes into the method and this could have a knock-on effect on potential optimisations), I don't particularly see a problem with this. You should always document the concurrent behaviour of your program, so I don't see the "'synchronized' publishes the behaviour" argument as being so compelling.

至于应该使用哪个对象的锁的问题,我认为在当前对象上同步并没有什么错,如果这是你所做的逻辑所期望的,以及你的类通常是如何被使用的。例如,对于集合,逻辑上期望锁定的对象通常是集合本身。

其他回答

我将分别讨论每一点。

Some evil code may steal your lock (very popular this one, also has an "accidentally" variant) I'm more worried about accidentally. What it amounts to is that this use of this is part of your class' exposed interface, and should be documented. Sometimes the ability of other code to use your lock is desired. This is true of things like Collections.synchronizedMap (see the javadoc). All synchronized methods within the same class use the exact same lock, which reduces throughput This is overly simplistic thinking; just getting rid of synchronized(this) won't solve the problem. Proper synchronization for throughput will take more thought. You are (unnecessarily) exposing too much information This is a variant of #1. Use of synchronized(this) is part of your interface. If you don't want/need this exposed, don't do it.

一个使用synchronized(this)的好例子。

// add listener
public final synchronized void addListener(IListener l) {listeners.add(l);}
// remove listener
public final synchronized void removeListener(IListener l) {listeners.remove(l);}
// routine that raise events
public void run() {
   // some code here...
   Set ls;
   synchronized(this) {
      ls = listeners.clone();
   }
   for (IListener l : ls) { l.processEvent(event); }
   // some code here...
}

正如你在这里看到的,我们在这个上使用同步来方便地与那里的一些同步方法进行长周期(可能是无限循环的run方法)合作。

当然,在私有字段上使用synchronized可以很容易地重写。但有时,当我们已经有了一些同步方法的设计时(例如,我们从遗留类派生出来的,synchronized(this)可能是唯一的解决方案)。

让我先把结论说出来——对私有字段的锁定对于稍微复杂一点的多线程程序是不起作用的。这是因为多线程是一个全局问题。本地化同步是不可能的,除非你以一种非常防御的方式写(例如,复制所有传递给其他线程的内容)。


下面是详细的解释:

同步包括三个部分:原子性、可见性和有序性

同步块是非常粗糙的同步级别。正如您所期望的那样,它加强了可见性和排序。但是对于原子性,它并不能提供太多的保护。原子性要求程序的全局知识,而不是局部知识。(这使得多线程编程非常困难)

假设我们有一个Account类,它有存取款方法。它们都是基于一个私有锁进行同步的,就像这样:

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);
        }
    }
}

假设我们现在有两个账户,

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);
}

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

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

正确且最常用的方法是在Account中公开锁。并让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);
                }
            }
        }
    }
}

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

(转载自https://stackoverflow.com/a/67877650/474197)

如果你已经决定:

你要做的就是锁定目标 当前对象;而且 你想要 锁定粒度小于 整体方法;

那么我就不认为synchronizezd是一个禁忌。

Some people deliberately use synchronized(this) (instead of marking the method synchronized) inside the whole contents of a method because they think it's "clearer to the reader" which object is actually being synchronized on. So long as people are making an informed choice (e.g. understand that by doing so they're actually inserting extra bytecodes into the method and this could have a knock-on effect on potential optimisations), I don't particularly see a problem with this. You should always document the concurrent behaviour of your program, so I don't see the "'synchronized' publishes the behaviour" argument as being so compelling.

至于应该使用哪个对象的锁的问题,我认为在当前对象上同步并没有什么错,如果这是你所做的逻辑所期望的,以及你的类通常是如何被使用的。例如,对于集合,逻辑上期望锁定的对象通常是集合本身。

锁可以用于可见性,也可以用于保护一些数据不受可能导致竞争的并发修改的影响。

当您需要将基本类型操作设置为原子类型时,可以使用AtomicInteger之类的选项。

但是假设你有两个整数,它们像x和y坐标一样彼此相关,它们彼此相关,应该以原子的方式改变。然后使用相同的锁来保护它们。

锁应该只保护彼此相关的状态。不多不少。如果在每个方法中都使用synchronized(this),那么即使类的状态是不相关的,即使更新不相关的状态,所有线程也将面临争用。

class Point{
   private int x;
   private int y;

   public Point(int x, int y){
       this.x = x;
       this.y = y;
   }

   //mutating methods should be guarded by same lock
   public synchronized void changeCoordinates(int x, int y){
       this.x = x;
       this.y = y;
   }
}

在上面的例子中,我只有一个方法同时改变x和y,而不是两个不同的方法,因为x和y是相关的,如果我给了两个不同的方法分别改变x和y,那么它就不会是线程安全的。

这个例子只是为了演示它的实现方式,而不一定是这样。最好的方法是让它成为IMMUTABLE。

现在,与Point例子相反的是,@Andreas已经提供了一个TwoCounters的例子,其中状态被两个不同的锁保护,因为状态彼此不相关。

使用不同的锁来保护不相关的状态的过程称为锁剥离或锁分裂