Java内存模型修订了!

标签: java 内存 模型 | 发表时间:2015-07-27 13:53 | 作者:aoyouzi
出处:http://www.iteye.com
传统的Java内存模型涵盖了很多Java语言的语义保证。在这篇文章中,我们将重点介绍其中的几个语义,以更深入地了解他们。对于本文中描述的语义,我们还将尝试体会对现有Java内存模型更新的动机。本文中与JMM未来更新相关的讨论,将被称为JMM9。
 
1. Java内存模型
现有的Java内存模型,如JSR133(以下称为JMM-JSR133)中所定义的,为共享内存指定了一致性模型,并且有助于为开发者提供与JMM-JSR133表述一致的定义。JMM-JSR133规范的目标是确保线程通过内存交互语义的精确定义,以便允许优化并提供清晰的编程模型。JMM-JSR133旨在提供定义和语义,使多线程程序不仅是正确的,而且是高性能的,并对现有代码库的影响微乎其微。
考虑到这一点,我们来过一下JMM-JSR133中,过分指定或者指定不足的语义保证,同时重点放到社区广泛讨论的,关于我们如何在JMM9对其改进的话题上。
 
2. JMM9 - 顺序一致性 - 数据竞态自由问题
JMM-JSR133谈到了相对于操作的程序执行。结合有序操作的执行,描述了这些操作之间的关系。在这篇文章中,我们将扩展一些这样的顺序和关系,进而讨论一下什么是顺序一致的执行。让我们先从“程序顺序”开始。每个线程的程序顺序是一个总体顺序,表示通过该线程执行的所有操作的顺序。有时候,并不是所有操作都需要按序执行的。因此,有一些关系仅是部分有序的关系。例如,“happens-before”和“synchronized-with”两个就是部分有序关系。当一个操作发生在另一个操作之前;第一个操作不仅对第二个操作是可见的,而且其顺序在第二个操作之前。这两个操作之间的关系被称为是happens-before关系。有时,有些特殊操作需要指定顺序,他们被称为“同步操作”。volatile的读取和写入、monitor的锁定和解锁等都是同步操作的例子。一个同步操作会引起该操作的“synchronized-with”关系。synchronized-with关系是偏序的,这意味着并非所有两两的同步操作都包含这个关系之内。所有同步操作的总体顺序被称为“同步顺序”,每个执行都有一个同步顺序。
 
现在让我们谈谈顺序一致的执行。当所有的读写操作是总体有序执行时,被认为是顺序一致的(SC)。在SC执行中,读操作总是能看到最后一次写入特定变量的值。当SC执行表现为没有“数据竞态”时,该程序被认为是数据竞态自由(DRF)的。当程序中有两个不具备happens-before关系顺序的访问,他们访问的变量相同且至少其中之一是一个写访问时,就会发生数据竞态。数据竞态自由的顺序一致(SC for DRF)意味着DRF程序的行为是顺序一致的。但是严格支持顺序一致是以牺牲性能为代价的,大多数系统会对内存中的操作重新排序,以提高执行速度,并“隐藏”昂贵操作的延迟。同时,编译器也会对代码重新排序以优化执行。在保证严格顺序的一致性的场景中,不能进行这些内存操作重新排序或代码优化,因此性能会受到影响。JMM-JSR133已经使用底层编译器、高速缓冲存储器的相互作用和对程序不可见的JIT,合并了松散排序限制和任何重新排序。
 
注:昂贵操作是那些占用大量的CPU周期来完成、阻止执行流水线。
 
对于JMM9来说,性能是一个重要的考虑因素,而且任何一门编程语言的内存模型,理论上,都应该让开发者可以利用内存模型架构上弱有序(weakly-ordered)的优势。成功的实现和示例是放松严格的顺序,尤其是在弱有序的架构上。
 
注:弱序是指可以对读取和写入重新排序,并且需要显式的内存屏障遏制这种重新排序的架构。
 
3. JMM9 - 无中生有问题
JMM-JSR133另一个主要的语义是对“无中生有”(Out-of Thin Air,OoTA)值的禁止。happens-before模型有时会创建变量值并“无中生有”地读取,因为它不包含因果条件。有一点非常重要,由自身引起的关系不会采用数据和控制依赖的概念,我们将在下面正确同步代码的例子看到,非法写入是由写入本身引起的。
 
(注:x和y初始化为0) -

这段码是happens-before一致的,但不是真正的顺序一致。例如,如果r1看到为x=42的写入,并且r2看到Y=42的写入,x和y的值都是42,这是一个数据竞态条件的结果。

这里,写入变量都在读取变量之前,读取将看到相关的写入,这将导致OoTA结果。

 

注:数据竞态可能产生推测的结果,这将最终把自己变成自我实现的预言。OoTA保证是关于秉承因果关系的规则。目前的想法是,因果关系可以避免写入推测。JMM9旨在寻找OoTA的原因和改进方法,以避免OoTA。

 

为了禁止OoTA值,一些写入需要等待他们的读取来避免数据竞态。因此,JMM-JSR133定义的OoTA禁止正式拒绝OoTA读取。这个正式的定义包括内存模型的“执行和因果条件”。基本上,当所有的程序操作提交时,一个良好的执行要满足因果条件。

 

