前言
在java代码块中，synchronized的使用无非有两个：
1.通过对一个对象进行加锁来实现同步
synchronized(object){
//代码
}
2.通过对一个方法进行synchronized声明，进而对一个方法进行加锁实现同步
public synchronized void test(){
//代码
}
无论是对一个对象进行加锁，还是对一个方法进行加锁，实际上，都是对对象进行加锁。
对于方式2，虚拟机会根据synchronized修饰的实例方法还是类方法，去取对应的实例对象或者Class对象进行加锁。
对于synchronized这个关键字，大家之前应该都接触过或者听说过，他是一个重量级锁，开销很大，建议大家少用点，但大家可能也听说过，在JDK1.6之后，对synchronized关键字进行了优化，那么它是怎么优化的呢？为何重量级锁开销就大呢？
基于这些问题，我们一一展开研究。
锁对象
刚才说到，锁实际上是加在对象上的，那么被加锁的对象就被称为锁对象，在java中，任何一个对象都能称为锁对象。我们来简单看一下java中的对象的结构，来理解虚拟机是如何知道这个对象就是一个锁对象。
java对象在内存中存储结构主要有以下三个部分：
- 对象头
- 实例数据
- 填充数据
右上图画了两个对象，只看其中一个即可：
- Markword（锁相关）
- 元数据指针：指向当前实例所属的类
- 实例数据：我们平常看到的
我们关注的重点是对象头，对象中关于锁的信息都存在了对象头的markword里面。
可以看到markword里面包含的信息很多，我们把它简单的理解为记录锁信息的标记即可，上图展示的是32位虚拟机下的java对象内存，Markword从有限的32bit中划分出2bit，专门用作锁标志位，通俗的讲就是标记当前锁的状态。
正是因为每个java对象都有Markword标记锁状态(把自己当作锁)，所以java中任意对象都可以作为synchronized的锁：
LockObject lockObject = new LockObject();//随便创建一个对象
synchronized(lockObject){
//代码
}
当我们创建一个对象时，该对象的Markword关键数据如下：
| bit fields | 是否偏向锁 | 锁标志位 |
|---|---|---|
| hash | 0 | 01 |
从上图可以看出，偏向锁的标志位是 01，状态是0，表示该对象还没有加上偏向锁。(1 表示被加上偏向锁)。该对象被创建出来的那一刻，就有了偏向锁的标志，这也说明了所有对象都是可偏向的，但所有的对象的状态都为0，也同时所有被创建的对象的偏向锁并没有生效。
偏向锁
当线程执行到临界区(critical section)时，此时会利用CAS（compare and swap）操作，将线程ID插入到Markword中，同时修改偏向锁的标志。
所谓临界区，就是只允许一个线程进去执行操作区域，即同步代码块，CAS是一个原子性操作。
此时Markword的结构信息如下：
| bit fields | 是否偏向锁 | 锁标志位 |
|---|---|---|
| threadId | 1 | 01 |
此时偏向锁的状态为1，说明对象的偏向锁生效了，同时也可以看到，哪个线程获得了该对象的锁。
什么是偏向锁
偏向锁是JDK1.6引入的一项锁优化，其中的"偏"是偏心的偏，也就说，这个锁会偏向于第一个获得它的线程，在接下来的执行过程中，假如该锁没有被其他线程锁获取，没有其他线程来竞争该锁，那么持有偏向锁的线程将永远不需要进行同步操作。
在此线程之后的执行过程中，如果再次进入或者退出同一块同步代码块，并不在需要进行加锁或者解锁的操作，而是会做以下的步骤：
- Load-and-test ，判断一下当前线程id与Markword当中的线程id是否一致
- 如果一致，说明此线程已经获得锁，继续执行下面的代码
- 如果不一致，则要检查一下对象是否还是可偏向，如果还未偏向，执行第一获取锁的操作。
如果此对象已经偏向了，并且不是偏向自己，则说明有了竞争，此时可能就要根据另外线程的情况，可能是重新偏向，也有可能是做偏向撤销，但大部分情况是升级成轻量级锁。
可以看出，偏向锁针对一个线程而言，线程获得锁之后就不会再有其他的操作了，这样可以省略很多开销。假如有两个线程来竞争该锁，那么偏向锁就会失效，进而升级成轻量级锁。
为什么要这样做呢？因为大部分情况下，都是同一个线程进入同一块同步代码。
在Jdk1.6中，偏向锁的开关是默认开启的，适用于只有一个线程访问同步块的场景。
锁膨胀
上面说过，当出现两个线程竞争锁，那么偏向锁就会失效，此时锁就会膨胀， 升级为轻量级锁，这就是锁膨胀。
锁撤销
由于偏向锁失效了，那么接下来就是该把锁撤销了。锁撤销的开销花费还是挺大的，大概过程如下：
- 在一个安全点停止拥有锁的线程。
- 遍历线程栈，如果存在锁记录的话，需要修复锁记录和Markword，使其变成无锁状态。
- 唤醒当前线程，将当前锁升级成轻量级锁。
所以，如果某些同步代码块大多数情况下都是两个及以上线程竞争的话，那么偏向锁就是一种累赘，对于这种情况，可以一开始就把偏向锁这个默认功能关闭。
轻量级锁
锁撤销升级为轻量级锁之后，那么对象的Markword也会进行相应的变化，大致过程如下：
- 线程在自己的桢栈中创建锁记录LockRecord
- 将锁对象的对象头中的Markword复制到线程刚刚创建的所记录中
- 将锁记录中的owner指针指向锁对象
- 将锁对象中对象头的Markword替换为执行锁记录的指针。
之后Mark’word如下：
| bit fields | 锁标志位 |
|---|---|
| 指向LockRecord的指针 | 00 |
锁标志位00 表示轻量级锁
轻量级锁主要分为两种：
- 自旋锁
- 自适应自旋锁
下面一一介绍
自旋锁
所谓自旋，就是当另外一个线程来竞争锁时，这个线程会在原地循环等待，而不是把该线程给阻塞，直到那个获得锁的线程释放锁之后，这个线程就可以马上获得锁。
注意，锁在原地循环等待的时候，会很消耗cpu。
所以，轻量级锁适用于同步代码块执行很快的场景，这样线程在原地等待很短的时间就能获得锁。
大部分同步代码块的执行时间很短很短，才会有轻量级锁这个东西出现。
自旋锁的一些问题
- 同步代码块执行的很慢，其他线程在循环等待的时候会占用cpu
- 本来一个线程释放锁之后，当前线程还是能够获得锁的，但是假如有多个线程同时竞争锁，那么有可能当前线程获取不到锁，甚至有可能一直获取不到锁，原地等待空消耗cpu。
基于上面的问题，必须给线程空循环设置一个循环次数，当线程超过这个次数，我们就认为不再适用自旋锁，此时锁会再次膨胀，升级为重量级锁。
默认情况下，自旋的次数为10次，用户可以通过-XX:PreBlockSpin来进行更改。
自适应自旋锁
自适应自旋锁是线程空循环等待的自旋次数并非是固定的，而是根据实际情况来改变自旋等待的次数。
大概原理是这样的：
假如线程A刚刚成功获得一个锁，当它把锁释放了之后，线程B获得该锁，并且线程B在运行过程中，此时线程A又想来获得该锁，但是线程B还没有释放锁，所以线程A只能自旋等待，但是虚拟机认为，由于线程A刚刚获得过锁，那么线程A自旋很有可能再次获得该锁，所以会延长线程A的自旋次数。
另外，如果对于某一个锁，一个线程自旋之后，很少成功获得该锁，那么以后这个线程要获取该锁时，是有可能直接忽略掉自旋过程，直接升级为重量级锁，以免空循环等待浪费资源。
轻量级锁也成为非阻塞同步、乐观锁，因为这个过程并没有阻塞线程，而是让线程空循环等待，串行执行。
重量级锁
轻量级锁膨胀之后，就升级为重量级锁了。重量级锁是依赖对象内部的monitor锁来实现的，而monitor又是依赖操作系统的互斥锁来实现的，所以重量级锁也被称为互斥锁。
为什么说重量级锁开销大呢？
当系统监测到锁是重量级锁之后，会把等待想要获得锁的线程进行阻塞，被阻塞的线程不会消耗cpu，但是阻塞或者唤醒一个线程时，都需要操作系统来帮忙，这就需要从用户态转换到内核态，而转换状态是需要消耗很多时间的，有可能比用户执行代码的时间还要长，这就是为什么说重量级锁开销大的原因。
重量级锁也称为阻塞同步、悲观锁。
扫一扫
784
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
