一、为什么要使用 synchronized
使用synchronized的原因在于：它能够确保多个线程在同一时刻，只能有一个线程处于方法或者同步块中，它保证了线程对变量访问的可见性和排他性。
二、synchronized 原理
在JDK 1.6之前，synchronized的实现是基于对象上的监视器，这也被称为重量锁。默认情况下，每一个对象都有一个关联的Monitor，而每个Monitor包含了一个EntryCount计数器，它是synchronized实现可重入的关键。
在JDK 1.6之后，对锁进行了一系列优化的措施，通过引入自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销。
这些优化措施最终的目的是减少锁操作的开销，然而它所改变的只是锁的实现方式，但是加锁和解锁这一基本原则是没有改变的。这篇文章主要是介绍synchronized的使用，因此，在后面的介绍中，我们还是按照比较容易理解的重量锁的方式进行分析，在之后的文章中，我们再来谈一下优化后的实现策略。
2.1 进入同步方法或者代码块
当一个线程执行某个对象的同步方法或者代码块时，会先检查这个对象所关联的Monitor's EntryCount是否为0：
- 如果
EntryCount为0，那么该线程就会将Monitor’s EntryCount设置为1，并成为该Monitor的所有者，接着执行该方法或者代码块中的语句。 - 如果
EntryCount不为0，这时会去检查对象所关联的Monitor的持有者是哪一个线程： - 第一种情况：持有该
Monitor的线程就是当前正在尝试获取Monitor的线程，那么将EntryCount的数值加1，继续执行方法或者代码块中的语句。 - 第二种情况：持有该
Monitor的是其它的线程，那么该线程进入阻塞状态，直到EntryCount的数值变为0。
2.2 退出同步方法或者代码块
当一个线程从同步方法或者代码块退出时，会将EntryCount减1，如果EntryCount变为0，那么该线程会释放它所持有的Monitor。之前那些阻塞在synchronized的线程会尝试去获取Monitor，成功获取Monitor的线程可以进入同步方法或者代码块。
三、synchronized 使用
对于synchronized的使用，我们有两种分类方法：
- 根据使用场景分类
- 根据
Monitor关联的对象分类。
3.1 根据使用场景分类
很多介绍synchronized的文章，都是通过使用场景进行分类的，一般来说可以分为如下四种使用场景，而每种场景下根据Monitor所关联的对象不同，又会衍生出另外的用法：
- 静态方法
//静态方法，使用的是Class类锁 synchronized public static void staticMethod() {}复制代码 - 静态方法代码块
private static final byte[] mStaticLockByte = new byte[1]; //静态方法代码块1，使用的是Class类锁 public static void staticBlock1() { synchronized (SynchronizedObject.class) {} } //静态方法代码块2，使用的是内部静态变量锁 public static void staticBlock2() { synchronized (mStaticLockByte) {} }复制代码 - 普通方法
//普通方法，使用的是调用该方法的对象锁 synchronized public void method() {}复制代码 - 普通方法代码块
private static final byte[] mStaticLockByte = new byte[1]; private final byte[] mLockByte = new byte[1]; //普通方法代码块1，使用的是Class类锁 public void block1() { synchronized (SynchronizedObject.class) {} } //普通方法代码块2，使用的是mLockByte的变量锁 public void block2() { synchronized (mLockByte) {} //变量需要声明为final } //普通方法代码块3，使用的是mStaticLockByte的变量锁 public void block3() { synchronized (mStaticLockByte) {} } //普通方法代码块4，使用的是调用该方法的对象锁 public void block4() { synchronized (this) {} }复制代码 3.2 根据 Monitor 关联的对象分类
根据使用场景进行分类，主要是为了让大家知道如何使用synchronized关键字，然而要真正地理解synchronized，就需要结合第二节谈到的synchronized原理，其实3.1中谈到的多种场景，都是和Monitor有关，那么从和Monitor关联的对象来看，我们重新对3.1中的8种场景重新进行分类：
Class对象：- 静态方法
- 静态方法代码块1 -
SynchronizedObject.class - 普通方法代码块1 -
SynchronizedObject.class - 调用方法的对象
- 普通方法
- 普通方法代码块4 -
this - 静态对象
- 静态方法代码块2 -
mStaticLockByte - 普通方法代码块3 -
mStaticLockByte - 非静态对象
- 普通方法代码块1 -
mLockByte
如果使用场景属于上面的同一个分类当中，那么才有可能产生线程阻塞在synchronized关键字的情况，举一个例子，如果A线程通过静态方法访问（分类一）并且没有从该方法退出：
- 这时
B线程是通过一个对象的普通方法来访问（分类二），那么是不会阻塞的，这是因为调用该方法的对象所关联的Monitor没有被持有。 - 如果
B线程使用的是静态方法代码块来访问，而该静态方法代码块使用的是SynchronizedObject.class来修饰（分类一），由于这两种使用场景是属于同一个分类，那么就会B线程就会进入阻塞状态，这是因为SynchronizedObject类所关联的Monitor已经被A线程持有了。
四、小结
从表面上来看，synchronized的使用可以简单地分为同步方法和同步代码块，但是究竟在什么情况下会导致一个线程在synchronized上阻塞，则需要分析synchronized方法所尝试获取的Monitor的是否已经被其它线程持有了。