每当在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
我只想提到一种可能的解决方案，用于在没有依赖关系的原子代码部分中惟一的私有引用。您可以使用带锁的静态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
}
不，你不应该总是这样。但是，当一个特定对象上有多个关注点时，我倾向于避免它，而这些关注点只需要对它们本身是线程安全的。例如，你可能有一个可变数据对象，它有“label”和“parent”字段;它们需要是线程安全的，但是改变其中一个不需要阻止另一个被写入/读取。(在实践中，我将通过声明字段为volatile和/或使用java.util来避免这种情况。concurrent的AtomicFoo包装器)。
一般来说，同步有点笨拙，因为它只是一个大的锁定，而不是仔细考虑如何允许线程相互工作。使用synchronized(this)更加笨拙和反社会，因为它表示“当我持有锁时，没有人可以更改这个类的任何内容”。你需要多久做一次?
I would much rather have more granular locks; even if you do want to stop everything from changing (perhaps you're serialising the object), you can just acquire all of the locks to achieve the same thing, plus it's more explicit that way. When you use synchronized(this), it's not clear exactly why you're synchronizing, or what the side effects might be. If you use synchronized(labelMonitor), or even better labelLock.getWriteLock().lock(), it's clear what you are doing and what the effects of your critical section are limited to.
这里已经说过，同步块可以使用用户定义的变量作为锁对象，当同步函数只使用“this”时。当然，你也可以对函数中需要同步的部分进行操作。
但是每个人都说synchronized函数和block之间没有区别，block覆盖了使用“this”作为锁对象的整个函数。这是不对的，不同的是字节码，将在这两种情况下产生。在同步块使用的情况下，应该分配本地变量，其中包含引用“this”。因此，我们会得到一个更大的函数(如果你只有几个函数，这就无关紧要了)。
你可以在这里找到更详细的解释:
http://www.artima.com/insidejvm/ed2/threadsynchP.html
同步块的使用也不好，原因如下:
synchronized关键字在一个方面非常有限:当退出一个同步块时，所有等待该锁的线程都必须被解除阻塞，但只有其中一个线程可以获得锁;所有其他人都看到锁已被占用，并返回阻塞状态。这不仅仅是浪费了大量的处理周期:为解除线程阻塞而进行的上下文切换通常还涉及从磁盘调出内存，这是非常非常昂贵的。
关于这方面的更多细节，我建议你阅读这篇文章:
http://java.dzone.com/articles/synchronized-considered
