深入理解JVM之高效并发

Java内存模型与线程、线程安全与锁优化

Posted by Wanglizhi on July 16, 2016

第十二章 Java内存模型与线程

多任务和高并发是衡量一台计算机处理器的能力重要指标之一。一般衡量一个服务器性能的高低好坏,使用每秒事务处理数(Transactions Per Second,TPS)这个指标比较能说明问题,它代表着一秒内服务器平均能响应的请求数,而TPS值与程序的并发能力有着非常密切的关系。

硬件的效率与一致性

由于计算机的存储设备与处理器的运算能力之间有几个数量级的差距,所以现代计算机系统都不得不加入一层读写速度尽可能接近处理器运算速度的高速缓存(cache)来作为内存与处理器之间的缓冲:将运算需要使用到的数据复制到缓存中,让运算能快速进行,当运算结束后再从缓存同步回内存之中没这样处理器就无需等待缓慢的内存读写了。 基于高速缓存的存储交互很好地解决了处理器与内存的速度矛盾,但是引入了一个新的问题:缓存一致性(Cache Coherence)。在多处理器系统中,每个处理器都有自己的高速缓存,而他们又共享同一主存,如下图所示:多个处理器运算任务都涉及同一块主存,需要一种协议可以保障数据的一致性,这类协议有MSI、MESI、MOSI及Dragon Protocol等。Java虚拟机内存模型中定义的内存访问操作与硬件的缓存访问操作是具有可比性的,后续将介绍Java内存模型。

除此之外,为了使得处理器内部的运算单元能竟可能被充分利用,处理器可能会对输入代码进行乱起执行(Out-Of-Order Execution)优化,处理器会在计算之后将对乱序执行的代码进行结果重组,保证结果准确性。与处理器的乱序执行优化类似,Java虚拟机的即时编译器中也有类似的指令重排序(Instruction Recorder)优化。

Java 内存模型

JMM(Java Memory Model)试图屏蔽掉各种硬件和操作系统的内存访问差异,以实现让Java程序在各种平台下都能达到一致的并发效果。在JDK1.5后,Java内存模型已经成熟和完善。

主内存与工作内存

Java内存模型的主要目标是定义程序中各个变量的访问规则,即在虚拟机中将变量存储到内存和从内存中取出变量这样底层细节。此处的变量与Java编程时所说的变量不一样,指包括了实例字段、静态字段和构成数组对象的元素,但是不包括局部变量与方法参数,后者是线程私有的,不会被共享。

Java内存模型中规定了所有的变量都存储在主内存中,每条线程还有自己的工作内存(可以与前面将的处理器的高速缓存类比),线程的工作内存中保存了该线程使用到的变量到主内存副本拷贝,线程对变量的所有操作(读取、赋值)都必须在工作内存中进行,而不能直接读写主内存中的变量。不同线程之间无法直接访问对方工作内存中的变量,线程间变量值的传递均需要在主内存来完成,线程、主内存和工作内存的交互关系如下图所示,和上图很类似。

内存间交互操作

一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存之类的实现细节,JMM定义了一下八种操作来完成:

  • lock(锁定):作用域主内存的变量,它把一个变量标识为一条线程独占的状态;
  • unlock(解锁):作用于主内存的变量,它把一个处于锁定状态的变量释放出来,释放后的变量才可以被其他线程锁定;
  • read(读取):作用于主内存变量,它变量的值从主内存传输到线程的工作内存中,以便随后的load动作使用
  • load(载入):作用于工作内存的变量,它把read操作从主内存中得到的变量值放入工作内存的变量副本中;
  • use(使用):作用于工作内存的变量,它把工作内存中一个变量的值传递给执行引擎,每当虚拟机遇到一个需要使用变量的值的字节码指令时将会执行这个操作。
  • assign(赋值):作用于工作内存的变量,它把一个从执行引擎接收到的值赋值给工作内存的变量,每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。
  • store(存储):作用于工作内存的变量,把工作内存中的一个变量的值传送到主内存中,以便随后的write的操作。
  • write(写入):作用于主内存的变量,它把store操作从工作内存中一个变量的值传送到主内存的变量中。

