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

不，你不应该总是这样。但是，当一个特定对象上有多个关注点时，我倾向于避免它，而这些关注点只需要对它们本身是线程安全的。例如，你可能有一个可变数据对象，它有“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.

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

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

这里已经说过，同步块可以使用用户定义的变量作为锁对象，当同步函数只使用“this”时。当然，你也可以对函数中需要同步的部分进行操作。

但是每个人都说synchronized函数和block之间没有区别，block覆盖了使用“this”作为锁对象的整个函数。这是不对的，不同的是字节码，将在这两种情况下产生。在同步块使用的情况下，应该分配本地变量，其中包含引用“this”。因此，我们会得到一个更大的函数(如果你只有几个函数，这就无关紧要了)。

你可以在这里找到更详细的解释: http://www.artima.com/insidejvm/ed2/threadsynchP.html

同步块的使用也不好，原因如下:

synchronized关键字在一个方面非常有限:当退出一个同步块时，所有等待该锁的线程都必须被解除阻塞，但只有其中一个线程可以获得锁;所有其他人都看到锁已被占用，并返回阻塞状态。这不仅仅是浪费了大量的处理周期:为解除线程阻塞而进行的上下文切换通常还涉及从磁盘调出内存，这是非常非常昂贵的。

关于这方面的更多细节，我建议你阅读这篇文章: http://java.dzone.com/articles/synchronized-considered

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