JVM内存结构和Java内存模型

最近看到两个比较容易混淆的概念：JVM内存结构和Java内存模型

JVM内存结构
JVM内存结构或者说内存模型指的是Java虚拟机在运行程序的过程中会把内存分为不同的区域，根据Java虚拟机规范(1.8)运行时数据区域包括程序计数器(Program Counter Register)、虚拟机栈(VM Stack)、本地方法栈(Native Method Stack)、Java堆(Heap)、方法区(Method Area)、运行时常量池。

程序计数器是线程私有的，是唯一一块没有OOM的内存区域，主要用于记录各个线程执行的字节码的地址，用来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理和线程恢复等都需要借助于计数器来完成。

虚拟机栈用于描述Java方法执行的内存模型，属于线程私有，生命周期和线程相同。每当发生一次方法调用，就会创建一个栈帧用于存储局部变量表、操作数栈、动态链接和方法出口等信息，每一个方法从调用到执行完成就对应着一个栈帧入栈和出栈的过程。局部变量表用于储存编译期可知的基本类型数据和对象引用，其中double的long类型数据占用两个局部变量空间(Slot)，其他均是一个，局部变量表占用的空间在编译期完成分配，运行期不会改变改变其大小。每一次方法调用产生的栈帧中都有一个指向常量池中该方法的引用，常量池中有大量的符号引用，这些符号引用有部分在类加载过程中解析化阶段被转化为直接引用，有些则是在运行阶段转化为直接引用，前者称为静态链接，或者称为动态链接。方法出口分为正常完成出口和异常完成出口。
注意：当线程请求的栈深度大于虚拟机所允许的最大深度，会抛出StackOverflowError，如果支持动态扩展，扩展时无法申请到足够的内存时会抛出OutOfMemoryError

本地方法栈和Java虚拟机栈类似，不过本地方法栈是为调用Native方法服务的，本地方法栈区域也会抛出StackOverflowError和OutOfMemoryError。

Java堆是存放实例对象和数组的地方，是一块所有线程共享的区域，在虚拟机启动时创建。Java堆是垃圾收集器管理的主要区域，根据分代垃圾算法，Java堆可以分为新声代和老年代，其中新生代又可以细分为Eden区和Survivor区根据Java虚拟机规范，Java堆可以处于物理上不连续的内存空间，只要逻辑连续就可以了，可以通过-Xmx和-Xms来控制堆区的大小，如果堆中无法为对象分配内存并且无法扩展时抛出OutOfMemoryError。

方法区也是各个线程共享的区域，用来存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据，根据Java虚拟机规范，当方法区无法满足内存分配时也会OOM。

运行时常量池时方法区的一部分，Class文件除了有类的版本、字段、方法、接口等描述信息外，还有一项信息时常量池，用于存放编译期生成的各种字面量和符号引用，这部分内容在类加载后进入方法区的运行时常量池中存放。此外该区域也存在OOM。

永久代和方法区有着本质区别，方法区是Java虚拟机规范，后者则是JVM规范的一种实现，准确的来说是HotSpot对JVM规范的实现，而Oracle的JRockit和IBM的J9并不存在永久代(Perm Space)的说法。此外从jdk1.7开始将永久代中的部分数据移到Java heap或者Native memory中，例如字符串常量池和类的静态变量移至堆中，将符号引用移至Native memory中，但是jdk1.7并没有完全去除永久代，而jdk1.8完全移除了永久代，引入了元空间(Meta space)，元空间也是对方法区的一种实现，但是元空间不在虚拟机分配内存，而是使用本地内存，因此理论上元空间的大小仅仅受限于本地内存的大小，我们可以通过-XX:Metaspacesize、-XX:MaxMetaspaceSize对元空间的大小进行调整，前者设置初始空间的大小，后者为最大空间限制，当内存使用达到metaspacesize会触发垃圾收集进行无用的类的卸载，同时GC会对MetaspaceSize的大小进行调整，如果释放了大量的空间会适当降低该值，如果释放少量的空间会在不超过MaxMetaspaceSize大小的基础上适当提高该值。除了上面两个指定大小的选项以外，还有两个与 GC 相关的属性：

• -XX:MinMetaspaceFreeRatio，在GC之后，最小的Metaspace剩余空间容量的百分比，减少为分配空间所导致的垃圾收集；
• -XX:MaxMetaspaceFreeRatio，在GC之后，最大的Metaspace剩余空间容量的百分比，减少为释放空间所导致的垃圾收集。

• 字符串在永久代中，容易出现性能问题和内存溢出；
• 永久代的大小不好确定，太小容易出现OOM，太大浪费内存；
• 永久代为垃圾回收带来复杂度，且永久代垃圾回收效率低下；
• 为了合并HotSpot和JRockit作准备。

Java内存模型
Java内存模型(Java Memory Model)是和多线程相关的一个抽象模型，描述了一组规则或规范，这个规范定义了一个线程对共享变量的写入时对另一个线程是可见的。简而言之，JMM是为了解决多线程环境下可见性问题的一组规范。可见性，即一个线程对共享变量的修改，另一个线程能够立即看到，在多核时代，每个CPU都有自己的缓存，如下图所示，线程1操作CPU01的缓存，线程2操作CPU02的缓存，显然线程1对共享变量的操作对于线程2来说就不具备可见性。

可见性问题和JMM

具体来说JMM通过happens-before的概念来阐述多线程之间的内存可见性，happens-before表达的意思是前一个操作的结果对后续的操作是可见的，是判断多线程之间是否存在竞争和线程安全的依据。happens-before原则包括但不仅限于如下：

• 程序次序规则：一个线程内，按照代码顺序，书写在前面的操作先行发生于书写在后面的操作；
• 锁定规则：一个unLock操作先行发生于后面对同一个锁额lock操作；
• volatile变量规则：对一个变量的写操作先行发生于后面对这个变量的读操作；
• 传递规则：如果操作A先行发生于操作B，而操作B又先行发生于操作C，则可以得出操作A先行发生于操作C；
• 线程启动规则：Thread对象的start()方法先行发生于此线程的每个一个动作；
• 线程中断规则：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生；
• 线程终结规则：线程中所有的操作都先行发生于线程的终止检测，我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值手段检测到线程已经终止执行；
• 对象终结规则：一个对象的初始化完成先行发生于他的finalize()方法的开始。

总结
通过对JVM内存结构的介绍，可以看出JVM内存结构强调的是根据JVM规范，在Java运行的过程中，JVM管理各个数据区域，并且这些数据区域有着各自的职责；而JMM强调的是解决多线程并发条下的可见性问题、有序性问题的一组规范。