如果要把一个变量从主内存中复制到工作内存,就需要按顺寻地执行read和load操作,如果把变量从工作内存中同步回主内存中,就要按顺序地执行store和write操作。Java内存模型只要求上述操作必须按顺序执行,而没有保证必须是连续执行。也就是read和load之间,store和write之间是可以插入其他指令的,如对主内存中的变量a、b进行访问时,可能的顺序是read a,read b,load b, load a。Java内存模型还规定了在执行上述八种基本操作时,必须满足如下规则:

  • 不允许read和load、store和write操作之一单独出现,如不允许从主内存读取了但工作内存不接受
  • 不允许一个线程丢弃它的最近assign的操作,即变量在工作内存中改变了之后必须同步到主内存中。
  • 不允许一个线程无原因地(没有发生过任何assign操作)把数据从工作内存同步回主内存中。
  • 一个新的变量只能在主内存中诞生,不允许在工作内存中直接使用一个未被初始化(load或assign)的变量。即就是对一个变量实施use和store操作之前,必须先执行过了assign和load操作。
  • 一个变量在同一时刻只允许一条线程对其进行lock操作,lock和unlock必须成对出现
  • 如果对一个变量执行lock操作,将会清空工作内存中此变量的值,在执行引擎使用这个变量前需要重新执行load或assign操作初始化变量的值
  • 如果一个变量事先没有被lock操作锁定,则不允许对它执行unlock操作;也不允许去unlock一个被其他线程锁定的变量。
  • 对一个变量执行unlock操作之前,必须先把此变量同步到主内存中(执行store和write操作)。

对于volatile型变量的特殊规则

当一个变量被定义成volatile之后,它将具备两种特性,第一是保证此变量对所有线程的可见性,即当一条线程修改了这个变量的值,新值对于其他线程来说是立即得知的。

由于volatile变量只能保证可见性,在不符合以下两条规则的运算场景中,我们仍然要通过加锁来保证原子性。

  • 运算结果并不依赖变量的当前值,或者能够确保只有单一的线程修改变量的值
  • 变量不需要与其他状态变量共同参与不变约束

volatile变量的第二个语义是禁止指令重排序优化。

对于long和double型变量的特殊规则

JVM规范允许虚拟机将没有被volatile修饰的64位数据的读写操作划分为两次32位的操作来进行。但是各种虚拟机实现几乎把64位数据的读写作为原子操作来对待

原子性、可见性和有序性

  • 原子性(Atomicity):大致认为基本数据类型的访问读写是具备原子性的。JMM提供lock和unlock保证原子性,对应代码中的synchronized关键字
  • 可见性(Visibility):当一个线程修改了共享变量的值,其他线程能够立即得知这个修改。volatile保证新值能立即同步到主内存,以及每次使用前立即从主内存刷新。除了volatile外,synchronized和final两个关键字也能实现可见性,其中同步块是有lock和unlock机制决定的,而final关键字一旦初始化完成,其他线程就能看见final字段的值
  • 有序性(Ordering):如果在本线程内观察,所有的操作都是有序的;如果在一个线程内观察另一个线程,所有操作都是无序的。Java提供了volatile和synchronized来听歌关键字来保证线程之间操作的有序性。

先行发生原则

先行发生原则:如果操作A先发生于操作B,操作A产生的影响能被操作B观察到,“影响”包括:修改了内存中共享变量的值、发送了消息、调用了方法。

  • 程序次序规则:写在程序签名的操作先行发生于书写在后面的操作
  • 管程锁定规则:一个unlock操作先行发生于后面对同一个锁的lock操作
  • volatile变量规则:对一个volatile变量的写操作先行发生于后面对这个变量的读操作
  • 线程启动规则:Thread对象的start方法先行发生于此线程的每一个动作
  • 线程终止规则:线程中的所有操作都先行发生于对此线程的终止检测
  • 线程中断规则:对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生
  • 对象终结规则:一个对象初始化完成先行发生于它的finalize方法的开始
  • 传递性:如果操作A先于操作B,操作B先行于操作C,那么操作A先行发生于操作C

Java与线程

线程的实现

线程是比进程更轻量级的调度执行单位,把一个进程资源分配和执行调度分开,各个线程既可以共享进程资源,又可以独立调度(线程是CPU调度的最基本的单位)。实现线程主要有三种方式:

1、使用内核线程实现

