java内存模型与多线程

现代计算机,cpu在计算的时候,并不老是从内存读取数据,它的数据读取顺序优先级是:寄存器-高速缓存-内存,线程计算的时候,原始的数据来自内存,在 计算过程当中,有些数据可能被频繁读取,这些数据被存储在寄存器和高速缓存中,当线程计算完后,这些缓存的数据在适当的时候应该写回内存,当多个线程同时读 写某个内存数据时,因为涉及数据的可见性、操做的有序性,因此就会产生多线程并发问题。java

    Java做为平台无关性语言,JLS(Java语言规范)定义了一个统一的内存管理模型JMM(Java Memory Model),JMM屏蔽了底层平台内存管理细节,在多线程环境中必须解决可见性和有序性的问题。JMM规定了jvm有主内存(Main Memory)和工做内存(Working Memory) ,主内存存放程序中全部的类实例、静态数据等变量,是多个线程共享的,而工做内存存放的是该线程从主内存中拷贝过来的变量以及访问方法所取得的局部变量, 是每一个线程私有的其余线程不能访问,每一个线程对变量的操做都是以先从主内存将其拷贝到工做内存再对其进行操做的方式进行,多个线程之间不能直接互相传递数 据通讯,只能经过共享变量来进行。缓存

    dc9d7w83_47gnxqbmd8_b

    JLS定义了线程对主存的操做指令:read,load,use,assign,store,write。这些行为是不可分解的原子操做,在使用上相互依赖,read-load从主内存复制变量到当前工做内存,use-assign执行代码改变共享变量值,store-write用工做内存数据刷新主存相关内容。安全

    线程要引用某变量,若是线程工做内存中没有该个变量,经过read-load从主内存中拷贝一个副本到工做内存中,完成后线程会引用该副本,当同一个线程 再次引用该变量时,有可能从新从主存中获取变量副本(read-load-use),也有可能直接引用原来的副本(use),也就是说read、 load、use顺序能够由jvm实现系统决定。多线程

    线程要写入某变量,它会将值指定给工做内存中的变量副本(assign),完成后这个变量副本会同步到主存(store-write),至于什么时候同步过去,即assign,store,write顺序由jvm实现系统决定。并发

    多线程对主存的有序性操做有可能会致使并发问题,看一个例子:jvm

public class Test{ public int i = 0; public void add(){ i++; } } 

 

    前提:线程a、b使用类Test的同一个实例,执行顺序1-6函数

  1. 线程a从主存读取i副本x到工做内存,工做内存中x值为0
  2. 线程b从主存读取i副本y到工做内存,工做内存中y值为0
  3. 线程a将工做内存中x加1,工做内存中x值变为1
  4. 线程a将x提交到主存,主存中i变为1
  5. 线程b将工做内存中y加1,工做内存中y值变为1
  6. 线程b将y提交到主存中,主存中i变为1   

    *单线程环境下,i进行两次加1,结果一定是2,但多线程环境下,i进行两次加1,结果不必定是2,这取决于上例中第2和第4步的执行顺序!this

    volatile是java提供的一种同步手段,只不过它是 轻量级的同步,为何这么说,由于volatile只能保证多线程的内存可见性,不能保证多线程的执行有序性。而最完全的同步要保证有序性和可见性。当同 一线程屡次重复对字段赋值时,线程有可能只对工做内存中的副本进行赋值,直到最后一次赋值后才同步到主存储区。任何被volatile修饰的变量,都不拷 贝副本到工做内存,任何修改都及时写在主存。所以对于valatile修饰的变量的修改,全部线程立刻就能看到,可是volatile不能保证对变量的修 改是有序的。要使 volatile 变量提供理想的线程安全,必须同时知足下面两个条件:spa

    一、对变量的写操做不依赖于当前值。线程

    二、该变量没有包含在具备其余变量的不变式中。

    错误的例子:

public class VolatileFalse{ public volatile int i; public void add(){ i++; } }

    说明:虽然volatile 保证对i的修改“及时”写在主存,全部线程立刻能看到,但i = i + 1 对变量i的写操做依赖于当前值,而当前值是可变的,因为多线程下读写i的值是无序的,因此多个线程运行VolatileFalse的同一个实例后的到i的 最终值不必定是正确。

    正确的例子:

public class VolatileTrue{ public volatile int i; public void setI(int j){ this.i = j; } } 

    说明:没有volatie声明,在多线程环境下,i的值不必定是正确的,由于this.i = j;涉及给i赋值和将i的值同步主存的步骤,这个顺序可能被打乱。若是用volatie声明了,读取主存副本到工做内存和同步i到主存的步骤,至关因而一 个原子操做,所以是线程安全的。

    volatile适合这种场景:一个变量被多个线程共享,线程直接给这个变量赋值。这是一种很简单的同步场景,这时候使用volatile的开销将会很是小。

    synchronized关键字做为多线程并发环境的执行有序性的保证手段之一,若是某个线程访问一个标识为synchronized的方法,并对相应变量作操做,那么根据JLS,JVM的执行步骤以下:

  1. 取得该对象锁(普通方法的锁为this对象,静态方法则为该类的class对象)并将其锁住(lock)。
  2. 将须要的数据从主内存拷贝到本身的工做内存(read and load)。
  3. 根据程序流程读取或者修改相应变量值(use and assign)。
  4. 将本身工做内存中修改了值的变量拷贝回主内存(store and write)。
  5. 释放对象锁(unlock)。

    对synchronized的一些总结:

public class Test{ public void method0(){...} public synchronized void method1(){...} public void method2() { synchronized (this){...} } public void method3(SomeObject so) {    synchronized(so) {...} } public void method4() {    ...    private byte[] lock = new byte[0];    synchronized (lock){...}    ... } public synchronized static void method5(){...} public void method6(){ synchronized(Test.class){...} } }
  1. method1同步函数和method2中同步块synchronized (this){...}所取得的同步锁都是类Test的实例对象,即对象锁,因此method1和method2效果等同。
  2. 当多个并发线程访问"同一个"对象中的同步函数或同步块时,取得对象锁的线程获得执行,该线程执行期间,其余要访问该对象同步函数或同步块(无论 是否是相同的同步函数或同步块)的线程将会阻塞,直到获取该对象锁后才能执行,固然要访问该对象的非同步方法或同步块的线程不受对象锁的限制,能够直接访 问。
  3. method2同步块synchronized (this){...}中this是指调用这个方法的对象,若是两个线程中分别调用的是t1和t2(类Test的实例化)两个对象,则这个同步块对于这两 个线程来讲无效,这时可使用method3中同步块synchronized(so) {...}方式,将锁挂在其余对象上面。
  4. 若是要对函数中的部分代码进行同步处理,怎么办?method4中经过一个特别的实例变量充当锁来实现。
  5. method5静态同步函数和method6中同步块synchronized(Test.class){...}所取得的同步锁是类锁,即类Test的锁,而非类Test的对象锁。
  6. 由于类锁跟对象锁是不一样的锁,因此在多线程并发环境下method1和method5不构成同步。
相关文章
相关标签/搜索