注:在每次读取可以看到对同一变量的写入时,一个良好的执行遵循在一个线程内、happens-before和synchronization-order一致地执行。

 

正如你可能已经知道的,JMM-JSR133定义严格定义,不让OoTA值侵袭。JMM9旨在发现和纠正正式的定义,以便允许一些常见的优化。

 

4. JMM9 非Volatile变量上的Volatile操作

首先,关键字'Volatile'是什么意思呢?Java的‘volatile’保证了线程间的交互,使得当一个线程写入一个volatile变量,不仅这次写入对其他线程可见,而且其他线程可以看到该线程所有的对volatile变量的写入。

 

那么对于non-volatile变量又发生了什么呢?非volatile变量没有volatile关键字保证交互的好处。因此,编译器可以使用non-volatile变量的缓存值而不是‘volatile’保证,‘volatile’变量将总是从内存中读取。happens-before模型可以用来绑定同步访问到非volatile变量上。

 

注:声明的任何字段为‘volatile’并不意味着有锁参与。因此volatile比使用锁来同步更便宜。但是着重要注意的是,当方法中有多个volatile字段时,可能比使用锁更昂贵。

 

5. JMM9 - 读写原子性问题和字分裂问题

JMM-JSR133也有为共享内存并行算法提供的读取和写入的原子性保证(使用异常)。异常是为non-volatile的长整型和双精度浮点型的写入被视为两个独立的写入而定义的。因此,一个64位的值可以分别写入两个32位,一个线程正在执行读的时候,如果其中的一个写入仍未完成,该线程可能会看到只有一半正确的值,从而失去原子性。这是原子性保证依赖于底层硬件和内存子系统的一个例子。例如,底层汇编指令应该能够处理的操作数的大小,以便保证原子性,否则如果读或写操作必须被分成多于一个的操作,最终将破坏原子性(正如例子中的non-volatile的长整型和双精度浮点型的值)。类似地,如果因为实现产生一个以上的内存子系统事务,那么也将破坏原子性。

注:volatile的长整型和双精度浮点型字段和引用始终保证读取和写入的原子性

 

基于位的设计不是一个理想的解决方案,因为如果64位的异常被删除,那么在32位的体系结构中就会受损。如果在64位架构上行不通,如果期望原子性,那么不得不为长整型和双精度浮点型引入“volatile”,即使底层硬件可以保证原子操作。例如:volatile类型的字段不需要定义为双精度浮点型,因为基础架构,或者ISA、浮点单元会处理好64位宽字段的原子性需求。JMM9的目的是确定硬件提供原子性的保证。

 

JMM-JSR133写于十多年前;此后处理器位数发生了演变,64位已经成为主流的处理位数。当即强调的是,JMM-JSR133提出了针对64位读写的妥协,尽管64位的值可以由任何架构原子生成,一些架构仍然有必要请求锁。现在,这使得在这些架构上的64位读写操作非常昂贵。在32位x86架构上,如果不能找到一个合理的原子64位操作实现,则原子性将不会改变。

 

注:在语言设计中潜在一个问题,关键字“volatile”被赋予了过分的含义。运行时很难弄清楚,用户使用volatile是为了恢复原子性(因此它可以在64位平台被剥离出来),还是为了内存排序的目的。

 

当谈论访问原子性,读写操作的独立性是要着重考虑的。写入一个特定的字段不应该与读取或者写入其他字段有交互。JMM-JSR133的保证意味着,同步不应需要提供顺序一致性。因此,JMM-JSR133保证禁止被称为“字分裂”的问题。基本上,当更新一个操作数希望在比基础架构为所有操作数生成的更低的粒度上操作时,我们将遇到“字撕裂”问题。需要记住的重要一点是,字撕裂问题的原因之一是,64位长整型和双精度浮点型都没有给出原子性保证。字撕裂在JMM-JSR133中是禁止的,在JMM9中继续保持这种方式。

 

6. JMM9 - final字段问题

与其他字段相比,final字段是不同的。例如,一个线程用final字段x读取一个“完全初始化”的对象;在对象“完全初始化”后,能保证读取了final字段y的初始值,但不能保证“正常”的非final字段nonX。

注:“完全初始化”是指对象的构造函数完成。

 

鉴于上述情况,有一些简单的事情可以在JMM9中修复。例如:volatile类型字段,volatile字段在构造函数中初始化是不保证可见性的,即使对实例本身是可见的。因此,问题来了,是否final字段应该保证扩大到所有字段,包括初始化volatile字段?此外,如果一个完全初始化对象的“正常”非final字段的值不发生变化,我们是否可以将final字段保证到这个“正常”的字段。

 

http://it.dataguru.cn/article-7676-1.html



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [java 内存 模型] 推荐:

深入Java内存模型

- - ImportNew
你可以在网上找到一大堆资料让你了解JMM是什么东西,但大多在你看完后仍然会有很多疑问. happen-before是怎么工作的呢. 用volatile会导致缓存的丢弃吗. 为什么我们从一开始就需要内存模型. 通过这篇文章,读者可以学习到足以回答以上所有问题的知识. 它包含两大部分:第一部分是硬件层次的大体架构,第二部分是深入OpenJdk源代码和实现.

