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

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

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

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

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

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

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

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

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

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

这取决于你想做的任务，但我不会用它。此外，检查您想要完成的线程保存是否不能首先通过同步(此)来完成?API中也有一些不错的锁，可能会帮助到你:)

如果可能的话，让你的数据不可变(最终变量) 如果你不能避免跨多个线程共享数据的突变，使用高级编程结构[例如，粒度锁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包。

我只想提到一种可能的解决方案，用于在没有依赖关系的原子代码部分中惟一的私有引用。您可以使用带锁的静态Hashmap和名为atomic()的简单静态方法，该方法使用堆栈信息(完整的类名和行号)自动创建所需的引用。然后，您可以在同步语句中使用此方法，而无需写入新的锁对象。

// Synchronization objects (locks)
private static HashMap<String, Object> locks = new HashMap<String, Object>();
// Simple method
private static Object atomic() {
    StackTraceElement [] stack = Thread.currentThread().getStackTrace(); // get execution point 
    StackTraceElement exepoint = stack[2];
    // creates unique key from class name and line number using execution point
    String key = String.format("%s#%d", exepoint.getClassName(), exepoint.getLineNumber()); 
    Object lock = locks.get(key); // use old or create new lock
    if (lock == null) {
        lock = new Object();
        locks.put(key, lock);
    }
    return lock; // return reference to lock
}
// Synchronized code
void dosomething1() {
    // start commands
    synchronized (atomic()) {
        // atomic commands 1
        ...
    }
    // other command
}
// Synchronized code
void dosomething2() {
    // start commands
    synchronized (atomic()) {
        // atomic commands 2
        ...
    }
    // other command
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如果你已经决定:

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

那么我就不认为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.

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