内核线程(Kernel Thread,KLT)就是直接由操作系统内核支持的线程,由内核完成线程切换,通过操纵器(Scheduler)对线程进行调度,并负责将线程的任务映射到各个处理器上。每个内核线程都可以看做是内核的一个分身,支持多线程的内核叫做多线程内核。

程序一般不会直接使用内核线程,而是使用内核线程的一种高级接口——轻量级进程(Light Weight Process,LWP),就是我们通常意义上讲的线程,这种轻量级进程与内核线程之间1:1关系成为一对一的线程模型。

轻量级进程具有局限性。首先,大多数LWP的操作,如建立、析构以及同步,都需要进行系统调用。系统调用的代价相对较高:需要在user mode和kernel mode中切换。其次,每个LWP都需要有一个内核线程支持,因此LWP要消耗内核资源(内核线程的栈空间)。因此一个系统不能支持大量的LWP。

2、使用用户线程实现

LWP虽然本质上属于用户线程,但LWP线程库是建立在内核之上的,LWP的许多操作都要进行系统调用,因此效率不高。而这里的用户线程指的是完全建立在用户空间的线程库,用户线程的建立,同步,销毁,调度完全在用户空间完成,不需要内核的帮助。因此这种线程的操作是极其快速的且低消耗的。

上图(N:1模型)是最初的一个用户线程模型,从中可以看出,进程中包含线程,用户线程在用户空间中实现,内核并没有直接对用户线程进程调度,内核的调度对象和传统进程一样,还是进程本身,内核并不知道用户线程的存在。用户线程之间的调度由在用户空间实现的线程库实现。其缺点是一个用户线程如果阻塞在系统调用中,则整个进程都将会阻塞。使用用户线程的程序越来越少了。

3、Java线程,混合实现(用户线程+LWP)

用户线程库还是完全建立在用户空间中,因此用户线程的操作还是很廉价,因此可以建立任意多需要的用户线程。操作系统提供了LWP作为用户线程和内核线程之间的桥梁。LWP还是和前面提到的一样,具有内核线程支持,是内核的调度单元,并且用户线程的系统调用要通过LWP,因此进程中某个用户线程的阻塞不会影响整个进程的执行。用户线程库将建立的用户线程关联到LWP上,LWP与用户线程的数量不一定一致。当内核调度到某个LWP上时,此时与该LWP关联的用户线程就被执行。

Java 线程调度

协同式调度:线程的执行时间由线程本身来控制,线程把自己的工作执行完后,要主动通知系统切换到另一个线程上去;

抢占式调度:每个线程由系统来分配执行时间,线程切换不由线程本身来决定。Java使用的就是抢占式调度。

Java一种设置了10个级别的线程优先级,在两个线程同时处于Ready状态时,优先级越高的线程越容易被系统选择执行。但线程优先级并不靠谱,因为Java线程是被映射到原生线程上来实现,所以线程调度最终还是由操作系统说了算。

状态转换

Java定义了5种线程状态,在任意一个时间点,一个线程只能有且只有其中一种状态。

  • 新建(New):创建后尚未启动
  • 运行(Runnable):包括了操作系统线程状态中的Running和Ready,可能正在执行,也可能正在等待CPU分配时间
  • 无限期等待(Waiting):不会被分配CPU执行时间,需要其他线程显式唤醒。没设置时间的Object.wait()、Thread.join()、LockSupport.park()
  • 限期等待(Timed Waiting):不会被分配CPU执行时间,不需要显式唤醒,在一定时间后系统自动唤醒,Thread.sleep(),设置了Timeout的Object.wait和Thread.join()方法
  • 阻塞(Blocked):等待着获取到一个排它锁,等待进入同步区域时将进入这个状态
  • 结束(Terminated):已经终止

第十三章 线程安全与锁优化

线程安全

线程安全,当多个线程访问一个对象时,如果不用考虑这些线程在运行时环境下的调度和交替执行,也不需要进行额外的同步,或者在调用方进行任何其他的协调操作,调用这个对象的行为都可以获得正确的结果,那这个对象就是线程安全的

Java语言中的线程安全

讨论线程安全的前提是多个线程之间存在共享数据访问。将Java语言中各种操作由强至弱分为五类:不可变、绝对线程安全、相对线程安全、线程兼容和线程对立。

1、不可变