Java 内存模型 JMM

- - 码蜂笔记
JMM,Java Memory Model,Java 内存模型. 什么是内存模型,要他何用. 假定一个线程为变量var赋值: var = 3;,内存模型要回答的问题是:在什么条件下,读取变量var的线程可以看到 3这个值. 如果缺少了同步,线程可能无法看到其他线程操作的结果. 导致这种情况的原因可以有:编译器生成指令的次序可以不同于源代码的“显然”版本,编译器还会把变量存储在寄存器而不是内存中;处理器可以乱序或并行执行指令;缓存会改变写入提交到主存得到变量的次序;存储在处理器本地缓存中的变量对其他处理器不可见 等等.

Java 多线程内存模型

- - ITeye博客
Java 多线程内存模型.       Java虚拟机规范中试图定义一种Java内存模型(Java Memory Model,JMM)来屏蔽掉各种硬件和操作系统的内存访问差异,以实现让Java程序在各种平台下都能达到一致的并发效果. 在此之前,主流程序怨言(如C/C++等)直接使用物理硬件(或者说操作系统的内存模型),因此,会由于不同的平台上内存模型差异,导致程序在一套平台上并发完成正常,而在另一套平台上并发访问却经常出错,因此经常需要针对不同的平台来编写程序.

Java运行时的内存模型

- - CSDN博客编程语言推荐文章
每个线程单独的数据区(线程间不共享). 每个线程都有一片单独的内存区域,这里面包含:程序计数器(program counter register),JVM栈和本地方法栈(Native Method Stack). 当一个新的线程被创建的时候,这片内存就已经被分配出来了. 程序计数器:为了线程切换后能恢复到正确的执行位置,每条线程都需要有一个独立的程序计数器,各线程之间的计数器互不影响,独立存储.

Java内存模型修订了!

- - 互联网 - ITeye博客
传统的Java内存模型涵盖了很多Java语言的语义保证. 在这篇文章中,我们将重点介绍其中的几个语义,以更深入地了解他们. 对于本文中描述的语义,我们还将尝试体会对现有Java内存模型更新的动机. 本文中与JMM未来更新相关的讨论,将被称为JMM9. 现有的Java内存模型,如JSR133(以下称为JMM-JSR133)中所定义的,为共享内存指定了一致性模型,并且有助于为开发者提供与JMM-JSR133表述一致的定义.

文章: 深入理解Java内存模型(五)——锁

- - InfoQ cn
锁的释放-获取建立的happens before 关系. 锁是java并发编程中最重要的同步机制. 锁除了让临界区互斥执行外,还可以让释放锁的线程向获取同一个锁的线程发送消息. 深度剖析WebKit渲染机制:Chromium项目Committer确认QCon北京2013. QCon北京自动化运维专题:腾讯海量SNS社区网站高效运维探索.

JAVA内存释放

- - Java - 编程语言 - ITeye博客
(问题一:什么叫垃圾回收机制. ) 垃圾回收是一种动态存储管理技术,它自动地释放不再被程序引用的对象,按照特定的垃圾收集算法来实现资源自动回收的功能. 当一个对象不再被引用的时候,内存回收它占领的空间,以便空间被后来的新对象使用,以免造成内存泄露. (问题二:java的垃圾回收有什么特点. ) JAVA语言不允许程序员直接控制内存空间的使用.

Java 堆内存(Heap)

- - ITeye博客
        堆(Heap)又被称为:优先队列(Priority Queue),是计算机科学中一类特殊的数据结构的统称. 堆通常是一个可以被看做一棵树的数组对象. 在队列中,调度程序反复提取队列中第一个作业并运行,因而实际情况中某些时间较短的任务将等待很长时间才能结束,或者某些不短小,但具有重要性的作业,同样应当具有优先权.

java内存泄漏

- - 编程语言 - ITeye博客
不论哪种语言的内存分配方式,都需要返回所分配内存的真实地址,也就是返回一个指针到内存块的首地址. Java中对象是采用new或者反射的方法创建的,这些对象的创建都是在堆(Heap)中分配的,所有对象的回收都是由Java虚拟机通过垃圾回收机制完成的. GC为了能够正确释放对象,会监控每个对象的运行状况,对他们的申请、引用、被引用、赋值等状况进行监控,Java会使用有向图的方法进行管理内存,实时监控对象是否可以达到,如果不可到达,则就将其回收,这样也可以消除引用循环的问题.

求你了,再问你 Java 内存模型的时候别再给我讲堆栈方法区了

- - IT瘾-dev
最近,面试过很多Java中高级开发,问过很多次关于Java内存模型的知识,问完之后,很多人上来就开始回答:. Java内存模型由几部分组成,堆、本地方法栈、虚拟机栈、方法区…. 每一次我不想打断他们的话,虽然我知道这又是一个误会了我的问题的朋友. 其实,我想问的Java内存模型,是和并发编程有关的.