最近在学习jvm，发现随着对虚拟机底层的了解，对java的多线程也有了全新的认识，原来一个小小的synchronized关键字里别有洞天。决定把自己关于java多线程的所学整理成一篇文章，从最基础的为什么使用多线程，一直深入讲解到jvm底层的锁实现。

为什么要使用多线程？可以简单的分两个方面来说：

其实多线程根本的问题只有一个：线程间变量的共享

java里的变量可以分3类：

下图是jvm的内存区域划分图：

根据各个区域的定义，我们可以知道：

“方法区”和“堆”都属于线程共享数据区，“虚拟机栈”属于线程私有数据区。

因此，局部变量是不能多个线程共享的，而类变量和实例变量是可以多个线程共享的。事实上，在java中，多线程间进行通信的唯一途径就是通过类变量和实例变量。

也就是说，如果一段多线程程序中如果没有类变量和实例变量，那么这段多线程程序就一定是线程安全的。

以Web开发的Servlet为例，一般我们开发的时候，自己的类继承HttpServlet之后，重写doPost()、doGet()处理请求，不管我们在这两个方法里写什么代码，只要没有操作类变量或实例变量，最后写出来的代码就是线程安全的。如果在Servlet类里面加了实例变量，就很可能出现线程安全性问题，解决方法就是把实例变量改为ThreadLocal变量，而ThreadLocal实现的含义就是让实例变量变成了“线程私有”的，即给每一个线程分配一个自己的值。

?

?现在我们知道：其实多线程根本的问题只有一个：线程间变量的共享，这里的变量，指的就是类变量和实例变量，后续的一切，都是为了解决类变量和实例变量共享的安全问题。

现在唯一的问题就是要让多个线程安全的共享变量（下文中的变量一般特指类变量和实例变量），上文提到了一种ThreadLocal的方式，其实这种方式并不是真正的共享，而是为每个线程分配一个自己的值。

比如现在有一个特别简单的需求，有一个类变量a=0，现在启动5个线程，每个线程执行a++；如果用ThreadLocal的方式，最后的结果就是5个线程都拥有一份自己的a值，最终结果都是1，这显然不符合我们的预期。

那么如果不使用ThreadLocal呢？直接声明一个类变量a=0，然后让5个线程分别去执行a++；这样结果依旧不对，而且结果是不确定的，可能是1,2,3,4,5中的任一个。这种情况叫做竞态条件(Race Condition)，要理解竞态条件先要理解Java内存模型：

要理解java的内存模型，可以类比计算机硬件访问内存的模型。由于计算机的cpu运算速度和内存io速度有几个数量级的差距，因此现代计算机都不得不加入一层尽可能接近处理器运算速度的高速缓存来做缓冲：将内存中运算需要使用的数据先复制到缓存中，当运算结束后再同步回内存。如下图：

因为jvm要实现跨硬件平台，因此jvm定义了自己的内存模型，但是因为jvm的内存模型最终还是要映射到硬件上，因此jvm内存模型几乎与硬件的模型一样：

每个java线程都有一份自己的工作内存，线程访问变量的时候，不能直接访问主内存中的变量，而是先把主内存的变量复制到自己的工作内存，然后操作自己工作内存里的变量，最后再同步给主内存。

现在就可以解释为什么5个线程执行a++最后结果不一定是5了，因为a++可以分解为3步操作：

而5个线程并发执行的时候完全有可能5个线程都先执行了第一步，这样5个线程的工作内存里a的初始值都是0，然后执行a=a+1后在工作内存里的运算结果都是1，最后同步回主内存的值肯定也是1。

而避免这种情况的方法就是：在多个线程并发访问a的时候，保证a在同一个时刻只被一个线程使用。

同步(synchronized)就是：在多个线程并发访问共享数据的时候，保证共享数据在同一个时刻只被一个线程使用。

为了保证共享数据在同一时刻只被一个线程使用，我们有一种很简单的实现思想，就是在共享数据里保存一个锁，当没有线程访问时，锁是空的，当有第一个线程访问时，就在锁里保存这个线程的标识并允许这个线程访问共享数据。在当前线程释放共享数据之前，如果再有其他线程想要访问共享数据，就要等待锁释放。

我们把这种思想的三个关键点抽出来：

可以说jvm中的三种锁都是以上述思想为基础的，只是实现的“重量级”不同，jvm中有以下三种锁(由上到下越来越“重量级”)：

其中重量级锁是最初的锁机制，偏向锁和轻量级锁是在jdk1.6加入的，可以选择打开或关闭。如果把偏向锁和轻量级锁都打开，那么在java代码中使用synchronized关键字的时候，jvm底层会尝试先使用偏向锁，如果偏向锁不可用，则转换为轻量级锁，如果轻量级锁不可用，则转换为重量级锁。具体转换过程下面会讲。

要想深入了解这3种锁需要了解对象的内存结构（MarkWord头），会涉及到字节码的内部存储格式，但是其实我觉得脱离细节的实现，单从原理上理解这三个锁是很容易的，只需要了解两个大体的概念：

MarkWord：java中的每个对象在存储的时候，都有统一的数据结构。每个对象都包含一个对象头，称为MarkWord,里面会保存关于这个对象的加锁信息。

Lock Record: 即锁记录，每个线程在执行的时候，会有自己的虚拟机栈，当个方法的调用相当于虚拟机栈里的一个栈帧，而Lock Record就位于栈帧上，是用来保存关于这个线程的加锁信息。

最初jvm没有前两种锁（前两种都是jdk1.6才引入的），只有重量级锁。

我们之前给出了同步基本思想的三个点，我们也说了jvm的三种锁都是以基本思想为基础的，而这三种锁在第1、2点的实现上本质上是一样的：

?

而区分这三种锁的关键，就是同步基本思想的第三点：

　　 3.其他线程访问已加锁共享数据要等待锁释放

这里的等待锁释放是一个抽象的说法，并没有严格要求怎么等待。而重量级锁因为使用了互斥量，这里的等待就是线程阻塞。使用互斥量可以保证所有情况下的并发安全，但是使用互斥量会带来较大的性能消耗。而且在实际的项目代码中，很可能一段本来不会有并发情况的代码被加了锁，这样每次使用互斥量就白白消耗了性能。能不能先假设被加锁的代码不会有并发的情况，等到发现有并发的时候再使用互斥量呢？答案是可以的，轻量级锁和偏向锁都是基于这种假设来实现的。

轻量级锁的核心思想就是“被加锁的代码不会发生并发，如果发生并发，那就膨胀成重量级锁(膨胀指的锁的重量级上升，一旦升级，就不会降级了)”。

轻量级锁依赖了一种叫做CAS(compare and swap)的操作，这个操作是由底层硬件提供相关指令实现的：

CAS操作需要3个参数，分别是内存位置V,旧的期望值A和新值B。CAS指令执行时，当且仅当V当前值符合旧值A时，处理器用新值B更新V的值，否则不执行更新。上述过程是一个原子操作。