不可变(Immutable)的对象一定是线程安全的。如果共享数据是一个基本数据类型,那么使用final关键字修饰它就可以保证它是不可变的;如果共享数据是一个对象,那就需要保证对象的行为不会对其状态产生任何影响才行,如java.lang.String类的对象,它是一个典型的不可变对象,调用subString()、replace()和concat()不会影响它原来的值,只会返回一个新构造的而字符串对象。

保证对象行为不影响自己状态的途径有很多种,其中最简单的就是把对象中带有状态的变量都声明为final。除了String,常用的不可变类型还有枚举类型、java.lang.Number的部分子类,如Integer、Long和Double等数值包装类型,BigInteger和BigDecimal等大数据类型,但同为Number的子类型的原子类AtomicInteger和AtomicLong则并非不可变的。

2、绝对线程安全

绝对的线程安全满足线程安全的定义,是很严格的,Java API中标注自己是线程安全的类大多数都不是绝对的线程安全。如:Vector类是一个线程安全的容器,它的add()、get()、size()方法都是被synchronized修饰的,但并不意味着不需要外部同步手段了。

private static Vector<Integer> vector = new Vector<Integer>();
while(true){
  for(int i=0; i<10; i++){
    vector.add(i);
  }
  Thread removeThread = new Thread(new Runnable(){
    public void run(){
      for(int i=0; i<vector.size(); i++){
        vector.remove(i);
      }
    }
  });
  Thread printThread = new Thread(new Runnable(){
    public void run(){
      for(int i=0; i<vector.size(); i++){
        System.out.println(vector.get(i));
      }
    }   
  });
  removeThread.start();
  printThread.start();
  while(Thread.activeCount() > 20);
}

这段代码不是线程安全的,如果另一个线程恰好在错误的时间里删除了一个元素,导致序号i不可再用,get()方法就会抛出一个ArrayIndexOutOfBoundsException,如果要让代码正确执行,必须在代码中加同步块,并且使用同一个对象的锁。

Thread removeThread = new Thread(new Runnable(){
    public void run(){
      synchronized(vector){
      for(int i=0; i<vector.size(); i++){
        vector.remove(i);
      }
      }
    }
  });
  Thread printThread = new Thread(new Runnable(){
    public void run(){
      synchronized(vector){
      for(int i=0; i<vector.size(); i++){
        System.out.println(vector.get(i));
      }
      }
    }   
  });

3、相对线程安全

相对线程安全就是通常意义讲的线程安全,需要保证对这个对象单独的操作是线程安全的,但是对于一些特定顺序的连续调用,就可能需要在调用端使用额外的同步手段来保证调用的正确性。Java中大部分的线程安全都属于这个类型,如Vector、HashTable、Collections的synchronizedCollection()方法包装的集合等

4、线程兼容

线程兼容是指对象本身并不是线程安全的,通过在调用端正确使用同步手段来保证对象在并发环境中安全地使用。Java API中大部分类都是线程兼容的,如Vector、HashTable、ArrayList和HashMap

5、线程对立

线程对立指不管调用端是否采取了同步措施,都无法在多线程环境中并发使用的代码。线程对立通常是有害的,应当尽量避免。一个线程对立的例子是Thread类的suspend和resume方法,如果有两个线程同时持有一个线程对象,一个尝试去中断线程,一个尝试去恢复线程,如果并发进行的话,无论调用时是否进行了同步,目标线程都是存在死锁风险的,如果中断的线程就是即将执行resume的那个线程,那就肯定要产生死锁了。目前suspend和resume方法已经被JDK声明废弃了(Deprecated)

线程安全的实现方法

1、互斥同步

互斥同步(Mutual Exclusion & Synchronization)是最常见的一种并发正确性保障手段,同步是指在多个线程并发访问共享数据时,保证共享数据在同一时刻只被一条线程使用。而互斥是实现同步的一种手段,临界区(Critical Section)、互斥量(Mutex)和信号量(Semaphore)都是主要的互斥实现方式。所以,互斥是因,同步是果,互斥是方法,同步是目的

最基本的互斥同步手段就是synchronized关键字,经过编译之后,会在同步块的前后分别形成monitorenter和monitorexit这两个字节码指令,这两个字节码都需要一个reference类型的参数来指明要锁定和解锁的对象。如果指定了synchronized的对象参数,那就是这个对象的reference;如果没有明确指定,那就根据synchronized修饰的是实例方法还是类方法,去取对应的对象实例或Class对象来作为锁对象。

