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

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

虽然我同意不要盲目地遵守教条规则，但“偷锁”的场景对你来说是不是很古怪?一个线程确实可以从你的对象“外部”获得锁(synchronized(theObject){…})，阻塞其他线程等待同步实例方法。

如果您不相信恶意代码，请考虑这些代码可能来自第三方(例如，如果您开发了某种应用程序服务器)。

“意外”版本似乎不太可能，但就像他们说的那样，“让一些东西不受白痴的影响，就会有人发明一个更好的白痴”。

所以我同意“这取决于这个班级做什么”的观点。

编辑以下eljenso的前3条评论:

我从来没有遇到过偷锁的问题，但这里有一个想象的场景:

假设您的系统是一个servlet容器，我们考虑的对象是ServletContext实现。它的getAttribute方法必须是线程安全的，因为上下文属性是共享数据;所以你声明它是同步的。让我们再想象一下，您提供了一个基于容器实现的公共托管服务。

我是您的客户，并在您的站点上部署我的“好”servlet。我的代码碰巧包含对getAttribute的调用。

黑客伪装成另一个客户，在您的站点上部署恶意servlet。它在init方法中包含以下代码:

synchronized (this.getServletConfig().getServletContext()) {
   while (true) {}
}

假设我们共享相同的servlet上下文(只要两个servlet位于同一个虚拟主机上，规范就允许)，那么我对getAttribute的调用将永远锁定。黑客已经在我的servlet上实现了DoS。

如果getAttribute在私有锁上同步，则这种攻击是不可能的，因为第三方代码无法获得此锁。

我承认这个例子是人为设计的，对servlet容器如何工作的看法过于简单，但恕我直言，它证明了这一点。

因此，我将基于安全性考虑做出设计选择:我是否能够完全控制访问实例的代码?线程无限期地持有实例锁的后果是什么?

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

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

避免使用synchronized(this)作为锁定机制:这会锁定整个类实例，并可能导致死锁。在这种情况下，重构代码以只锁定特定的方法或变量，这样整个类就不会被锁定。同步可以在方法级别内使用。 下面的代码展示了如何锁定一个方法，而不是使用synchronized(this)。

   public void foo() {
if(operation = null) {
    synchronized(foo) { 
if (operation == null) {
 // enter your code that this method has to handle...
          }
        }
      }
    }

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

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

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

当您使用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)，结果允许更好的并发性，另一方面，它变得比第一个例子更复杂……