Java内存储器模型1

Java内存模型1

（原本准备把内存模型单独放到某一篇文章的某个章节里面讲解，后来查阅了国外很多文档才发现其实JVM内存模型的内容还蛮多的，所以直接作为一个章节的基础知识来讲解，可能该章节概念的东西比较多。一个开发Java的开发者，一旦了解了JVM内存模型就能够更加深入地了解该语言的语言特性，可能这个章节更多的是概念，没有太多代码实例，所以希望读者谅解，有什么笔误来Email告知：silentbalanceyh@126.com，本文尽量涵盖所有Java语言可以碰到的和内存相关的内容，同样也会提到一些和内存相关的计算机语言的一些知识，为草案。因为平时开发的时候没有特殊情况不会进行内存管理，所以有可能有笔误的地方比较多，我用的是Windows平台，所以本文涉及到的与操作系统相关的只是仅仅局限于Windows平台。不仅仅如此，这一个章节牵涉到的多线程和另外一些内容并没有讲到，这里主要是结合JVM内部特性把本章节作为核心的概念性章节来讲解，这样方便初学者深入以及彻底理解Java语言）
本文章节：1.JMM简介
2.堆和栈3.本机内存4.防止内存泄漏
1.JMM简介
　　i.内存模型概述　　Java平台自动集成了线程以及多处理器技术，这种集成程度比Java以前诞生的计算机语言要厉害很多，该语言针对多种异构平台的平台独立性而使用的多线程技术支持也是具有开拓性的一面，有时候在开发Java同步和线程安全要求很严格的程序时，往往容易混淆的一个概念就是内存模型。究竟什么是内存模型？内存模型描述了程序中各个变量（实例域、静态域和数组元素）之间的关系，以及在实际计算机系统中将变量存储到内存和从内存中取出变量这样的底层细节，对象最终是存储在内存里面的，这点没有错，但是编译器、运行库、处理器或者系统缓存可以有特权在变量指定内存位置存储或者取出变量的值。【JMM】（Java Memory Model的缩写）允许编译器和缓存以数据在处理器特定的缓存（或寄存器）和主存之间移动的次序拥有重要的特权，除非程序员使用了final或synchronized明确请求了某些可见性的保证。　　1)JSR133：　　在Java语言规范里面指出了JMM是一个比较开拓性的尝试，这种尝试视图定义一个一致的、跨平台的内存模型，但是它有一些比较细微而且很重要的缺点。其实Java语言里面比较容易混淆的关键字主要是synchronized和volatile，也因为这样在开发过程中往往开发者会忽略掉这些规则，这也使得编写同步代码比较困难。　　JSR133本身的目的是为了修复原本JMM的一些缺陷而提出的，其本身的制定目标有以下几个：

• 保留目前JVM的安全保证，以进行类型的安全检查：
  