根据JVM规范,在执行monitorenter指令时,首先要尝试获取对象的锁。如果这个对象没被锁定,或者当前线程已经拥有了那个对象的锁,把锁的计数器加1,相应的在执行monitorexit指令时会将锁计数器减1,当计数器为0时,锁就被释放了。如果获取对象锁失败,那当前线程就要阻塞等待,直到对象锁被另外一个线程释放为止。

关于JVM规范,有两点需要注意:首先,synchronized同步块对同一条线程来说是可重入的,不会出现把自己锁死的问题;其次,同步块在已进入的线程执行完之前,会阻塞后面其他线程的进入。上一章讲过,Java线程是映射到操作系统的原生线程之上的,如果要阻塞或唤醒一条线程,都需要操作系统来帮忙完成,这就需要从用户态转换到核心态中,因此会耗费很多处理器时间,状态转换消耗的时间可能比用户代码执行的时间还要长。所以,synchronized是Java语言中一个重量级的操作,在必要情况下才使用这种操作。

除了synchronized之外,我们还可以使用java.util.concurrent包中的重入锁(ReentrantLock)来实现同步,在基本用法上,ReentrantLock与synchronized很相似,他们都具备一样的线程重入特性,只是代码写法上有点区别,一个表现为API层面的互斥锁(lock和unlock方法配合try/finally语句块来完成),一个表现为原生语法层面的互斥锁。不过ReentrantLock增加了一些高级功能,主要有一下三项:

  • 等待可中断:是指当持有锁的线程长期不释放锁的时候,正在等待的线程可以选择放弃等待,改为处理其他事情,可中断特性对于处理时间非常长的同步块很有帮助;
  • 公平锁:指多个线程在等待同一个锁时,必须按照申请锁的时间顺序来一次获得锁;而非公平锁不保证这一点,在锁被释放时,任何一个等待锁的线程都有机会获得锁。synchronized中锁是非公平的,ReentrantLock默认也是非公平的,但可以通过构造函数要求使用公平锁
  • 锁绑定多个条件:是指一个ReentrantLock对象可以同时绑定多个Condition对象,而在synchronized中,锁对象的wait()和notify()或notifyAll()方法可以实现一个隐含的条件,如果要和多于一个的条件关联的时候,就不得不额外地添加锁,而ReentrantLock则无须这样做,只需要多次调用newCondition()方法即可。

从性能上来说,synchronized与ReentrantLock的性能基本上是完全持平,虚拟机未来肯定也更偏向于原生的synchronized,所以还是提倡在synchronized能实现需求的情况下,优先考虑使用synchronized来进行同步。

2、非阻塞同步

互斥同步主要问题是进行现场阻塞和唤醒的性能问题,这种同步称为阻塞同步,另外它属于一种悲观的并发策略,总是认为不加锁肯定会出问题。随着硬件指令集的发展,我们有了另外一个选择:基于冲突检测的乐观并发策略,通俗讲就是先进行操作,没有冲突就成功,有冲突就进行补偿(如重试直到成功),这种乐观的并发策略成为非阻塞同步。

“硬件指令集的发展“是指操作和冲突检测这两个步骤具备原子性,靠硬件保证一个从语义上看起来需要多次操作的行为只通过一条处理器指令就能完成,这类指令常用的有:

  • 测试并设置(Test-and-Set)
  • 获取并增加(Fetch-and-Increment)
  • 交换(Swap)
  • 比较并交换(Compare-and-Swap,CAS)
  • 加载链接/条件存储(Load-Linked/Store-Conditional,LL/SC)

CAS指令需要有三个操作数,分别是内存位置(变量的内存地址,V表示)、旧的预期值(A表示)和新值(B表示)。CAS执行时,当且仅当V符合旧预期值A时,处理器用新值B更新V的值,否则它就不执行更新操作,但是不管是否更新了V的值,都会返回V的旧值,上述过程是一个原子操作。

