唯一的区别是:同步块允许颗粒状锁定，不像同步方法

基本上同步块或方法被用来编写线程安全的代码，以避免内存不一致的错误。

这个问题很老了，在过去的7年里，很多事情都发生了变化。 为了线程安全，引入了新的编程结构。

您可以通过使用高级并发API而不是同步块来实现线程安全。该文档页提供了实现线程安全的良好编程结构。

锁对象支持简化许多并发应用程序的锁定习惯用法。

executor为启动和管理线程定义了高级API。concurrent提供的执行器实现提供了适合大型应用程序的线程池管理。

并发集合使管理大型数据集合变得更容易，并且可以大大减少同步的需要。

原子变量具有最小化同步和帮助避免内存一致性错误的特性。

ThreadLocalRandom(在JDK 7中)提供了从多个线程有效生成伪随机数的功能。

更好的synchronized替代品是ReentrantLock，它使用Lock API

一个可重入互斥锁，其基本行为和语义与使用同步方法和语句访问的隐式监视锁相同，但具有扩展功能。

锁的例子:

class X {
   private final ReentrantLock lock = new ReentrantLock();
   // ...

   public void m() {
     lock.lock();  // block until condition holds
     try {
       // ... method body
     } finally {
       lock.unlock()
     }
   }
 }

其他编程结构也可以参考java.util.concurrent和java.util.concurrent.atomic包。

参考这个相关的问题:

同步vs锁定

注意:静态同步方法和块工作在Class对象上。

public class MyClass {
   // locks MyClass.class
   public static synchronized void foo() {
// do something
   }

   // similar
   public static void foo() {
      synchronized(MyClass.class) {
// do something
      }
   }
}

当java编译器将源代码转换为字节码时，它处理同步方法和同步块的方式非常不同。

当JVM执行一个同步方法时，执行线程识别出该方法的method_info结构体设置了ACC_SYNCHRONIZED标志，然后它自动获取对象的锁，调用该方法，并释放锁。如果发生异常，线程自动释放锁。

另一方面，同步方法块绕过了JVM对获取对象锁和异常处理的内置支持，并要求显式地用字节代码编写功能。如果读取带有同步块的方法的字节代码，您将看到十多个额外的操作来管理此功能。

这显示了生成同步方法和同步块的调用:

public class SynchronizationExample {
    private int i;

    public synchronized int synchronizedMethodGet() {
        return i;
    }

    public int synchronizedBlockGet() {
        synchronized( this ) {
            return i;
        }
    }
}

synchronizedMethodGet()方法生成以下字节代码:

0:  aload_0
1:  getfield
2:  nop
3:  iconst_m1
4:  ireturn

下面是synchronizedBlockGet()方法的字节代码:

0:  aload_0
1:  dup
2:  astore_1
3:  monitorenter
4:  aload_0
5:  getfield
6:  nop
7:  iconst_m1
8:  aload_1
9:  monitorexit
10: ireturn
11: astore_2
12: aload_1
13: monitorexit
14: aload_2
15: athrow

One significant difference between synchronized method and block is that, Synchronized block generally reduce scope of lock. As scope of lock is inversely proportional to performance, its always better to lock only critical section of code. One of the best example of using synchronized block is double checked locking in Singleton pattern where instead of locking whole getInstance() method we only lock critical section of code which is used to create Singleton instance. This improves performance drastically because locking is only required one or two times.

在使用同步方法时，如果混合使用静态同步方法和非静态同步方法，则需要格外小心。

在实际应用中，同步方法相对于同步块的优势在于它们更能抵抗白痴;因为您不能选择任意对象来锁定，所以您不能滥用synchronized方法语法来做一些愚蠢的事情，比如锁定字符串文字或锁定从线程下面更改的可变字段的内容。

另一方面，使用同步方法，您无法保护锁不被任何可以获得对象引用的线程获取。

因此，在方法上使用synchronized作为修饰符可以更好地保护你的奶牛免受伤害，而将synchronized块与私有final锁对象结合使用则可以更好地保护你自己的代码免受奶牛的伤害。

唯一真正的区别是同步块可以选择在哪个对象上同步。同步方法只能使用'this'(或同步类方法的相应Class实例)。例如，它们在语义上是等价的:

synchronized void foo() {
  ...
}

void foo() {
    synchronized (this) {
      ...
    }
}

后者更灵活，因为它可以竞争任何对象(通常是成员变量)的关联锁。它也更细粒度，因为您可以在块之前和块之后执行并发代码，但仍然在方法中。当然，您也可以通过将并发代码重构为单独的非同步方法来轻松地使用同步方法。使用任何使代码更容易理解的方法。

谁能告诉我同步方法比同步块的优势与一个例子?谢谢。

与块相比，使用同步方法并没有明显的优势。

也许唯一的一点(但我不认为这是优点)是您不需要包含对象引用this。

方法:

public synchronized void method() { // blocks "this" from here.... 
    ...
    ...
    ...
} // to here

布洛克:

public void method() { 
    synchronized( this ) { // blocks "this" from here .... 
        ....
        ....
        ....
    }  // to here...
}

看到了吗?一点好处都没有。

块确实比方法有优势，主要是灵活性，因为你可以使用另一个对象作为锁，而同步方法将锁定整个对象。

比较:

// locks the whole object
... 
private synchronized void someInputRelatedWork() {
    ... 
}
private synchronized void someOutputRelatedWork() {
    ... 
}

vs.

// Using specific locks
Object inputLock = new Object();
Object outputLock = new Object();

private void someInputRelatedWork() {
    synchronized(inputLock) { 
        ... 
    } 
}
private void someOutputRelatedWork() {
    synchronized(outputLock) { 
        ... 
    }
}

另外，如果方法增长了，你仍然可以保持同步段的分离:

 private void method() {
     ... code here
     ... code here
     ... code here
    synchronized( lock ) { 
        ... very few lines of code here
    }
     ... code here
     ... code here
     ... code here
     ... code here
}