• 提供（out-of-thin-air safety）无中生有安全性，这样“正确同步的”应该被正式而且直观地定义
• 程序员要有信心开发多线程程序，当然没有其他办法使得并发程序变得很容易开发，但是该规范的发布主要目标是为了减轻程序员理解内存模型中的一些细节负担
• 提供大范围的流行硬件体系结构上的高性能JVM实现，现在的处理器在它们的内存模型上有着很大的不同，JMM应该能够适合于实际的尽可能多的体系结构而不以性能为代价，这也是Java跨平台型设计的基础
• 提供一个同步的习惯用法，以允许发布一个对象使他不用同步就可见，这种情况又称为初始化安全（initialization safety）的新的安全保证
• 对现有代码应该只有最小限度的影响　　2)同步、异步【这里仅仅指概念上的理解，不牵涉到计算机底层基础的一些操作】：　　在系统开发过程，经常会遇到这几个基本概念，不论是网络通讯、对象之间的消息通讯还是Web开发人员常用的Http请求都会遇到这样几个概念，经常有人提到Ajax是异步通讯方式，那么究竟怎样的方式是这样的概念描述呢？　　同步：同步就是在发出一个功能调用的时候，在没有得到响应之前，该调用就不返回，按照这样的定义，其实大部分程序的执行都是同步调用的，一般情况下，在描述同步和异步操作的时候，主要是指代需要其他部件协作处理或者需要协作响应的一些任务处理。比如有一个线程A，在A执行的过程中，可能需要B提供一些相关的执行数据，当然触发B响应的就是A向B发送一个请求或者说对B进行一个调用操作，如果A在执行该操作的时候是同步的方式，那么A就会停留在这个位置等待B给一个响应消息，在B没有任何响应消息回来的时候，A不能做其他事情，只能等待，那么这样的情况，A的操作就是一个同步的简单说明。　　异步：异步就是在发出一个功能调用的时候，不需要等待响应，继续进行它该做的事情，一旦得到响应了过后给予一定的处理，但是不影响正常的处理过程的一种方式。比如有一个线程A，在A执行的过程中，同样需要B提供一些相关数据或者操作，当A向B发送一个请求或者对B进行调用操作过后，A不需要继续等待，而是执行A自己应该做的事情，一旦B有了响应过后会通知A，A接受到该异步请求的响应的时候会进行相关的处理，这种情况下A的操作就是一个简单的异步操作。　　3)可见性、可排序性　　Java内存模型的两个关键概念：可见性（Visibility）和可排序性（Ordering）　　开发过多线程程序的程序员都明白，synchronized关键字强制实施一个线程之间的互斥锁（相互排斥），该互斥锁防止每次有多个线程进入一个给定监控器所保护的同步语句块，也就是说在该情况下，执行程序代码所独有的某些内存是独占模式，其他的线程是不能针对它执行过程所独占的内存进行访问的，这种情况称为该内存不可见。但是在该模型的同步模式中，还有另外一个方面：JMM中指出了，JVM在处理该强制实施的时候可以提供一些内存的可见规则，在该规则里面，它确保当存在一个同步块时，缓存被更新，当输入一个同步块时，缓存失效。因此在JVM内部提供给定监控器保护的同步块之中，一个线程所写入的值对于其余所有的执行由同一个监控器保护的同步块线程来说是可见的，这就是一个简单的可见性的描述。这种机器保证编译器不会把指令从一个同步块的内部移到外部，虽然有时候它会把指令由外部移动到内部。JMM在缺省情况下不做这样的保证——只要有多个线程访问相同变量时必须使用同步。简单总结：　　可见性就是在多核或者多线程运行过程中内存的一种共享模式，在JMM模型里面，通过并发线程修改变量值的时候，必须将线程变量同步回主存过后，其他线程才可能访问到。　　【*：简单讲，内存的可见性使内存资源可以共享，当一个线程执行的时候它所占有的内存，如果它占有的内存资源是可见的，那么这时候其他线程在一定规则内是可以访问该内存资源的，这种规则是由JMM内部定义的，这种情况下内存的该特性称为其可见性。】　　可排序性提供了内存内部的访问顺序，在不同的程序针对不同的内存块进行访问的时候，其访问不是无序的，比如有一个内存块，A和B需要访问的时候，JMM会提供一定的内存分配策略有序地分配它们使用的内存，而在内存的调用过程也会变得有序地进行，内存的折中性质可以简单理解为有序性。而在Java多线程程序里面，JMM通过Java关键字volatile来保证内存的有序访问。　　ii.JMM结构：　　1)简单分析：　　Java语言规范中提到过，JVM中存在一个主存区（Main Memory或Java Heap Memory），Java中所有变量都是存在主存中的，对于所有线程进行共享，而每个线程又存在自己的工作内存（Working Memory），工作内存中保存的是主存中某些变量的拷贝，线程对所有变量的操作并非发生在主存区，而是发生在工作内存中，而线程之间是不能直接相互访问，变量在程序中的传递，是依赖主存来完成的。而在多核处理器下，大部分数据存储在高速缓存中，如果高速缓存不经过内存的时候，也是不可见的一种表现。在Java程序中，内存本身是比较昂贵的资源，其实不仅仅针对Java应用程序，对操作系统本身而言内存也属于昂贵资源，Java程序在性能开销过程中有几个比较典型的可控制的来源。synchronized和volatile关键字提供的内存中模型的可见性保证程序使用一个特殊的、存储关卡（memory barrier）的指令，来刷新缓存，使缓存无效，刷新硬件的写缓存并且延迟执行的传递过程，无疑该机制会对Java程序的性能产生一定的影响。　　JMM的最初目的，就是为了能够支持多线程程序设计的，每个线程可以认为是和其他线程不同的CPU上运行，或者对于多处理器的机器而言，该模型需要实现的就是使得每一个线程就像运行在不同的机器、不同的CPU或者本身就不同的线程上一样，这种情况实际上在项目开发中是常见的。对于CPU本身而言，不能直接访问其他CPU的寄存器，模型必须通过某种定义规则来使得线程和线程在工作内存中进行相互调用而实现CPU本身对其他CPU、或者说线程对其他线程的内存中资源的访问，而表现这种规则的运行环境一般为运行该程序的运行宿主环境（操作系统、服务器、分布式系统等），而程序本身表现就依赖于编写该程序的语言特性，这里也就是说用Java编写的应用程序在内存管理中的实现就是遵循其部分原则，也就是前边提及到的JMM定义了Java语言针对内存的一些的相关规则。然而，虽然设计之初是为了能够更好支持多线程，但是该模型的应用和实现当然不局限于多处理器，而在JVM编译器编译Java编写的程序的时候以及运行期执行该程序的时候，对于单CPU的系统而言，这种规则也是有效的，这就是是上边提到的线程和线程之间的内存策略。JMM本身在描述过程没有提过具体的内存地址以及在实现该策略中的实现方法是由JVM的哪一个环节（编译器、处理器、缓存控制器、其他）提供的机制来实现的，甚至针对一个开发非常熟悉的程序员，也不一定能够了解它内部对于类、对象、方法以及相关内容的一些具体可见的物理结构。相反，JMM定义了一个线程与主存之间的抽象关系，其实从上边的图可以知道，每一个线程可以抽象成为一个工作内存（抽象的高速缓存和寄存器），其中存储了Java的一些值，该模型保证了Java里面的属性、方法、字段存在一定的数学特性，按照该特性，该模型存储了对应的一些内容，并且针对这些内容进行了一定的序列化以及存储排序操作，这样使得Java对象在工作内存里面被JVM顺利调用，（当然这是比较抽象的一种解释）既然如此，大多数JMM的规则在实现的时候，必须使得主存和工作内存之间的通信能够得以保证，而且不能违反内存模型本身的结构，这是语言在设计之处必须考虑到的针对内存的一种设计方法。这里需要知道的一点是，这一切的操作在Java语言里面都是依靠Java语言自身来操作的，因为Java针对开发人员而言，内存的管理在不需要手动操作的情况下本身存在内存的管理策略，这也是Java自己进行内存管理的一种优势。　　[1]原子性（Atomicity）：　　这一点说明了该模型定义的规则针对原子级别的内容存在独立的影响，对于模型设计最初，这些规则需要说明的仅仅是最简单的读取和存储单元写入的的一些操作，这种原子级别的包括——实例、静态变量、数组元素，只是在该规则中不包括方法中的局部变量。　　[2]可见性（Visibility）：　　在该规则的约束下，定义了一个线程在哪种情况下可以访问另外一个线程或者影响另外一个线程，从JVM的操作上讲包括了从另外一个线程的可见区域读取相关数据以及将数据写入到另外一个线程内。　　[3]可排序性（Ordering）：　　该规则将会约束任何一个违背了规则调用的线程在操作过程中的一些顺序，排序问题主要围绕了读取、写入和赋值语句有关的序列。　　如果在该模型内部使用了一致的同步性的时候，这些属性中的每一个属性都遵循比较简单的原则：和所有同步的内存块一样，每个同步块之内的任何变化都具备了原子性以及可见性，和其他同步方法以及同步块遵循同样一致的原则，而且在这样的一个模型内，每个同步块不能使用同一个锁，在整个程序的调用过程是按照编写的程序指定指令运行的。即使某一个同步块内的处理可能会失效，但是该问题不会影响到其他线程的同步问题，也不会引起连环失效。简单讲：当程序运行的时候使用了一致的同步性的时候，每个同步块有一个独立的空间以及独立的同步控制器和锁机制，然后对外按照JVM的执行指令进行数据的读写操作。这种情况使得使用内存的过程变得非常严谨！　　如果不使用同步或者说使用同步不一致（这里可以理解为异步，但不一定是异步操作），该程序执行的答案就会变得极其复杂。而且在这样的情况下，该内存模型处理的结果比起大多数程序员所期望的结果而言就变得十分脆弱，甚至比起JVM提供的实现都脆弱很多。因为这样所以出现了Java针对该内存操作的最简单的语言规范来进行一定的习惯限制，排除该情况发生的做法在于：　　JVM线程必须依靠自身来维持对象的可见性以及对象自身应该提供相对应的操作而实现整个内存操作的三个特性，而不是仅仅依靠特定的修改对象状态的线程来完成如此复杂的一个流程。　　【*：综上所属，JMM在JVM内部实现的结构就变得相对复杂，当然一般的Java初学者可以不用了解得这么深入。】　　[4]三个特性的解析（针对JMM内部）：　　原子性（Atomicity）：　　访问存储单元内的任何类型的字段的值以及对其更新操作的时候，除开long类型和double类型，其他类型的字段是必须要保证其原子性的，这些字段也包括为对象服务的引用。此外，该原子性规则扩展可以延伸到基于long和double的另外两种类型：volatile long和volatile double（volatile为java关键字），没有被volatile声明的long类型以及double类型的字段值虽然不保证其JMM中的原子性，但是是被允许的。针对non-long/non-double的字段在表达式中使用的时候，JMM的原子性有这样一种规则：如果你获得或者初始化该值或某一些值的时候，这些值是由其他线程写入，而且不是从两个或者多个线程产生的数据在同一时间戳混合写入的时候，该字段的原子性在JVM内部是必须得到保证的。也就是说JMM在定义JVM原子性的时候，只要在该规则不违反的条件下，JVM本身不去理睬该数据的值是来自于什么线程，因为这样使得Java语言在并行运算的设计的过程中针对多线程的原子性设计变得极其简单，而且即使开发人员没有考虑到最终的程序也没有太大的影响。再次解释一下：这里的原子性指的是原子级别的操作，比如最小的一块内存的读写操作，可以理解为Java语言最终编译过后最接近内存的最底层的操作单元，这种读写操作的数据单元不是变量的值，而是本机码，也就是前边在讲《Java基础知识》中提到的由运行器解释的时候生成的Native Code。　　可见性（Visibility）：　　当一个线程需要修改另外线程的可见单元的时候必须遵循以下原则：
  • 一个写入线程释放的同步锁和紧随其后进行读取的读线程的同步锁是同一个
    从本质上讲，释放锁操作强迫它的隶属线程【释放锁的线程】从工作内存中的写入缓存里面刷新（专业上讲这里不应该是刷新，可以理解为提供）数据（flush操作），然后获取锁操作使得另外一个线程【获得锁的线程】直接读取前一个线程可访问域（也就是可见区域）的字段的值。因为该锁内部提供了一个同步方法或者同步块，该同步内容具有线程排他性，这样就使得上边两个操作只能针对单一线程在同步内容内部进行操作，这样就使得所有操作该内容的单一线程具有该同步内容（加锁的同步方法或者同步块）内的线程排他性，这种情况的交替也可以理解为具有“短暂记忆效应”。
    这里需要理解的是同步的双重含义：使用锁机制允许基于高层同步协议进行处理操作，这是最基本的同步；同时系统内存（很多时候这里是指基于机器指令的底层存储关卡memory barrier，前边提到过）在处理同步的时候能够跨线程操作，使得线程和线程之间的数据是同步的。这样的机制也折射出一点，并行编程相对于顺序编程而言，更加类似于分布式编程。后一种同步可以作为JMM机制中的方法在一个线程中运行的效果展示，注意这里不是多个线程运行的效果展示，因为它反应了该线程愿意发送或者接受的双重操作，并且使得它自己的可见区域可以提供给其他线程运行或者更新，从这个角度来看，使用锁和消息传递可以视为相互之间的变量同步，因为相对其他线程而言，它的操作针对其他线程也是对等的。
  • 一旦某个字段被申明为volatile，在任何一个写入线程在工作内存中刷新缓存的之前需要进行进一步的内存操作，也就是说针对这样的字段进行立即刷新，可以理解为这种volatile不会出现一般变量的缓存操作，而读取线程每次必须根据前一个线程的可见域里面重新读取该变量的值，而不是直接读取。
  • 当某个线程第一次去访问某个对象的域的时候，它要么初始化该对象的值，要么从其他写入线程可见域里面去读取该对象的值；这里结合上边理解，在满足某种条件下，该线程对某对象域的值的读取是直接读取，有些时候却需要重新读取。
    这里需要小心一点的是，在并发编程里面，不好的一个实践就是使用一个合法引用去引用不完全构造的对象，这种情况在从其他写入线程可见域里面进行数据读取的时候发生频率比较高。从编程角度上讲，在构造函数里面开启一个新的线程是有一定的风险的，特别是该类是属于一个可子类化的类的时候。Thread.start由调用线程启动，然后由获得该启动的线程释放锁具有相同的“短暂记忆效应”，如果一个实现了Runnable接口的超类在子类构造子执行之前调用了Thread(this).start()方法，那么就可能使得该对象在线程方法run执行之前并没有被完全初始化，这样就使得一个指向该对象的合法引用去引用了不完全构造的一个对象。同样的，如果创建一个新的线程T并且启动该线程，然后再使用线程T来创建对象X，这种情况就不能保证X对象里面所有的属性针对线程T都是可见的除非是在所有针对X对象的引用中进行同步处理，或者最好的方法是在T线程启动之前创建对象X。
  • 若一个线程终止，所有的变量值都必须从工作内存中刷到主存，比如，如果一个同步线程因为另一个使用Thread.join方法的线程而终止，那么该线程的可见域针对那个线程而言其发生的改变以及产生的一些影响是需要保证可知道的。
    1 楼 liuxuejin 2011-04-08   工作内存在哪里的？？