当您使用synchronized(this)时，您正在使用类实例作为锁本身。这意味着当线程1获得锁时，线程2应该等待。

假设有以下代码:

public void method1() {
    // do something ...
    synchronized(this) {
        a ++;      
    }
    // ................
}


public void method2() {
    // do something ...
    synchronized(this) {
        b ++;      
    }
    // ................
}

方法一修改变量a，方法二修改变量b，应避免两个线程同时修改同一个变量。但是当thread1修改a和thread2修改b时，它可以在没有任何竞争条件的情况下执行。

不幸的是，上面的代码不允许这样做，因为我们对锁使用了相同的引用;这意味着线程即使没有处于竞争状态也应该等待，显然代码牺牲了程序的并发性。

解决方案是对两个不同的变量使用两个不同的锁:

public class Test {

    private Object lockA = new Object();
    private Object lockB = new Object();

    public void method1() {
        // do something ...
        synchronized(lockA) {
            a ++;      
        }
        // ................
    }


    public void method2() {
        // do something ...
        synchronized(lockB) {
            b ++;      
        }
        // ................
    }

}

上面的例子使用了更细粒度的锁(2个锁而不是一个锁(分别针对变量a和变量b的lockA和lockB)，结果允许更好的并发性，另一方面，它变得比第一个例子更复杂……

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

当您需要将基本类型操作设置为原子类型时，可以使用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的例子，其中状态被两个不同的锁保护，因为状态彼此不相关。

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

这要视情况而定。 如果只有一个或多个共享实体。

在这里查看完整的工作示例

简单介绍一下。

线程和可共享实体 多个线程可以访问同一个实体，例如多个connectionThreads共享一个messageQueue。由于线程并发运行，可能会有一个数据被另一个覆盖的机会，这可能是一个混乱的情况。 因此，我们需要某种方法来确保可共享实体一次只能被一个线程访问。(并发)。

同步块 Synchronized()块是一种确保可共享实体并发访问的方法。 首先，打个小比方 假设有两个人P1, P2(线程)一个盥洗室(可共享实体)，有一扇门(锁)。 现在我们想让一个人一次使用脸盆。 一种方法是在P1锁门的时候P2等待P1完成他的工作 P1打开门 那么只有p1可以使用脸盆。

语法。

synchronized(this)
{
  SHARED_ENTITY.....
}

"this" provided the intrinsic lock associated with the class (Java developer designed Object class in such a way that each object can work as monitor). Above approach works fine when there are only one shared entity and multiple threads (1: N). N shareable entities-M threads Now think of a situation when there is two washbasin inside a washroom and only one door. If we are using the previous approach, only p1 can use one washbasin at a time while p2 will wait outside. It is wastage of resource as no one is using B2 (washbasin). A wiser approach would be to create a smaller room inside washroom and provide them one door per washbasin. In this way, P1 can access B1 and P2 can access B2 and vice-versa.

washbasin1;  
washbasin2;

Object lock1=new Object();
Object lock2=new Object();

  synchronized(lock1)
  {
    washbasin1;
  }

  synchronized(lock2)
  {
    washbasin2;
  }

在这里查看更多关于Threads---->的信息

一个使用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)可能是唯一的解决方案)。

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

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.

我对2019年的看法，尽管这个问题本可以已经解决了。

如果你知道你在做什么，锁定'this'并不坏，但在幕后锁定'this'是(不幸的是synchronized关键字在方法定义中允许)。

如果你真的希望你的类的用户能够“窃取”你的锁(即阻止其他线程处理它)，你实际上希望所有同步方法在另一个同步方法运行时等待，以此类推。 它应该是有意的、经过深思熟虑的(因此有文档来帮助用户理解它)。

更详细地说，反过来，你必须知道如果你锁定了一个不可访问的锁(没有人可以“偷”你的锁，你完全控制等等)，你会“获得”(或“失去”)什么。

对我来说，问题是方法定义签名中的synchronized关键字使程序员很容易不考虑锁定什么，如果你不想在多线程程序中遇到问题，这是一个非常重要的事情。

人们不能争辩说，“通常”你不希望你的类的用户能够做这些事情，或者“通常”你想要……这取决于你编写的是什么功能。因为你不能预测所有的用例，所以你不能制定一个经验法则。

例如，prinwriter使用了一个内部锁，但是如果人们不想让他们的输出相互交错，他们就很难从多个线程中使用它。

锁是否可以在类外部访问是程序员根据类的功能来决定的。它是api的一部分。例如，你不能从synchronized(this)移到synchronized(provateObjet)而不冒破坏使用它的代码更改的风险。

注1:我知道你可以实现任何同步(这个)'实现'通过使用显式锁对象和暴露它，但我认为这是不必要的，如果你的行为是很好的记录，你实际上知道什么锁定'this'的意思。

注2:我不同意这样的观点:如果一些代码不小心偷了你的锁，那就是一个bug，你必须解决它。这在某种程度上等同于说我可以让我所有的方法公开，即使它们本不应该是公开的。如果有人“意外”调用我的意图是私人方法，这是一个bug。为什么会发生这样的事故!!如果能偷你的锁对你的类来说是一个问题，那就不要允许它。就这么简单。