文章目录
- 一、synchronized 实现同步示例
- 二、synchronized 典型错误示例
- 三、Java 对象头与 Monitor
- 四、synchronized代码块底层原理
- 五、synchronized方法底层原理
- 六、Java虚拟机对synchronized的优化
一、synchronized 实现同步示例
public class MyThread extends Thread{
private int count = 0;
@ Override
public synchronized void run() {
for (int i = 0; i < 5; i++) {
try {
System.out.println("线程名:"+Thread.currentThread().getName() + ":" + (count++));
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
public class MyTest
public static void main(String[] args) {
MyThread myThread = new MyThread();
Thread thread1 = new Thread( myThread, "SyncThread1");
Thread thread2 = new Thread( myThread, "SyncThread2");
thread1.start();
thread2.start();
}
}
分析:
通过
new MyThread()
创建了一个对象myThread
,这时候堆中就存在了共享资源myThread
,然后对myThread
对象创建两个线程,那么thread1线程和thread2线程就会共享myThread
。thread1.start()
和thead2.start()
开启了两个线程,CPU会随机调度这两个线程。假如thread1
先获得synchronized
锁,那么thread1先把run()
执行完,然后释放锁。接着thread1
获得synchronized
锁,thread2把run()
执行完,然后释放锁。
二、synchronized 典型错误示例
public class MyThread implements Runnable{
private int count = 0;
@ Override
public synchronized void run() {
for (int i = 0; i < 5; i++) {
try {
System.out.println("线程名:"+Thread.currentThread().getName() + ":" + (count++));
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
public class MyTest
public static void main(String[] args) {
System.out.println("使用关键字synchronized每次调用进行new SyncThread()");
MyThread myThread1 = new MyThread();
MyThread myThread2 = new MyThread();
Thread thread1 = new Thread(myThread1, "SyncThread1");
Thread thread2 = new Thread(myThread2, "SyncThread2");
thread1.start();
thread2.start();
}
}
分析:
通过
new MyThread()
创建了两个对象myThread1
和myThread2
,这时候堆中就存在了共享资源myThread1
和myThread2
,然后对myThread1
对象创建一个线程thread1
,对myThread2
对象创建一个线程thread2
,那么thread1
线程就会共享myThread1
,thread2
线程就会共享myThread2
,thread1.start()
和thead2.start()
开启了两个线程,CPU会随机调度这两个线程。那么thread1
线程在执行的时候就会获取共享资源myThread1.run()
的锁,thread2
线程在执行的时候就会获取共享资源myThread2.run()
的锁,显然两个线程共享的都不是同一个资源。
三、Java 对象头与 Monitor
下面先来了解一个概念Java对象头,这对深入理解synchronized实现原理非常关键。
在JVM中,对象在内存中的布局分为三块区域:对象头、实例数据、填充数据
- 实例变量:存放类的属性数据信息,包括父类的属性信息.
- 填充数据:由于虚拟机要求对象起始地址必须是8字节的整数倍。
而对于顶部,则是Java头对象
,它实现synchronized的锁对象的基础,这点我们重点分析它,一般而言,synchronized使用的锁对象是存储在Java对象头里的,jvm中采用2个字来存储对象头(如果对象是数组则会分配3个字,多出来的1个字记录的是数组长度),其主要结构是由Mark Word
和 Class Metadata Address
组成,其结构说明如下表:
其中Mark Word
字段的存储结构会根据锁状态而发生变化:
这里我们重点分析一下重量级锁也就是通常说synchronized的对象锁
,锁标识位为10,其中指针指向的是monitor对象
的起始地址。
每个对象都存在着一个 monitor 与之关联,对象与其 monitor 之间的关系有存在多种实现方式,如monitor可以与对象一起创建销毁或当线程试图获取对象锁时自动生成,但当一个 monitor 被某个线程持有后,它便处于锁定状态。
在Java虚拟机(HotSpot)中,monitor是由ObjectMonitor实现的,其主要数据结构如下(位于HotSpot虚拟机源码ObjectMonitor.hpp文件,C++实现的)
ObjectMonitor() {
_header = NULL;
_count = 0; //记录个数
_waiters = 0,
_recursions = 0;
_object = NULL;
_owner = NULL;
_WaitSet = NULL; //处于wait状态的线程,会被加入到_WaitSet
_WaitSetLock = 0 ;
_Responsible = NULL ;
_succ = NULL ;
_cxq = NULL ;
FreeNext = NULL ;
_EntryList = NULL ; //处于等待锁block状态的线程,会被加入到该列表
_SpinFreq = 0 ;
_SpinClock = 0 ;
OwnerIsThread = 0 ;
}
ObjectMonitor
中有两个队列,_WaitSet
(等待状态) 和 _EntryList
(阻塞状态),都是用来保存ObjectWaiter对象列表
( _WaitSet
和 _EntryList
中的线程都会被封装成ObjectWaiter对象
),_owner
指向持有ObjectMonitor对象
的线程,当多个线程同时访问一段同步代码时,首先会进入_EntryList
集合,当线程获取到对象的monitor
后进入_Owner
区域,并把monitor
中的owner
变量设置为当前线程,同时monitor
中的计数器count
加1,若线程调用 wait()
方法,将释放当前持有的monitor
,owner
变量恢复为null,count
自减1,同时该线程进入WaitSet
集合中等待被唤醒。若当前线程执行完毕也将释放monitor
(锁)并复位变量的值,以便其他线程进入获取monitor
(锁)。
四、synchronized代码块底层原理
public class SyncCodeBlock {
public int i;
public void syncTask(){
//同步代码库
synchronized (this){
i++;
}
}
}
编译上述代码并使用javap反编译后得到字节码如下(这里我们省略一部分没有必要的信息):
Classfile /Users/zejian/Downloads/Java8_Action/src/main/java/com/zejian/concurrencys/SyncCodeBlock.class
Last modified 2017-6-2; size 426 bytes
MD5 checksum c80bc322c87b312de760942820b4fed5
Compiled from "SyncCodeBlock.java"
public class com.zejian.concurrencys.SyncCodeBlock
minor version: 0
major version: 52
flags: ACC_PUBLIC, ACC_SUPER
Constant pool:
//........省略常量池中数据
//构造函数
public com.zejian.concurrencys.SyncCodeBlock();
descriptor: ()V
flags: ACC_PUBLIC
Code:
stack=1, locals=1, args_size=1
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
LineNumberTable:
line 7: 0
//===========主要看看syncTask方法实现================
public void syncTask();
descriptor: ()V
flags: ACC_PUBLIC
Code:
stack=3, locals=3, args_size=1
0: aload_0
1: dup
2: astore_1
3: monitorenter //注意此处,进入同步方法
4: aload_0
5: dup
6: getfield #2 // Field i:I
9: iconst_1
10: iadd
11: putfield #2 // Field i:I
14: aload_1
15: monitorexit //注意此处,退出同步方法
16: goto 24
19: astore_2
20: aload_1
21: monitorexit //注意此处,退出同步方法
22: aload_2
23: athrow
24: return
Exception table:
//省略其他字节码.......
}
SourceFile: "SyncCodeBlock.java"
我们主要关注字节码中的如下代码
3: monitorenter //进入同步方法
//..........省略其他
15: monitorexit //退出同步方法
16: goto 24
//省略其他.......
21: monitorexit //退出同步方法
从字节码中可知同步语句块的实现使用的是monitorenter
和 monitorexit
指令,其中monitorenter
指令指向同步代码块的开始位置,monitorexit
指令则指明同步代码块的结束位置,当执行monitorenter
指令时,当前线程将试图获取 objectref
(即对象锁) 所对应的 monitor
的持有权,当 objectref
的 monitor
的进入计数器为 0,那线程可以成功取得 monitor
,并将计数器值设置为 1,取锁成功。如果当前线程已经拥有 objectref
的 monitor
的持有权,那它可以重入这个 monitor
(关于重入性稍后会分析),重入时计数器的值也会加 1。倘若其他线程已经拥有 objectref
的 monitor
的所有权,那当前线程将被阻塞,直到正在执行线程执行完毕,即monitorexit
指令被执行,执行线程将释放 monitor
(锁)并设置计数器值为0 ,其他线程将有机会持有 monitor
。值得注意的是编译器将会确保无论方法通过何种方式完成,方法中调用过的每条 monitorenter
指令都有执行其对应 monitorexit
指令,而无论这个方法是正常结束还是异常结束。为了保证在方法异常完成时 monitorenter
和 monitorexit
指令依然可以正确配对执行,编译器会自动产生一个异常处理器,这个异常处理器声明可处理所有的异常,它的目的就是用来执行 monitorexit
指令。从字节码中也可以看出多了一个monitorexit
指令,它就是异常结束时被执行的释放monitor
的指令。
五、synchronized方法底层原理
方法级的同步是隐式,即无需通过字节码指令来控制的,它实现在方法调用和返回操作之中。JVM可以从方法常量池中的方法表结构(method_info Structure) 中的 ACC_SYNCHRONIZED 访问标志区分一个方法是否同步方法。当方法调用时,调用指令将会 检查方法的 ACC_SYNCHRONIZED 访问标志是否被设置,如果设置了,执行线程将先持有monitor(虚拟机规范中用的是管程一词), 然后再执行方法,最后再方法完成(无论是正常完成还是非正常完成)时释放monitor。在方法执行期间,执行线程持有了monitor,其他任何线程都无法再获得同一个monitor。如果一个同步方法执行期间抛 出了异常,并且在方法内部无法处理此异常,那这个同步方法所持有的monitor将在异常抛到同步方法之外时自动释放。
补充:“获取monitor” 在第四点提到过,就是把monitor中owner变量设置为当前线程,同时monitor中的计数器count加1
六、Java虚拟机对synchronized的优化
锁的状态总共有四种:无锁状态
、偏向锁
、轻量级锁
、重量级锁
。随着锁的竞争,锁可以从偏向锁升级到轻量级锁,再升级的重量级锁(自动的)
,但是锁的升级是单向的,也就是说只能从低到高升级,不会出现锁的降级。、
偏向锁
锁偏向是一种针对加锁操作的优化手段。它的核心思想是:如果一个线程获得了锁,那么锁就进入偏向模式。当这个线程再次请求锁时,无须再做任何同步操作。这样就节省了大量有关锁申请的操作,从而提高了程序性能。
因此,对于几乎没有锁竞争的场合,偏向锁有比较好的优化效果,因为连续多次极有可能是同一个线程请求相同的锁。而对于锁竞争比较激烈的场合,其效果不佳。因为在竞争激烈的场合,最有可能的情况是每次都是不同的线程来请求相同的锁。这样偏向模式会失效,因此还不如不启用偏向锁。
轻量级锁
倘若偏向锁失败,虚拟机并不会立即升级为重量级锁,它还会尝试使用一种称为轻量级锁的优化手段(1.6之后加入的),此时Mark Word 的结构也变为轻量级锁的结构。
轻量级锁能够提升程序性能的依据是“对绝大部分的锁,在整个同步周期内都不存在竞争”,注意这是经验数据。需要了解的是,轻量级锁所适应的场景是不同的线程交替执行同一同步块的场合,如果存在不同线程在同一时间访问同一锁的场合,就会导致轻量级锁膨胀为重量级锁。
自旋锁
轻量级锁失败后,虚拟机为了避免线程真实地在操作系统层面挂起,还会进行一项称为自旋锁的优化手段。这是基于在大多数情况下,线程持有锁的时间都不会太长,如果直接挂起操作系统层面的线程可能会得不偿失,毕竟操作系统实现线程之间的切换时需要从用户态转换到核心态,这个状态之间的转换需要相对比较长的时间,时间成本相对较高,因此自旋锁会假设在不久将来,当前的线程可以获得锁,因此虚拟机会让当前想要获取锁的线程做几个空循环(这也是称为自旋的原因),一般不会太久,可能是50个循环或100循环,在经过若干次循环后,如果得到锁,就顺利进入临界区。如果还不能获得锁,那就会将线程在操作系统层面挂起,这就是自旋锁的优化方式,这种方式确实也是可以提升效率的。最后没办法也就只能升级为重量级锁了。
重量级锁
上述已经讲得 fi~ 常 清楚了。
锁消除
消除锁是虚拟机另外一种锁的优化,这种优化更彻底,Java虚拟机在JIT编译时(可以简单理解为当某段代码即将第一次被执行时进行编译,又称即时编译),通过对运行上下文的扫描,去除不可能存在共享资源竞争的锁,通过这种方式消除没有必要的锁,可以节省毫无意义的请求锁时间,如下StringBuffer的append是一个同步方法,但是在add方法中的StringBuffer属于一个局部变量,并且不会被其他线程所使用,因此StringBuffer不可能存在共享资源竞争的情景,JVM会自动将其锁消除。
/**
* Created by zejian on 2017/6/4.
* Blog : http://blog.csdn.net/javazejian [原文地址,请尊重原创]
* 消除StringBuffer同步锁
*/
public class StringBufferRemoveSync {
public void add(String str1, String str2) {
//StringBuffer是线程安全,由于sb只会在append方法中使用,不可能被其他线程引用
//因此sb属于不可能共享的资源,JVM会自动消除内部的锁
StringBuffer sb = new StringBuffer();
sb.append(str1).append(str2);
}
public static void main(String[] args) {
StringBufferRemoveSync rmsync = new StringBufferRemoveSync();
for (int i = 0; i < 10000000; i++) {
rmsync.add("abc", "123");
}
}
}