在c#和Java阵营中似乎有不同的共识。我看到的大多数Java代码使用:

// apply mutex to this instance
synchronized(this) {
    // do work here
}

而大多数c#代码选择了更安全的:

// instance level lock object
private readonly object _syncObj = new object();

...

// apply mutex to private instance level field (a System.Object usually)
lock(_syncObj)
{
    // do work here
}

c#语言当然更安全。如前所述，不能从实例外部对锁进行恶意/意外访问。Java代码也有这种风险，但随着时间的推移，Java社区似乎倾向于稍微不那么安全，但稍微更简洁的版本。

这并不是对Java的挖苦，只是我在这两种语言上工作的经验的反映。

这实际上只是对其他答案的补充，但如果你对使用私有对象进行锁定的主要反对意见是，它会使你的类与与业务逻辑无关的字段混乱，那么Project Lombok有@Synchronized在编译时生成样板:

@Synchronized
public int foo() {
    return 0;
}

编译,

private final Object $lock = new Object[0];

public int foo() {
    synchronized($lock) {
        return 0;
    }
}

首先需要指出的是:

public void blah() {
  synchronized (this) {
    // do stuff
  }
}

语义上等价于:

public synchronized void blah() {
  // do stuff
}

这是不使用synchronized(this)的一个原因。您可能会说，您可以围绕synchronized(this)块做一些事情。通常的原因是试图避免必须进行同步检查，这将导致各种并发问题，特别是双重检查锁定问题，这表明要使一个相对简单的检查具有线程安全性是多么困难。

私有锁是一种防御机制，这从来都不是一个坏主意。

另外，正如您所提到的，私有锁可以控制粒度。一个对象上的一组操作可能与另一组完全无关，但同步(这)将相互排除对所有这些操作的访问。

同步(这个)真的不能给你任何东西。

concurrent包极大地降低了线程安全代码的复杂性。我只有一些轶事证据，但我所见过的大多数synchronized(x)工作似乎都是重新实现Lock、Semaphore或Latch，但使用的是较低级别的监视器。

考虑到这一点，使用这些机制中的任何一种进行同步都类似于对内部对象进行同步，而不是泄露锁。这是非常有益的，因为您可以绝对确定通过两个或多个线程控制进入监视器的条目。

如果可能的话，让你的数据不可变(最终变量) 如果你不能避免跨多个线程共享数据的突变，使用高级编程结构[例如，粒度锁API]

Lock提供对共享资源的独占访问:一次只有一个线程可以获得锁，并且对共享资源的所有访问都要求首先获得锁。

使用ReentrantLock实现Lock接口的示例代码

 class X {
   private final ReentrantLock lock = new ReentrantLock();
   // ...

   public void m() {
     lock.lock();  // block until condition holds
     try {
       // ... method body
     } finally {
       lock.unlock()
     }
   }
 }

锁定相对于同步的优势

The use of synchronized methods or statements forces all lock acquisition and release to occur in a block-structured way. Lock implementations provide additional functionality over the use of synchronized methods and statements by providing A non-blocking attempt to acquire a lock (tryLock()) An attempt to acquire the lock that can be interrupted (lockInterruptibly()) An attempt to acquire the lock that can timeout (tryLock(long, TimeUnit)). A Lock class can also provide behavior and semantics that is quite different from that of the implicit monitor lock, such as guaranteed ordering non-re entrant usage Deadlock detection

看看这个关于各种锁的SE问题:

同步vs锁定

您可以通过使用高级并发API而不是synchronized块来实现线程安全。该文档页提供了实现线程安全的良好编程结构。

锁对象支持简化许多并发应用程序的锁定习惯用法。

executor为启动和管理线程定义了高级API。concurrent提供的执行器实现提供了适合大型应用程序的线程池管理。

并发集合使管理大型数据集合变得更容易，并且可以大大减少同步的需要。

原子变量具有最小化同步和帮助避免内存一致性错误的特性。

ThreadLocalRandom(在JDK 7中)提供了从多个线程有效生成伪随机数的功能。

其他编程结构也可以参考java.util.concurrent和java.util.concurrent.atomic包。

简单的回答:您必须了解其中的区别，并根据代码做出选择。

Long answer: In general I would rather try to avoid synchronize(this) to reduce contention but private locks add complexity you have to be aware of. So use the right synchronization for the right job. If you are not so experienced with multi-threaded programming I would rather stick to instance locking and read up on this topic. (That said: just using synchronize(this) does not automatically make your class fully thread-safe.) This is a not an easy topic but once you get used to it, the answer whether to use synchronize(this) or not comes naturally.