在JDK1.5之后,Java程序中才可以使用CAS操作,该操作由sun.misc.Unsafe类里面的compareAndSwapInt()和compareAndSwapLong()等几个方法包装提供,JVM内部对这些方法做了特殊处理。由于UnSafe类不是提供给用户程序调用的类,如果不采用反射手段,我们只能通过其他的Java API来间接使用它,如Concurrent包里面的整数原子类。

采用AtomicInteger代替int后,incrementAndGet()方法具有原子性,程序输出正确结果。

public static AtomicInteger race = new AtomicInteger(0);
public static void increase(){
  race.incrementAndGet();
}
for(int i=0; i<10; i++){
  Thread a = new Thread(new Runnable(){
    public void run(){
      for(int i=0; i<10000; i++){
        increase();
      }
    }
})
}

incrementAndGet()在一个无限循环中,不断尝试将一个比当前值大1的新值赋值给自己,如果失败了,那说明在执行”获取-设置“操作时已经有了修改,于是再次循环进行下一次操作,直到设置成功为止。

CAS的缺陷:如果变量V初次读取的时候是A值,准备赋值的时候检查它依然为A值,不能说它没有被其他线程改过,如果先改成B又改回A事无法发现的,这个漏洞称为CAS操作的”ABA“问题。如果需要解决ABA问题,改用传统的互斥同步可能会比原子类更高效。

3、无同步方案

要保证线程安全,并不一定要进行同步,如果一个方法不涉及共享数据,那它就无须任何同步措施去保证正确性。

  • 可重入代码(Reentrant Code):也叫做纯代码,可以在代码执行的任何时刻中断它,转而执行另一段代码,返回后不会出现任何错误。可重入代码有一些共同的特征:不依赖存储在堆上的数据和公用的系统资源、用到的状态都由参数传入、不调用非可重入的方法等
  • 线程本地存储(Thread Local Storage):把共享数据的可见范围限制在同一个线程内,无须同步,如:经典Web交互模型中的”一个请求对应一个服务器线程“的处理方式。java.lang.ThreadLocal类来实现线程本地存储的功能,每个线程的Thread对象都有一个ThreadLocalMap对象,以threadLocalHashCode为键,以本地线程变量为值。

锁优化

自旋锁与自适应自旋

互斥同步对性能最大影响就是阻塞的实现,挂起线程和恢复线程的操作都需要转入内核态完成。对于多处理器,可以让线程等待锁时执行一个忙循环(自旋),就是所谓的自旋锁。

自旋锁避免了线程切换开销,但要占用处理器时间,适用于锁被占用时间很短的情况。JDK1.6引入了自适应的自旋锁,自旋的时间不再固定,而是由前一次在同一个锁上的自旋时间以及锁的拥有者的状态来决定。

锁消除

锁消除是指虚拟机即时编译器在运行时,对一些代码上要求同步,但是被检测到不可能存在共享数据竞争的锁进行消除。

public String concatString(String s1, String s2, String s3){
  return s1 + s2 + s3;
}

JDK1.5后会转化为StringBuilder对象的连续append()操作

public String concatString(String s1, String s2, String s3){
  StringBuffer sb = new StringBuffer();
  sb.append(s1);
  sb.append(s2);
  sb.append(s3);
  return sb.toString();
}

append方法都有同步块,但是JVM观察sb变量发现不会产生共享竞争,所以可以消除锁。

锁粗化

原则上,总是推荐将同步块的作用范围限制的尽量小——只在共享数据的实际作用域才进行同步,使得需要同步的操作数量尽可能小。

但是如果一系列的连续操作都对同一个对象反复加锁和解锁,甚至出现在循环体中,JVM会把加锁同步打范围扩展(粗化)到整个操作序列的外部

轻量级锁

JDK1.6加入的新型锁机制,根据绝大部分锁在整个同步周期内都是不存在竞争的,使用CAS操作避免了互斥量的开销,如果存在锁竞争,除了互斥量的开销外,还额外发生了CAS操作,会使轻量级锁比传统锁更慢

偏向锁

偏向锁也是JDK1.6中引入的一项锁优化,它的目的是消除数据在无竞争情况下的同步源于,进一步提高程序的运行性能。它的意思是这个锁会偏向于第一个获得它的线程,如果在接下来的执行过程中,该锁没有被其他的线程获取,则持有偏向锁的线程将永远不需要再进同步。

参考:《深入理解Java虚拟机》