1.JMM简介
Java平台自动集成了以及，这种集成程度比Java以前诞生的计算机语言要厉害很多，该语言针对而使用的多线程技术支持也是具有开拓性的一面，有时候在开发要求很严格的程序时，往往容易混淆的一个概念就是内存模型 。究竟什么是内存模型？内存模型描述了程序中各个变量（实例域、静态域和数组元素）之间的关系，以及在实际计算机系统中将变量存储到内存和从内存中取出变量这样的底层细节，对象最终是存储在内存里面的，这点没有错，但是或者可以有特权在变量指定内存位置存储或者取出变量的值。【JMM
】（Java Memory Model的缩写） 允许编译器和缓存以数据在处理器特定的缓存（或寄存器）和主存 之间移动的次序拥有重要的特权，除非程序员使用了final 或synchronized 明确请求了某些的保证。
】（Java Memory Model的缩写） 允许编译器和缓存以数据在处理器特定的缓存（或寄存器）和主存 之间移动的次序拥有重要的特权，除非程序员使用了final 或synchronized 明确请求了某些的保证。
在Java语言规范里面指出了JMM是一个比较开拓性的尝试，这种尝试视图定义一个的内存模型，但是它有一些比较细微而且很重要的缺点。其实Java语言里面比较的关键字主要是synchronized 和volatile ，也因为这样在开发过程中往往开发者会忽略掉这些规则，这也使得编写比较困难。
JSR133本身的目的是为了修复原本JMM的一些缺陷而提出的，其本身的制定目标有以下几个：
提供（ out-of-thin-air safety ） 无中生有安全性，这样“正确同步的”应该被正式而且直观地定义 程序员要有信心开发多线程程序，当然没有其他办法使得并发程序变得很容易开发，但是该规范的发布主要目标是为了减轻程序员理解内存模型中的一些细节负担 提供大范围的流行硬件体系结构上的高性能JVM实现，现在的处理器在它们的内存模型上有着很大的不同，JMM应该能够适合于实际的尽可能多的体系结构而不以性能为代价，这也是Java跨平台型设计的基础
提供一个同步的习惯用法，以允许发布一个对象使他不用同步就可见，这种情况又称为的新的安全保证
提供一个同步的习惯用法，以允许发布一个对象使他不用同步就可见，这种情况又称为的新的安全保证
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 的操作就是一个简单的异步操作。
Java内存模型的两个关键概念： 和
开发过多线程程序的程序员都明白，synchronized 关键字强制实施一个线程之间的 ，该互斥锁防止每次有多个线程进入一个给定监控器所保护的，也就是说在该情况下，执行程序代码所独有的某些内存是独占模式 ，其他的线程 是不能针对它执行过程所独占的内存进行访问的，这种情况称为该内存。但是在该模型的同步模式中，还有另外一个方面：JMM中指出了，JVM在处理该强制实施的时候可以提供一些内存的，在该规则里面，它确保当存在一个同步块时，缓存被更新，当输入一个同步块时，缓存失效。因此在JVM内部提供给定监控器保护的同步块之中，一个线程所写入的值对于其余所有的执行由来说是，这就是一个简单的可见性的描述。这种机器保证编译器不会把指令从一个同步块的内部移到外部，虽然有时候它会把指令由外部移动到内部
。JMM在缺省情况下不做这样的保证——只要有多个线程访问相同变量时必须使用同步 。简单总结：
。JMM在缺省情况下不做这样的保证——只要有多个线程访问相同变量时必须使用同步 。简单总结：
可见性就是在多核或者多线程运行过程中内存的一种共享模式，在JMM模型里面，通过并发线程修改变量值的时候，必须将线程变量同步回主存过后，其他线程才可能访问到。
【*：简单讲，内存的可见性使内存资源可以共享，当一个线程执行的时候它所占有的内存，如果它占有的内存资源是可见的，那么这时候其他线程在一定规则内是可以访问该内存资源的，这种规则是由JMM内部定义的，这种情况下内存的该特性称为其可见性。】
可排序性提供了内存内部的访问顺序 ，在不同的程序针对不同的内存块进行访问的时候，其访问，比如有一个内存块，A和B需要访问的时候，JMM会提供一定的内存分配策略有序地分配它们使用的内存，而在内存的调用过程也会变得有序地进行，内存的折中性质可以简单理解为有序性。而在Java多线程程序里面，JMM通过Java关键字volatile来保证内存的有序访问。
Java语言规范中提到过，JVM中存在一个主存区（Main Memory或Java Heap Memory ） ，Java中都是存在主存中的，对于所有线程进行共享，而每个线程又存在自己的工作内存（Working Memory ） ，工作内存中保存的是主存中某些变量的拷贝，线程对所有变量的操作发生在主存区，而是中，而线程之间是不能直接相互访问
，变量在程序中的传递，是依赖主存 来完成的。而在多核处理器下，大部分数据存储在中，如果高速缓存不经过内存的时候，也是不可见的一种表现。在Java程序中，内存本身是比较昂贵的资源，其实不仅仅针对Java应用程序，对操作系统本身而言内存也属于昂贵资源，Java程序在性能开销过程中有几个比较典型的可控制的来源。synchronized 和volatile 关键字提供的内存中模型的可见性保证程序使用一个特殊的、存储关卡（memory barrier ）
的指令，来刷新缓存，使缓存无效，刷新硬件的写缓存并且延迟执行的传递过程，无疑该机制会对Java程序的性能产生一定的影响。
，变量在程序中的传递，是依赖主存 来完成的。而在多核处理器下，大部分数据存储在中，如果高速缓存不经过内存的时候，也是不可见的一种表现。在Java程序中，内存本身是比较昂贵的资源，其实不仅仅针对Java应用程序，对操作系统本身而言内存也属于昂贵资源，Java程序在性能开销过程中有几个比较典型的可控制的来源。synchronized 和volatile 关键字提供的内存中模型的可见性保证程序使用一个特殊的、存储关卡（memory barrier ）
的指令，来刷新缓存，使缓存无效，刷新硬件的写缓存并且延迟执行的传递过程，无疑该机制会对Java程序的性能产生一定的影响。
JMM的最初目的，就是为了能够支持多线程程序设计的，每个线程可以认为是和其他线程不同的CPU上运行，或者对于多处理器的机器而言，该模型需要实现的就是使得每一个线程就像运行在不同的机器、不同的CPU 或者本身就不同的线程上一样，这种情况实际上在项目开发中是常见的。对于CPU本身而言，不能直接访问其他，模型必须通过某种定义规则来使得线程和线程在而实现CPU本身对其他CPU、或者说线程对其他线程的内存中资源的访问
，而表现这种规则的运行环境一般为运行该程序的运行宿主环境，而程序本身表现就依赖于编写该程序的语言特性，这里也就是说用Java编写的应用程序在内存管理中的实现就是遵循其部分原则，也就是前边提及到的JMM定义了Java语言针对内存的一些的。然而，虽然设计之初是为了能够更好支持多线程，但是该模型的应用和实现当然不局限于多处理器，而在JVM编译器编译Java编写的程序的时候以及运行期执行该程序的时候，对于的系统而言，这种规则也是有效的，这就是是上边提到的线程和线程之间的内存策略。JMM本身在描述过程没有提过具体的内存地址以及在实现该策略中的实现方法是由JVM的哪一个环节提供的机制来实现的，甚至针对一个开发非常熟悉的程序员，也不一定能够了解它内部对于类、对象、方法以及相关内容的一些具体可见的物理结构
。相反，JMM定义了一个之间的抽象关系 ，其实从上边的图可以知道，每一个线程可以抽象成为一个工作内存，其中存储了Java的一些值，该模型保证了Java里面的属性、方法、字段存在一定的数学特性 ，按照该特性，该模型存储了对应的一些内容，并且针对这些内容进行了一定的序列化以及存储排序操作 ，这样使得Java对象在工作内存里面被JVM顺利调用，（当然这是比较抽象的一种解释）既然如此，大多数JMM的规则在实现的时候，必须使得主存和工作内存之间的通信
能够得以保证，而且不能违反内存模型本身的结构，这是语言在设计之处必须考虑到的针对内存的一种设计方法。这里需要知道的一点是，这一切的操作在Java语言里面都是依靠Java语言自身来操作的，因为Java针对开发人员而言，内存的管理在不需要手动操作的情况下本身存在内存的管理策略，这也是Java自己进行内存管理的一种优势。
，而表现这种规则的运行环境一般为运行该程序的运行宿主环境，而程序本身表现就依赖于编写该程序的语言特性，这里也就是说用Java编写的应用程序在内存管理中的实现就是遵循其部分原则，也就是前边提及到的JMM定义了Java语言针对内存的一些的。然而，虽然设计之初是为了能够更好支持多线程，但是该模型的应用和实现当然不局限于多处理器，而在JVM编译器编译Java编写的程序的时候以及运行期执行该程序的时候，对于的系统而言，这种规则也是有效的，这就是是上边提到的线程和线程之间的内存策略。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内部 ）：
访问存储单元内的任何类型的字段的值以及对其更新操作的时候，除开 long 类型和double 类型，其他类型的字段是必须要保证其原子性的，这些字段也包括为对象服务的引用。此外，该原子性规则扩展可以延伸到基于long和double的另外两种类型 ：volatile long 和volatile double
，没有被volatile 声明的long 类型以及double 类型的字段值虽然不保证其JMM中的原子性，但是是被允许的。针对non-long/non-double 的字段在表达式中使用的时候，JMM的原子性有这样一种规则：如果你获得或者初始化该值或某一些值的时候，这些值是由其他线程 ，而且不是从两个或者多个线程产生的数据在同一时间戳混合写入的时候，该在JVM内部是必须得到保证的。也就是说JMM在定义JVM原子性的时候，只要在该规则不违反的条件下，JVM本身不去理睬该数据的值是来自于什么线程
，因为这样使得Java语言在并行运算的设计的过程中针对多线程的原子性设计变得极其简单，而且即使开发人员没有考虑到最终的程序也没有太大的影响。再次解释一下：这里的原子性指的是原子级别的操作，比如最小的一块内存的读写操作，可以理解为Java语言最终编译过后最接近内存的最底层的操作单元，这种读写操作的数据单元不是变量的值，而是本机码，也就是前边在讲《Java基础知识》中提到的由运行器解释的时候生成的。
，没有被volatile 声明的long 类型以及double 类型的字段值虽然不保证其JMM中的原子性，但是是被允许的。针对non-long/non-double 的字段在表达式中使用的时候，JMM的原子性有这样一种规则：如果你获得或者初始化该值或某一些值的时候，这些值是由其他线程 ，而且不是从两个或者多个线程产生的数据在同一时间戳混合写入的时候，该在JVM内部是必须得到保证的。也就是说JMM在定义JVM原子性的时候，只要在该规则不违反的条件下，JVM本身不去理睬该数据的值是来自于什么线程
，因为这样使得Java语言在并行运算的设计的过程中针对多线程的原子性设计变得极其简单，而且即使开发人员没有考虑到最终的程序也没有太大的影响。再次解释一下：这里的原子性指的是原子级别的操作，比如最小的一块内存的读写操作，可以理解为Java语言最终编译过后最接近内存的最底层的操作单元，这种读写操作的数据单元不是变量的值，而是本机码，也就是前边在讲《Java基础知识》中提到的由运行器解释的时候生成的。
当一个线程需要修改另外线程的可见单元的时候必须遵循以下原则：
一个写入线程释放的同步锁和紧随其后进行读取的读线程的同步锁是同一个
从本质上讲，释放锁操作强迫它的隶属线程 从工作内存中的写入缓存里面刷新（专业上讲这里不应该是刷新，可以理解为提供）数据（flush操作），然后获取锁操作使得另外一个线程 直接读取前一个线程
可访问域（也就是可见区域） 的字段的值。因为该锁内部提供了一个同步方法或者同步块，该同步内容具有 ，这样就使得上边两个操作只能针对单一线程在同步内容内部进行操作，这样就使得所有操作该内容的单一线程具有该同步内容
（加锁的同步方法或者同步块） 内的线程排他性，这种情况的交替也可以理解为具有 “短暂记忆效应 ”。
：使用锁机制允许基于高层同步协议进行处理操作，这是最基本的同步；同时系统内存（很多时候这里是指基于机器指令的底层存储关卡memory barrier，前边提到过）在处理同步的时候能够跨线程操作，使得线程和线程之间的数据是同步的 。这样的机制也折射出一点，并行编程相对于顺序编程而言，更加类似于分布式编程。后一种同步可以作为JMM机制中的方法在一个线程中运行的效果展示，注意这里不是多个线程运行的效果展示，因为它反应了该线程愿意发送或者接受的双重操作，并且使得它自己的可见区域可以提供给其他线程运行或者更新，从这个角度来看，使用
可以视为相互之间的变量同步，因为相对其他线程而言，它的操作针对其他线程也是对等的。 一旦某个字段被申明为volatile，在任何一个写入线程在工作内存中刷新缓存的之前需要进行进一步的内存操作
，也就是说针对这样的字段进行立即刷新，可以理解为这种 volatile 不会出现一般变量的缓存操作，而读取线程每次必须根据前一个线程的 里面重新读取该变量的值，而 不是直接读取 。
当某个线程第一次去访问某个对象的域的时候，它要么初始化该对象的值，要么从其他写入线程可见域里面去读取该对象的值 ；这里结合上边理解，在满足某种条件下，该线程对某对象域的值的读取是直接读取，有些时候却需要重新读取。
这里需要小心一点的是，在并发编程里面， 一个实践就是使用 一个合法引用去引用不完全构造的对象 ，这种情况在从其他写入线程可见域里面进行数据读取的时候发生频率比较高。从编程角度上讲，在构造函数里面开启一个新的线程是有一定的风险的，特别是该类是属于一个可子类化的类的时候。Thread.start由调用线程启动，然后由获得该启动的线程释放锁具有相同的“短暂记忆效应”，如果一个实现了 Runnable接口的 超类在子类构造子执行之前 调用了
Thread(this).start() 方法，那么就可能使得该对象在线程方法run执行之前并 没有被完全初始化 ，这样就使得一个指向该对象的合法引用去引用了 的一个对象。 同样的，如果创建一个新的线程T并且启动该线程，然后再使用线程T来创建对象X，这种情况就不能保证X对象里面所有的属性针对线程T都是可见的除非是在所有针对X对象的引用中进行同步处理，或者最好的方法是在T线程启动之前创建对象X。 ，比如，如果一个同步线程因为另一个使用Thread.join方法的线程而终止，那么该线程的
针对那个线程而言其发生的改变以及产生的一些影响是需要保证可知道的。
从本质上讲，释放锁操作强迫它的隶属线程 从工作内存中的写入缓存里面刷新（专业上讲这里不应该是刷新，可以理解为提供）数据（flush操作），然后获取锁操作使得另外一个线程 直接读取前一个线程
可访问域（也就是可见区域） 的字段的值。因为该锁内部提供了一个同步方法或者同步块，该同步内容具有 ，这样就使得上边两个操作只能针对单一线程在同步内容内部进行操作，这样就使得所有操作该内容的单一线程具有该同步内容
（加锁的同步方法或者同步块） 内的线程排他性，这种情况的交替也可以理解为具有 “短暂记忆效应 ”。
：使用锁机制允许基于高层同步协议进行处理操作，这是最基本的同步；同时系统内存（很多时候这里是指基于机器指令的底层存储关卡memory barrier，前边提到过）在处理同步的时候能够跨线程操作，使得线程和线程之间的数据是同步的 。这样的机制也折射出一点，并行编程相对于顺序编程而言，更加类似于分布式编程。后一种同步可以作为JMM机制中的方法在一个线程中运行的效果展示，注意这里不是多个线程运行的效果展示，因为它反应了该线程愿意发送或者接受的双重操作，并且使得它自己的可见区域可以提供给其他线程运行或者更新，从这个角度来看，使用
可以视为相互之间的变量同步，因为相对其他线程而言，它的操作针对其他线程也是对等的。 一旦某个字段被申明为volatile，在任何一个写入线程在工作内存中刷新缓存的之前需要进行进一步的内存操作
，也就是说针对这样的字段进行立即刷新，可以理解为这种 volatile 不会出现一般变量的缓存操作，而读取线程每次必须根据前一个线程的 里面重新读取该变量的值，而 不是直接读取 。
当某个线程第一次去访问某个对象的域的时候，它要么初始化该对象的值，要么从其他写入线程可见域里面去读取该对象的值 ；这里结合上边理解，在满足某种条件下，该线程对某对象域的值的读取是直接读取，有些时候却需要重新读取。
这里需要小心一点的是，在并发编程里面， 一个实践就是使用 一个合法引用去引用不完全构造的对象 ，这种情况在从其他写入线程可见域里面进行数据读取的时候发生频率比较高。从编程角度上讲，在构造函数里面开启一个新的线程是有一定的风险的，特别是该类是属于一个可子类化的类的时候。Thread.start由调用线程启动，然后由获得该启动的线程释放锁具有相同的“短暂记忆效应”，如果一个实现了 Runnable接口的 超类在子类构造子执行之前 调用了
Thread(this).start() 方法，那么就可能使得该对象在线程方法run执行之前并 没有被完全初始化 ，这样就使得一个指向该对象的合法引用去引用了 的一个对象。 同样的，如果创建一个新的线程T并且启动该线程，然后再使用线程T来创建对象X，这种情况就不能保证X对象里面所有的属性针对线程T都是可见的除非是在所有针对X对象的引用中进行同步处理，或者最好的方法是在T线程启动之前创建对象X。 ，比如，如果一个同步线程因为另一个使用Thread.join方法的线程而终止，那么该线程的
针对那个线程而言其发生的改变以及产生的一些影响是需要保证可知道的。
注意：如果在同一个线程里面通过方法调用去传一个对象的引用是绝对不会出现上边提及到的可见性问题的。JMM保证所有上边的规定以及关于内存可见性特性的描述——一个特殊的更新、一个特定字段的修改都是的一个“可见性”的概念，最终它发生的场所在内存模型中Java线程和线程之间，至于这个发生时间可以是一个任意长的时间，但是最终会发生，也就是说，Java内存模型中的可见性的特性主要是针对线程和线程之间使用内存的一种规则和约定，该约定由JMM定义。
不仅仅如此，该模型还允许不同步的情况下可见性特性。比如针对一个线程提供一个对象或者字段访问域的原始值进行操作，而针对另外一个线程提供一个对象或者字段刷新过后的值进行操作。同样也有可能针对一个线程读取一个原始的值以及引用对象的对象内容，针对另外一个线程读取一个刷新过后的值或者刷新过后的引用。
尽管如此，上边的可见性特性分析的一些特征在跨线程操作的时候是的，而且不能够避免这些故障发生。这是一个不争的事实，使用同步多线程的代码并不能绝对保证 线程安全的行为，只是允许某种规则对其操作进行一定的限制，但是在最新的JVM实现以及最新的Java平台中，即使是多个处理器，通过一些工具进行可见性的测试发现其实是很少发生故障的。跨线程共享CPU的共享缓存的使用，其缺陷就在于影响了编译器的优化操作，这也体现了强有力的使得硬件的价值有所提升，因为它们之间的关系在线程与线程之间的复杂度变得更高。这种方式使得可见度的自由测试显得更加不切实际，因为这些错误的发生极为罕见，或者说在平台上我们开发过程中根本碰不到。在并行程开发中，不使用同步导致失败的原因也不仅仅是对可见度的不良把握导致的，导致其程序失败的原因是多方面的，包括问题等。
从操作线程的角度看来，如果所有的指令执行都是按照进行，那么对于一个顺序运行的程序而言，可排序性也是顺序的 从其他操作线程的角度看来，排序性如同在这个线程中运行在非同步方法中的一个“”，所以任何事情都有可能发生。唯一有用的限制是同步方法和同步块的相对排序，就像操作字段一样，总是保留下来使用
【*：如何理解这里“间谍”的意思，可以这样理解，排序规则在本线程里面遵循了第一条法则，但是对其他线程而言，某个线程自身的排序特性可能使得它不定地访问执行线程的可见域，而使得该线程对本身在执行的线程产生一定的影响。举个例子，A线程需要做三件事情分别是A1、A2、A3，而B是另外一个线程具有操作 B1、B2，如果把参考定位到B线程，那么对A线程而言，B的操作B1、B2有可能随时会访问到A的可见区域，比如A有一个可见区域a，A1就是把a修改称为1，但是B线程在A线程调用了A1过后，却访问了a并且使用B1或者B2操作使得a发生了改变，变成了2，那么当A按照排序性进行A2操作读取到a的值的时候，读取到的是2而不是1，这样就使得程序最初设计的时候A线程的初衷发生了改变，就是排序被打乱了，那么B线程对A线程而言，其身份就是“间谍”，而且需要注意到一点，B线程的这些操作不会和A之间存在等待关系，那么B线程的这些操作就是异步操作，所以针对执行线程A而言，B的身份就是“非同步方法中的‘间谍’。】
同样的，这仅仅是一个最低限度的保障性质，在任何给定的程序或者平台，开发中有可能发现更加严格的排序，但是开发人员在设计程序的时候不能依赖这种排序，如果依赖它们会发现测试难度会成指数级递增，而且在复合规定的时候会因为不同的特性使得JVM的实现因为不符合设计初衷而失败。
第一点在JLS（Java Language Specification）的所有讨论中也是被采用的，例如算数表达式一般情况都是从上到下、从左到右的顺序，但是这一点需要理解的是，从其他操作线程的角度看来这一点又具有不确定性，对线程内部而言，其内存模型本身是存在排序性的。【*：这里讨论的排序是最底层的内存里面执行的时候的NativeCode的排序，不是说按照顺序执行的Java代码具有的有序性质，本文主要分析的是JVM的内存模型，所以希望读者明白这里指代的讨论单元是内存区。】
JMM最初设计的时候存在一定的缺陷，这种缺陷虽然现有的JVM平台已经修复，但是这里不得不提及，也是为了读者更加了解JMM的设计思路，这一个小节的概念可能会牵涉到很多更加深入的知识，如果读者不能读懂没有关系先看了文章后边的章节再返回来看也可以。
1)问题1：不可变对象不是不可变的
学过Java的朋友都应该知道Java中的不可变对象，这一点在本文最后讲解String类的时候也会提及，而JMM最初设计的时候，这个问题一直都存在，就是：不可变对象似乎可以改变它们的值 （这种对象的不可变指通过使用final关键字来得到保证） ，（：让一个对象的所有字段都为final并不一定使得这个对象不可变——所有类型还必须是原始类型而不能是对象的引用 。而不可变对象被认为不要求同步的。但是，因为在将内存写方面的更改从一个线程传播到另外一个线程的时候存在潜在的延迟，这样就使得有可能存在一种竞态条件，即允许一个线程首先看到不可变对象的一个值，一段时间之后看到的是一个不同的值。这种情况以前怎么发生的呢？在中的String实现里，这儿基本有三个重要的决定性字段：。String就是以这样的方式在JDK
1.4中实现的，而不是只有字符数组，因此字符数组可以在多个String和StringBuffer对象之间共享，而不需要在每次创建一个String的时候都拷贝到一个新的字符数组里。假设有下边的代码：
1.4中实现的，而不是只有字符数组，因此字符数组可以在多个String和StringBuffer对象之间共享，而不需要在每次创建一个String的时候都拷贝到一个新的字符数组里。假设有下边的代码：
s2 = s1.substring(4); // "/tmp"
这种情况下，字符串s2将具有大小为4的长度和偏移量 ，但是它将和s1共享“/usr/tmp” 里面的同一字符数组，在String构造函数运行之前，Object的构造函数将用它们默认的值初始化所有的字段，包括决定性的长度和偏移字段 。当String构造函数运行的时候，字符串长度和偏移量被设置成所需要的值。但是在旧的内存模型中，因为缺乏同步，有可能另一个线程会临时地看到偏移量字段具有初始默认值，而后又看到正确的值，结果是s2的值从“/usr”
变成了“/tmp” ，这并不是我们真正的初衷，这个问题就是原始JMM的第一个缺陷所在，因为在原始JMM模型里面这是合理而且合法的，以下的版本都允许这样做。
变成了“/tmp” ，这并不是我们真正的初衷，这个问题就是原始JMM的第一个缺陷所在，因为在原始JMM模型里面这是合理而且合法的，以下的版本都允许这样做。
2)问题2：重新排序的易失性和非易失性存储
另一个主要领域是与volatile 字段的内存操作重新排序有关，这个领域中现有的JMM引起了一些比较混乱的结果。现有的JMM表明易失性的读和写是直接和主存 打交道的，这样避免了把值存储到寄存器 或者绕过处理器特定的缓存 ，这使得多个线程一般能看见一个给定变量最新的值。可是，结果是这种volatile定义并没有最初想象中那样如愿以偿，并且导致了volatile的重大混乱。为了在缺乏同步的情况下提供较好的性能，编译器、运行时和缓存通常是允许进行内存的重新排序操作的，只要当前执行的线程分辨不出它们的区别。（这就是within-thread
as-if-serial semantics[线程内似乎是串行 ] 的解释）但是，易失性的读和写是完全跨线程安排的，编译器或缓存不能在彼此之间重新排序易失性的读和写。遗憾的是，通过参考普通变量的读写，JMM允许易失性的读和写被重排序，这样以为着开发人员不能使用易失性标志作为操作已经完成的标志。比如：
as-if-serial semantics[线程内似乎是串行 ] 的解释）但是，易失性的读和写是完全跨线程安排的，编译器或缓存不能在彼此之间重新排序易失性的读和写。遗憾的是，通过参考普通变量的读写，JMM允许易失性的读和写被重排序，这样以为着开发人员不能使用易失性标志作为操作已经完成的标志。比如：
initialized = false ;
configOptions = HashMap();
configText = readConfigFile(filename);
processConfigOptions(configText,configOptions);
sleep();
这里的思想是使用易失性变量initialized担任守卫来表明一套别的操作已经完成了，这是一个很好的思想，但是不能在JMM下工作，因为旧的 JMM允许非易失性的写（比如写到configOptions字段，以及写到由configOptions引用Map的字段中）与易失性的写一起重新排序，因此另外一个线程可能会看到initialized为true ，但是对于configOptions字段或它所引用的对象还没有一个一致的或者说当前的针对内存的视图变量，volatile
的旧语义只承诺在读和写的变量的可见性，而不承诺其他变量，虽然这种方法更加有效的实现，但是结果会和我们设计之初大相径庭。
的旧语义只承诺在读和写的变量的可见性，而不承诺其他变量，虽然这种方法更加有效的实现，但是结果会和我们设计之初大相径庭。
内存管理在Java语言中是JVM自动操作的，当JVM发现某些对象不再需要的时候，就会对该对象占用的内存进行重分配（释放）操作，而且使得分配出来的内存能够提供给所需要的对象。在一些编程语言里面，内存管理是一个程序的职责，但是书写过C++的程序员很清楚，如果该程序需要自己来书写很有可能引起很严重的错误或者说不可预料的程序行为，最终大部分开发时间都花在了调试这种程序以及修复相关错误上。一般情况下在Java程序开发过程把手动内存管理称为显示内存管理
，而显示内存管理 经常发生的一个情况就是——也就是说有可能在重新分配过程释放掉了一个被某个对象引用正在使用的内存空间，释放掉该空间过后，该引用就处于悬挂状态。如果这个被悬挂引用指向的对象试图进行原来对象（因为这个时候该对象有可能已经不存在了） 进行操作的时候，由于该对象本身的内存空间已经被手动释放掉了，这个结果是不可预知的。显示内存管理另外一个常见的情况是，当某些引用不再引用该内存对象的时候，而该对象原本占用的内存并没有被释放，这种情况简言为内存泄漏 。比如，如果针对某个链表进行了内存分配，而因为手动分配不当，仅仅让引用指向了某个元素所处的内存空间，这样就使得其他链表中的元素不能再被引用而且使得这些元素所处的内存让应用程序处于不可达状态而且这些对象所占有的内存也不能够被再使用，这个时候就发生了内存泄漏。而这种情况一旦在程序中发生，就会，而针对计算机而言内存泄漏的严重程度大了会使得本来正常运行的程序直接因为内存不足而中断，并不是Java程序里面出现Exception
那么轻量级。
，而显示内存管理 经常发生的一个情况就是——也就是说有可能在重新分配过程释放掉了一个被某个对象引用正在使用的内存空间，释放掉该空间过后，该引用就处于悬挂状态。如果这个被悬挂引用指向的对象试图进行原来对象（因为这个时候该对象有可能已经不存在了） 进行操作的时候，由于该对象本身的内存空间已经被手动释放掉了，这个结果是不可预知的。显示内存管理另外一个常见的情况是，当某些引用不再引用该内存对象的时候，而该对象原本占用的内存并没有被释放，这种情况简言为内存泄漏 。比如，如果针对某个链表进行了内存分配，而因为手动分配不当，仅仅让引用指向了某个元素所处的内存空间，这样就使得其他链表中的元素不能再被引用而且使得这些元素所处的内存让应用程序处于不可达状态而且这些对象所占有的内存也不能够被再使用，这个时候就发生了内存泄漏。而这种情况一旦在程序中发生，就会，而针对计算机而言内存泄漏的严重程度大了会使得本来正常运行的程序直接因为内存不足而中断，并不是Java程序里面出现Exception
那么轻量级。
在以前的编程过程中，手动内存管理带了计算机程序不可避免的错误，而且这种错误对计算机程序是毁灭性的，所以内存管理就成为了一个很重要的话题，但是针对大多数纯面向对象语言而言，比如Java，提供了语言本身具有的内存特性：，这种语言提供了一个程序垃圾回收器（Garbage Collector [GC]） ，自动内存管理提供了一个抽象的接口以及更加可靠的代码使得内存能够在程序里面进行合理的分配。最常见的情况就是垃圾回收器避免了悬挂引用的问题，因为一旦这些对象没有被任何引用的时候，也就是这些对象在JVM的内存池里面成为了不可引用对象，该垃圾回收器会直接回收掉这些对象占用的内存，当然这些对象必须满足垃圾回收器回收的某些对象规则，而垃圾回收器在回收的时候会自动释放掉这些内存。不仅仅如此，垃圾回收器同样会解决内存泄漏问题。
ii.详解堆和栈 [图片以及部分内容来自《Inside JVM》]：
学过编译原理的人都明白，程序运行时有三种内存分配策略：
静态存储 ——是指在编译时就能够确定每个数据目标在运行时的存储空间需求，因而在编译时就可以给它们分配固定的内存空间。这种分配策略要求程序代码中不允许有可变数据结构的存在，也不允许有嵌套或者递归的结构出现，因为它们都会导致编译程序无法计算准确的存储空间。
栈式存储 —— 该分配可成为动态存储分配，是由一个类似于堆栈的运行栈来实现的，和静态存储的分配方式相反，在栈式存储方案中，程序对数据区的需求在编译时是完全未知的，只有到了运行的时候才能知道，但是规定在运行中进入一个程序模块的时候，必须知道该程序模块所需要的数据区的大小才能分配其内存。和我们在数据结构中所熟知的栈一样，栈式存储分配按照先进后出的原则进行分配。
堆式存储 ——堆式存储分配则专门负责在编译时或运行时模块入口处都无法确定存储要求的数据结构的内存分配，比如可变长度串和对象实例，堆由大片的可利用块或空闲块组成，堆中的内存可以按照任意顺序分配和释放。
[1 ：由编译器自动分配释放，存放函数的参数值，局部变量的值等。其操作方式类似于数据结构中的栈。我们在程序中定义的局部变量就是存放在栈里，当局部变量的生命周期结束的时候，它所占的内存会被自动释放。
：一般由程序员分配和释放，若程序员不释放，程序结束时可能由OS回收。注意它与数据结构中的堆是两回事，分配方式倒是类似于链表。我们在程序中使用c++中 new或者c中的malloc申请的一块内存，就是在heap上申请的，在使用完毕后，是需要我们自己动手释放的，否则就会产生“内存泄露”的问题。
[3]全局区（静态区）（Static ） ：全局变量和静态变量的存储是放在一块的，初始化的全局变量和静态变量在一块区域，未初始化的全局变量和未初始化的静态变量在相邻的另一块区域。程序结束后由系统释放。
[4]文字常量区 ：常量字符串就是放在这里的，程序结束后由系统释放。在Java中对应有一个字符串常量池。
[5]程序代码区 ：存放函数体的二进制代码
在Java虚拟机规范中，一个虚拟机实例的行为主要描述为：、、和，这些组件在描述了抽象的JVM内部的一个抽象结构。与其说这些组成部分的目的是进行JVM内部结构的一种支配，更多的是提供一种严格定义实现的外部行为，该规范定义了这些抽象组成部分以及相互作用的任何Java虚拟机执行所需要的行为。下图描述了JVM内部的一个结构，其中主要包括主要的，如同以前在《Java基础知识》中描述的：Java虚拟机有一个类加载器作为JVM的子系统，类加载器针对Class进行检测以鉴定完全合格的类接口，而JVM内部也有一个执行引擎：
当JVM运行一个程序的时候，它的内存需要用来存储很多内容，包括、以及出来的一些附加信息、以及程序中实例化的。JVM的内存组织需要在不同的运行时数据区进行以上的几个操作，下边针对上图里面出现的几个运行时数据区进行详细解析：一些运行时数据区共享了所有应用程序线程和其他特有的单个线程，每个JVM实例有一个方法区和一个内存堆 ，这些是共同在虚拟机内运行的线程。在Java程序里面，每个新的线程启动过后，它就会被JVM在内部分配自己的
（）和Java堆栈 （）。若该线程正在执行一个，在PC寄存器的值指示下一条指令执行，该线程在Java内存栈中保存了非本地Java方法调用状态，其状态包括局部变量、被调用的参数、它的返回值、以及中间计算结果。而调用的状态则是存储在独立的本地方法内存栈里面（），这种情况下使得这些本地方法和其他内存运行时数据区的内容尽可能保证和其他内存运行时数据区 独立，而且该方法的调用更靠近操作系统，这些方法执行的字节码有可能根据操作系统环境的不同使得其编译出来的本地字节码的结构也有一定的差异。JVM中的内存栈是一个，一个栈帧包含了某个Java方法调用的状态，当某个线程调用方法的时候，JVM就会将一个新的帧到Java内存栈，当方法调用完成过后，JVM将会从内存栈中该栈帧。JVM里面一个可以存放中间计算数据结果值的，其内部指令集使用Java栈空间
来存储中间计算的数据结果值，这种做法的设计是为了保持Java虚拟机的指令集紧凑，使得与寄存器原理能够紧密结合并且进行操作。
1)方法区（Method Area ）
在JVM实例中，对装载的类型信息是存储在一个中，当Java虚拟机加载了一个类型的时候，它会跟着这个Class的类型去路径里面查找对应的Class文件，类加载器读取类文件（线性二进制数据），然后将该文件传递给Java虚拟机，JVM从二进制数据中提取信息并且将这些信息存储在，而类中声明（静态）变量就是来自于方法区中存储的信息。在JVM里面用什么样的方式存储该信息是由JVM设计的时候决定的，例如：当数据进入方法的时候，多类文件字节的存储量以（第一次最重要的字节）
的顺序存储，尽管如此，一个虚拟机可以用任何方式针对这些数据进行存储操作，若它存储在一个Little-Endian处理器上，设计的时候就有可能将多文件字节的值按照顺寻存储。
的顺序存储，尽管如此，一个虚拟机可以用任何方式针对这些数据进行存储操作，若它存储在一个Little-Endian处理器上，设计的时候就有可能将多文件字节的值按照顺寻存储。
——【$ Big-Endian和Little-Endian】——
程序存储数据过程中，如果数据是跨越多个字节对象就必须有一种约定：
：对于跨越多个字节的对象，一般它所占的字节都是连续的，它的地址等于它所占字节最低地址，这种情况链表可能存储的仅仅是表头
比如：x，它的地址为0x100，那么它占据了内存中的0x100、0x101、0x102、0x103四个字节，所以一般情况我们觉得int 是4个字节。上边只是内存组织的一种情况，多字节对象在内存中的组织有两种约定，还有一种情况：若一个整数为W位，它的表示如下：
每一位表示为：[Xw-1,Xw-2,...,X1,X0]
它的 为：[Xw-1,Xw-2,...,Xw-8]
（Least Significant Byte ） 为：[X7,X6,...,X0]
谁位于内存的最低地址，即代表了该对象的地址，这样就引出了Big-Endian和Little-Endian的问题，如果LSB在MSB前，LSB是最低地址，则该机器是小端，反之则是大端。DES（Digital Equipment Corporation，现在是Compaq公司的一部分）和Intel机器（x86平台）一般采用小端，IBM、Motorola（Power PC）、Sun的机器一般采用大端。当然这种不能代表所有情况，有的CPU既能工作于小端、又可以工作于大端，比如ARM、Alpha、摩托罗拉的
PowerPC，这些情况根据具体的处理器型号有所不同。但是大部分操作系统（Windows、FreeBSD、Linux）一般都是Little Endian的，少部分系统（Mac OS）是Big Endian的，所以用什么方式存储还得依赖宿主操作系统环境。
由上图可以看到，映射访问（“写32位地址的0”）主要是由寄存器到内存、由内存到寄存器的一种数据映射方式，在上图可以看出的原子内存单位（Atomic Unit） 在系统内存中的增长方向为，而Little-Endian的地址增长方向为。举个例子：
上图中可以看出MSB的值存储了0x0A，这种情况下数据的高位是从内存的低地址开始存储的，然后开始增长，第二位0x0B就是存储在第二位的，如果是按照16位为一个存储单位，其存储方式又为：
在计算机中，最高有效位（MSB）是指位值的存储位置为转换为二进制数据后的最大值，MSB有时候在Big-Endian的架构中称为，这种情况下再往左边的内存位则不是数据位了，而是有效位数位置的，不仅仅如此，MSB也可以对应一个二进制符号位的符号位补码标记：“1”的含义为负，“0”的含义为正 。最高位代表了“最重要字节”，也就是说当某些多字节数据拥有了最大值的时候它就是存储的时候最高位数据的字节对应的内存位置：
与Big-Endian相对的就是Little-Endian的存储方式，同样按照8位为一个存储单位上边的数据0x0A0B0C0D存储格式为：
可以看到LSB的值存储的0x0D，也就是数据的最低位是从内存的低地址开始存储的，它的高位是逐渐增加内存分配空间进行存储的，如果按照十六位为存储单位存储格式为：
从上图可以看到最低的16位的存储单位里面存储的值为0x0C0D，接着才是0x0A0B，这样就可以看到按照数据从高位到低位在内存中存储的时候是从右到左进行递增存储的，实际上可以从写内存的顺序来理解，实际上数据存储在内存中无非在使用的时候是和，针对LSB的方式最好的书面解释就是向左增加来看待 ，如果真正在进行内存读写的时候使用这样的顺序，其意义就体现出来了：
按照这种读写格式，0x0D存储在最低内存地址，而从右往左的增长就可以看到LSB存储的数据为0x0D，和初衷吻合，则十六位的存储就可以按照下边的格式来解释：
实际上从上边的存储还会考虑到另外一个问题，如果按照这种方式从右往左的方式进行存储，如果是遇到Unicode文字就和从左到右的语言显示方式相反。比如一个单词“XRAY”，使用Little-Endian的方式存储格式为：
使用这种方式进行内存读写的时候就会发现计算机语言和语言本身 的顺序会有冲突，这种冲突主要是以使用语言的人的习惯有关，而书面化的语言从左到右就可以知道其冲突是不可避免的。我们一般使用语言的阅读方式都是从左到右，而低端存储（Little-Endian）的这种内存读写的方式使得我们最终从计算机里面读取字符需要进行倒序，而且考虑另外一个问题，如果是针对中文而言，一个字符是两个字节，就会出现整体顺序和每一个位的顺序会进行两次倒序操作
，这种方式真正在制作处理器的时候也存在一种计算上的冲突，而针对使用文字从左到右进行阅读的国家而言，从右到左的方式（Big-Endian）则会有这样的文字冲突，另外一方面，尽管有很多国家使用语言是从右到左，但是仅仅和Big-Endian的方式存在冲突，这些国家毕竟占少数，所以可以理解的是，为什么都是使用的Little-Endian的方式
，这种方式真正在制作处理器的时候也存在一种计算上的冲突，而针对使用文字从左到右进行阅读的国家而言，从右到左的方式（Big-Endian）则会有这样的文字冲突，另外一方面，尽管有很多国家使用语言是从右到左，但是仅仅和Big-Endian的方式存在冲突，这些国家毕竟占少数，所以可以理解的是，为什么都是使用的Little-Endian的方式
【*：这里不解释 Middle-Endian 的方式以及 Mixed-Endian 的方式】
在计算机中，最低有效位是一个二进制给予单位的整数，位的位置确定了该数据是一个偶数还是奇数
，LSB有时被称为最右位。在使用具体位二进制数之内，常见的存储方式就是每一位存储1或者0的方式，从0向上到1每一比特逢二进一的存储方式。，而这种方式也有可能产生一定的混乱。
，LSB有时被称为最右位。在使用具体位二进制数之内，常见的存储方式就是每一位存储1或者0的方式，从0向上到1每一比特逢二进一的存储方式。，而这种方式也有可能产生一定的混乱。
——以上 是关于Big-Endian和Little-Endian的简单讲解——
JVM虚拟机将搜索和使用类型的一些信息也存储在方法区中以方便应用程序加载读取该数据。设计者在设计过程也考虑到要方便JVM进行Java应用程序的快速执行，而这种取舍主要是为了程序在运行过程中内存不足的情况能够通过一定的取舍去弥补内存不足的情况。在JVM内部，的，因此，访问方法区的数据结构必须是 线程安全的，如果两个线程都试图去调用去找一个名为Lava的类，比如Lava还没有被加载，而另外的线程只能够等待。方法区的大小在分配过程中是不固定的，随着Java应用程序的运行，JVM可以调整其大小，需要注意一点，方法区的内存，因为方法区内存在中，即使是虚拟机JVM实例对象自己所在的内存堆也是可行的，而在实现过程是允许程序员自身来指定方法区的初始化大小的。
同样的，因为Java本身的自动内存管理，方法区也会被垃圾回收的，Java程序可以通过类扩展动态加载器对象，类可以成为“未引用”向垃圾回收器进行申请，如果一个类是“未引用”的，则该类就可能被卸载，
类型的完全限定名的直接父类的完全限定名（除非这个父类的类型是一个接口或者java.lang.Object）
在JVM和类文件名的内部，类型名一般都是完全限定名（java.lang.String）格式，在Java源文件里面，完全限定名必须加入包前缀，而不是我们在开发过程写的简单类名，而在方法上，只要是符合Java语言规范的类的完全限定名都可以，而JVM可能直接进行解析，比如：（java.lang.String）在JVM内部名称为java/lang/String，这就是我们在异常捕捉的时候经常看到的ClassNotFoundException的异常里面类信息的名称格式
。
。
除此之外，还必须为每一种加载过的类型在JVM内进行存储，下边的信息不存储在方法区内，下边的章节会一一说明
针对类型加载的类型信息，JVM将这些存储在常量池里，常量池是一个根据类型定义的常量的有序常量集，包括字面量（String、Integer、 Float常量）以及符号引用（类型、字段、方法），整个长量池会被JVM的一个索引引用，如同数组里面的元素集合按照索引访问一样，JVM针对这些常量池里面存储的信息也是按照索引方式进行。实际上长量池在Java程序的起到了一个至关重要的作用。
字段修饰符（ public,private,protected,static,final,volatile,transient ）
方法修饰符（ public,private,protected,static,final,synchronized,native,abstract ）
类变量在一个类的多个实例之间共享，这些变量直接和类相关，而不是和类的实例相关，（定义过程简单理解为类里面定义的 static 类型的变量） ，针对类变量，其逻辑部分就是存储在方法区内的。在JVM使用这些类之前，JVM先要在方法区里面为定义的分配内存空间；常量（定义为final）则在JVM内部则不是以同样的方式来进行存储的 ，尽管针对常量而言，一个final的类变量是拥有它自己的常量池，作为常量池里面的存储某部分，，而其逻辑部分则不是按照上边的类变量的方式来进行内存分配的。虽然non-final类变量是作为这些类型声明中存储数据的某一部分，final变量存储为任何使用它类型的一部分的数据格式进行简单存储。
对于每种类型的加载，JVM必须检测其类型是否符合了JVM的语言规范，对于通过类加载器加载的对象类型，JVM必须存储对类的引用，而这些针对类加载器的引用是作为了方法区里面的类型数据部分进行存储的。
JVM在加载了任何一个类型过后会，虚拟机必须通过一定的途径来引用该类型对应的一个Class的实例，并且将其存储在方法区内
为了提高访问效率，必须仔细的设计存储在方法区中的数据信息结构。除了以上讨论的结构，jvm的实现者还添加一些其他的数据结构，如 。
当一个新线程启动的时候，JVM会为Java线程创建每个线程的，如前所言Java的内存栈是由栈帧构成，，在JVM里面，栈帧的操作只有两种：出栈 和入栈 。正在被线程执行的方法一般称为当前线程方法，而该方法的栈帧就称为当前帧，而在该方法内定义的类称为当前类，常量池也称为当前常量池。当执行一个方法如此的时候，JVM保留当前类和当前常量池的 ，当虚拟机遇到了存储在栈帧中的数据上的操作指令的时候，它就执行当前帧的操作。当一个线程调用某个Java方法时，虚拟机创建并且将一个新帧压入到内存堆栈中，而这个压入到内存栈中的帧成为，当该方法执行的时候，JVM使用内存栈来存储参数、局部变量、中间计算结果以及其他相关数据。方法在执行过程有可能因为两种方式而结束：如果一个方法返回完成就属于方法执行的正常结束，如果在这个过程抛出异常而结束，可以称为非正常结束，不论是正常结束还是异常结束，JVM都会弹出或者丢弃该栈帧，则上一帧的方法就成为了当前帧。
在JVM中，Java线程的栈数据是属于某个线程独有的，其他的线程不能够修改或者通过其他方式来访问该线程的栈帧，正因为如此这种情况不用担心多线程同步访问Java的局部变量，当一个线程调用某个方法的时候，方法的局部变量是在方法内部进行的Java栈帧的存储，只有当前线程可以访问该局部变量，而其他线程不能随便访问该内存栈里面存储的数据。内存栈内的栈帧数据和方法区以及内存堆一样，Java栈的栈帧 ，或者说它们可能是在堆，或者两者组合分配，实际数据用于表示Java堆栈和栈帧结构是JVM本身的设计结构决定的，而且在编程过程可以允许程序员指定一个用于Java堆栈的初始大小以及最大、最小尺寸。
内存栈： 这里的有点点区别，是内存里面数据存储的一种。从操作系统上讲，在程序执行过程对内存的使用本身常用的数据结构就是内存堆栈 ，而这里的内存堆栈指代的就是JVM在使用内存过程整个内存的存储结构，内存的物理结构 ，而不是指代的一个物理结构 ，更多的时候指代的是一个抽象结构 ，就是符合JVM语言规范的内存栈的一个抽象结构。因为物理内存堆栈结构和Java内存栈的抽象模型结构本身比较相似，所以我们在学习过程就正常把这两种结构放在一起考虑了，而且二者除了概念上有一点点小的区别，理解成为一种结构对于初学者也未尝不可，所以实际上也可以觉得二者没有太大的本质区别
。但是在学习的时候最好分清楚内存堆栈和Java内存栈的一小点细微的差距，前者是物理概念和本身模型，后者是抽象概念和本身模型的一个共同体。而内存堆栈更多的说法可以理解为一个内存块 ，因为内存块可以通过索引和指针进行数据结构的组合，内存栈就是内存块针对数据结构的一种表示，而内存堆则是内存块的另外一种数据结构的表示 ，这样理解更容易区分 内存栈和 内存堆栈（内存块）
的概念。 栈帧： 栈帧是内存栈里面的最小单位，指的是内存栈里面每一个最小内存存储单元，它针对内存栈仅仅做了两个操作：，一般情况下：所说的堆栈帧 和栈帧 倒是一个概念，所以在理解上记得加以区分
内存堆： 这里的内存堆和内存栈是相对应的，其实内存堆里面的数据也是存储在系统内存堆栈里面的，只是它使用了另外一种方式来进行堆里面内存的管理，而本章题目要讲到的就是Java语言本身的内存堆和内存栈，而这两个概念都是抽象的概念模型，而且是相对的。
。但是在学习的时候最好分清楚内存堆栈和Java内存栈的一小点细微的差距，前者是物理概念和本身模型，后者是抽象概念和本身模型的一个共同体。而内存堆栈更多的说法可以理解为一个内存块 ，因为内存块可以通过索引和指针进行数据结构的组合，内存栈就是内存块针对数据结构的一种表示，而内存堆则是内存块的另外一种数据结构的表示 ，这样理解更容易区分 内存栈和 内存堆栈（内存块）
的概念。 栈帧： 栈帧是内存栈里面的最小单位，指的是内存栈里面每一个最小内存存储单元，它针对内存栈仅仅做了两个操作：，一般情况下：所说的堆栈帧 和栈帧 倒是一个概念，所以在理解上记得加以区分
内存堆： 这里的内存堆和内存栈是相对应的，其实内存堆里面的数据也是存储在系统内存堆栈里面的，只是它使用了另外一种方式来进行堆里面内存的管理，而本章题目要讲到的就是Java语言本身的内存堆和内存栈，而这两个概念都是抽象的概念模型，而且是相对的。
栈帧： 栈帧主要包括三个部分：、和。本地变量和操作数帧的大小取决于需要，这些大小是在编译时就决定的，并且在每个方法的类文件数据中进行分配，帧的数据大小则不一样，它虽然也是在编译时就决定的但是它的大小和本身代码实现有关。当JVM调用一个Java方法的时候，它会检查类的数据来确定在本地变量和操作方法要求的栈大小，它计算该方法所需要的内存大小，然后将这些数据分配好内存空间压入到内存堆栈中。
局部变量是以Java栈帧组合成为的一个以零为基的数组 ，使用局部变量的时候使用的实际上是一个包含了0的一个基于索引的。int类型 、float 、引用 以及返回值 都占据了一个数组中的局部变量的条目，而byte 、short 、char 则在存储到局部变量的时候是先再进行操作的，则long 和double 则是在这样一个数组里面使用了的空间大小，在局部变量里面存储基本数据类型的时候使用的就是这样的结构。举个例子：
runClassMethod(i,l,f,d,Object o,b)
{
}
public int runInstanceMethod(c,d,s,b)
{
}
和局部变量一样，操作帧也是一组有组织的数组的存储结构，但是和局部变量不一样的是这个不是通过访问的，而是直接进行的入栈和出栈 的操作，当操作指令直接压入了操作栈帧过后，从栈帧里面出来的数据会直接在出栈的时候被读取 和使用 。除了以外，操作帧也是可以直接被指令访问到的，JVM里面。处理操作帧的时候Java虚拟机是基于内存栈的而不是基于寄存器的，因为它在操作过程是直接对内存栈进行操作而不是针对寄存器进行操作。而JVM内部的指令也可以来源于其他地方比如紧接着操作符以及操作数的字节码流或者直接从常量池里面进行操作
。 JVM指令其实真正在操作过程的焦点是集中在内存栈栈帧的操作帧上的。JVM指令将操作帧作为一个工作空间，有许多指令都是从操作帧里面出栈读取的，对指令进行操作过后将操作帧的计算结果重新压入内存堆栈内。比如iadd指令将两个整数压入到操作帧里面，然后将两个操作数进行相加，相加的时候从内存栈里面读取两个操作数的值，然后进行运算，最后将运算结果重新存入到内存堆栈里面。举个简单的例子：
iload_0 //将整数类型的局部变量0压入到内存栈里面
iload_1 //将整数类型的局部变量1压入到内存栈里面
iadd //将两个变量出栈读取，然后进行相加操作，将结果重新压入栈中
istore_2 //将最终输出结果放在另外一个局部变量里面
综上所述，就是整个计算过程针对内存的一些操作内容，而整体的结构可以用下图来描述：
：除了局部变量和操作帧以外，Java栈帧还包括了数据帧，用于支持常量池、普通的方法返回以及异常抛出等，这些数据都是存储在Java内存栈帧的数据帧中的。很多JVM的指令集实际上使用的都是常量池里面的一些条目，一些指令，只是把int、long、float、double或者String从常量池里面压入到Java栈帧的操作帧上边，一些指令使用常量池来管理类或者数组的实例化操作、字段的访问控制、或者方法的调用，其他的指令就用来决定常量池条目中记录的某一特定对象是否某一类或者常量池项中指定的接口。常量池会判断类型、字段、方法、类、接口、类字段以及引用是如何在JVM进行符号化描述，而这个过程由JVM本身进行对应的判断。这里就可以理解JVM如何来判断我们通常说的：“原始变量存储在内存栈上，而引用的对象存储在内存堆上边
。”除了常量池判断帧数据符号化描述特性以外，这些数据帧必须在JVM正常执行或者异常执行过程辅助它进行处理操作。如果一个方法是正常结束的，JVM必须恢复栈帧调用方法的数据帧，而且必须设置PC寄存器指向调用方法后边等待的指令完成该调用方法的位置 。如果该方法存在返回值，JVM也必须将这个值压入到操作帧里面以提供给需要这些数据的方法进行调用。不仅仅如此，数据帧也必须提供一个方法调用的，当JVM在方法中抛出异常而的时候，该异常表就用来存放异常信息。
当一个Java应用程序在运行的时候在程序中创建一个对象或者一个数组的时候，JVM会针对该对象和数组分配一个新的内存堆空间。但是在JVM实例内部，只存在，所有的依赖该JVM的Java应用程序都需要共享该堆实例，而Java应用程序本身在运行的时候它自己包含了一个由JVM虚拟机实例分配的 ，而在应用程序启动的时候，任何一个Java应用程序都会得到的堆空间，而且针对每一个Java应用程序，这些运行Java应用程序的堆空间都是相互独立的。这里所提及到的共享堆实例是指JVM在初始化运行的时候整体堆空间
只有一个，这个是Java语言平台直接从操作系统上 能够拿到的整体堆空间，所以的依赖该JVM的程序都可以得到这些
只有一个，这个是Java语言平台直接从操作系统上 能够拿到的整体堆空间，所以的依赖该JVM的程序都可以得到这些