我是一个线程，生活在JVM（Java虚拟机）中， 这一段日子过得有些无聊，整个世界似乎只有这一个人，天天忙着执行代码，想休息一下都很难。
我听说人类写的代码中有些特殊的地方，叫做临界区，比如synchronized修饰的方法或者代码块，他们非常神奇，在同一时刻JVM老大只允许一个线程进入执行。
实际上，老大设置了一把锁，抢到了这把锁就可以执行，否则只能阻塞，等待别人释放锁。
老大说，阻塞就是不用干活了，老老实实地等着就行。
竟然还有这等美事！ 赶紧让我阻塞一次吧。
可是老大又说：“每次设置锁我都得和操作系统打交道，请他在内核中维护一个什么Mutex（互斥量）的东西，他还得把你们这些线程阻塞，切换，这可是一笔巨大的费用啊，所以这些锁还是少用为妙。”
我运气也不好，我不知道执行了多少代码，调用了多少函数，竟然一次也没遇到临界区!
我想也许这个程序员编程时不小心，没有考虑多线程并发的情况； 也有可能是这些程序大部分都是无状态的，多少个线程执行都没有问题。
于是我只好一直执行下去， 不知道过了多少天，我激动地发现，一个synchronized修饰的代码块终于出现了：
Account account = ...
synchronized(account){
...临界区的代码...
}
偏向锁
我满心期望别的线程已经进入了代码块，那我就可以阻塞、休息。
即使没有其他线程进入临界区，老大为我申请锁， 也得和操作系统协商什么互斥量，从用户态进入核心态，再从核心态返回用户态，总要花些功夫吧。
可是老大根本没有去找操作系统， 只是看了看这个account对象的所谓“对象头”，其中有个叫做Mark Word的东西，似乎是个什么数据结构， 里边有几个标识位，还有其他数据。
老大随手使用CAS操作把我的线程ID记录到了这个Mark Word当中，修改了标识位，然后告诉我说： 可以了，你现在拥有这把锁了，进去执行代码吧。
我惊奇地说：“老大你不和操作系统协商设置Mutex了？”
老大说：“不用了，你看现在就你一个线程进入了这个代码块，我只要记录下你的线程ID，就表示你拥有这把锁了，不用操作系统介入。”
我获得了锁，开始执行被synchronized包裹的代码块。
等到我第二次执行到这个synchronized的时候，老大只是看了一眼锁对象account的Mark Word就说：“你的线程ID还在，还持有着这个对象的锁，进入临界区执行吧。”
我连喘口气的机会都没有，只好继续执行。
老大说，这叫偏向锁，在没有别的线程竞争的时候，一直偏向我，可以让我一直执行下去。
我是多么期盼来一个新的线程来和我竞争啊！
轻量级锁
很快，机会就来了。
另外一个线程0x3704也要进入这个代码块执行，但是锁对象account 保存的是我的线程ID，他是没法进入临界区的。
我心想，我们两个至少得有一个进入阻塞状态，休息一会儿了。
但是老大还是不去操作系统协商，只是说： 我把这个偏向锁升级一下，变成一个轻量级的锁吧。
老大把锁对象account恢复成无锁状态，在我们俩的栈帧中各自分配了一个空间，叫做Lock Record， 把锁对象account的Mark Word在我们俩这里各自复制了一份，叫做Displaced Mark Word， 这名字真奇怪。
然后把我的Lock Record的地址使用CAS放到了Mark Word当中，并且把锁标志位改为00， 这其实就意味着我也已经获得了这个轻量级的锁了，可以继续进入临界区执行。
0x3704没有获得锁，但还是不阻塞，老大让他自旋几次，等待一会儿。
等到我退出临界区，释放锁的时候，需要把这个Displaced markd word 使用CAS复制回去。接下来他就可以加锁了。
我们两个交替着进入临界区，执行这段代码，相安无事，很少出现真正的竞争。
即使是出现了竞争，想获得锁的线程只要自旋几次，等待一会儿，锁就可能释放了。
很明显，如果没有竞争或者轻度的竞争，轻量级锁仅仅使用CAS操作和Lock record就避免了重量级互斥锁的开销，对JVM老大来说，确实是个好主意。
重量级锁
轻量级锁运行得挺好，我还是没有机会休息，终于有这么一天，0x3704 正在持有锁，在临界区辛苦地执行代码。 我自旋了好多次，0x3704还是没释放锁。 这时候JVM老大说： 自旋次数太多了，太浪费CPU了，接下来升级为重量级锁！
这个重量级锁需要操作系统的帮忙，依赖操作系统底层的Mutex Lock。
只见老大创建了一个monitor 对象， 把这个对象的地址更新到了Mark word当中。
锁升级了！
由于0x3704还在持有锁运行，而我终于进入了梦寐以求的状态：阻塞！ 终于可以休息一下了！
仔细一想，老大煞费心机地设置了偏向锁和轻量级锁，就是为了避免阻塞，避免操作系统的介入， 这两种锁无非就是针对这两种情况：
偏向锁： 通常只有一个线程在临界区执行
轻量级锁： 可以有多个线程交替进入临界区，在竞争不激烈的时候，稍微自旋等待一下就能获得锁。
至于重量级锁，也是我最为期待的锁，那就是出现了激烈的竞争，只好让我们去阻塞休息了。
纠错！jvm专家 你假笨指出一个错误 ，偏向锁对象头里存的不是线程id ，其实存的是JavaThread对象的指针地址。图片没法修改了，在此更正
我是一个线程，生活在JVM（Java虚拟机）中， 这一段日子过得有些无聊，整个世界似乎只有这一个人，天天忙着执行代码，想休息一下都很难。
我听说人类写的代码中有些特殊的地方，叫做临界区，比如synchronized修饰的方法或者代码块，他们非常神奇，在同一时刻JVM老大只允许一个线程进入执行。
实际上，老大设置了一把锁，抢到了这把锁就可以执行，否则只能阻塞，等待别人释放锁。
老大说，阻塞就是不用干活了，老老实实地等着就行。
竟然还有这等美事！ 赶紧让我阻塞一次吧。
可是老大又说：“每次设置锁我都得和操作系统打交道，请他在内核中维护一个什么Mutex（互斥量）的东西，他还得把你们这些线程阻塞，切换，这可是一笔巨大的费用啊，所以这些锁还是少用为妙。”
我运气也不好，我不知道执行了多少代码，调用了多少函数，竟然一次也没遇到临界区!
我想也许这个程序员编程时不小心，没有考虑多线程并发的情况； 也有可能是这些程序大部分都是无状态的，多少个线程执行都没有问题。
于是我只好一直执行下去， 不知道过了多少天，我激动地发现，一个synchronized修饰的代码块终于出现了：
Account account = ...
synchronized(account){
...临界区的代码...
}
偏向锁
我满心期望别的线程已经进入了代码块，那我就可以阻塞、休息。
即使没有其他线程进入临界区，老大为我申请锁， 也得和操作系统协商什么互斥量，从用户态进入核心态，再从核心态返回用户态，总要花些功夫吧。
可是老大根本没有去找操作系统， 只是看了看这个account对象的所谓“对象头”，其中有个叫做Mark Word的东西，似乎是个什么数据结构， 里边有几个标识位，还有其他数据。
老大随手使用CAS操作把我的线程ID记录到了这个Mark Word当中，修改了标识位，然后告诉我说： 可以了，你现在拥有这把锁了，进去执行代码吧。
我惊奇地说：“老大你不和操作系统协商设置Mutex了？”
老大说：“不用了，你看现在就你一个线程进入了这个代码块，我只要记录下你的线程ID，就表示你拥有这把锁了，不用操作系统介入。”
我获得了锁，开始执行被synchronized包裹的代码块。
等到我第二次执行到这个synchronized的时候，老大只是看了一眼锁对象account的Mark Word就说：“你的线程ID还在，还持有着这个对象的锁，进入临界区执行吧。”
我连喘口气的机会都没有，只好继续执行。
老大说，这叫偏向锁，在没有别的线程竞争的时候，一直偏向我，可以让我一直执行下去。
我是多么期盼来一个新的线程来和我竞争啊！
轻量级锁
很快，机会就来了。
另外一个线程0x3704也要进入这个代码块执行，但是锁对象account 保存的是我的线程ID，他是没法进入临界区的。
我心想，我们两个至少得有一个进入阻塞状态，休息一会儿了。
但是老大还是不去操作系统协商，只是说： 我把这个偏向锁升级一下，变成一个轻量级的锁吧。
老大把锁对象account恢复成无锁状态，在我们俩的栈帧中各自分配了一个空间，叫做Lock Record， 把锁对象account的Mark Word在我们俩这里各自复制了一份，叫做Displaced Mark Word， 这名字真奇怪。
然后把我的Lock Record的地址使用CAS放到了Mark Word当中，并且把锁标志位改为00， 这其实就意味着我也已经获得了这个轻量级的锁了，可以继续进入临界区执行。
0x3704没有获得锁，但还是不阻塞，老大让他自旋几次，等待一会儿。
等到我退出临界区，释放锁的时候，需要把这个Displaced markd word 使用CAS复制回去。接下来他就可以加锁了。
我们两个交替着进入临界区，执行这段代码，相安无事，很少出现真正的竞争。
即使是出现了竞争，想获得锁的线程只要自旋几次，等待一会儿，锁就可能释放了。
很明显，如果没有竞争或者轻度的竞争，轻量级锁仅仅使用CAS操作和Lock record就避免了重量级互斥锁的开销，对JVM老大来说，确实是个好主意。
重量级锁
轻量级锁运行得挺好，我还是没有机会休息，终于有这么一天，0x3704 正在持有锁，在临界区辛苦地执行代码。 我自旋了好多次，0x3704还是没释放锁。 这时候JVM老大说： 自旋次数太多了，太浪费CPU了，接下来升级为重量级锁！
这个重量级锁需要操作系统的帮忙，依赖操作系统底层的Mutex Lock。
只见老大创建了一个monitor 对象， 把这个对象的地址更新到了Mark word当中。
锁升级了！
由于0x3704还在持有锁运行，而我终于进入了梦寐以求的状态：阻塞！ 终于可以休息一下了！
仔细一想，老大煞费心机地设置了偏向锁和轻量级锁，就是为了避免阻塞，避免操作系统的介入， 这两种锁无非就是针对这两种情况：
偏向锁： 通常只有一个线程在临界区执行
轻量级锁： 可以有多个线程交替进入临界区，在竞争不激烈的时候，稍微自旋等待一下就能获得锁。
至于重量级锁，也是我最为期待的锁，那就是出现了激烈的竞争，只好让我们去阻塞休息了。
纠错！Jvm专家 你假笨指出一个错误 ，偏向锁对象头里存的不是线程id ，其实存的是JavaThread对象的指针地址。图片没法修改了，在此更正！
最后：
为了让学习变得轻松、高效，今天给大家免费分享一套阿里架构师传授的一套教学资源。帮助大家在成为架构师的道路上披荆斩棘。
这套视频课程详细讲解了（Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构）等这些成为架构师必备的内容！
而且还把框架需要用到的各种程序进行了打包，根据基础视频可以让你轻松搭建分布式框架环境，像在企业生产环境一样进行学习和实践。
加Java高级交流群：725633148 就可以马上免费获得这套价值一万八的内部教材！