Java虚拟机回忆录

那么今天我就来谈谈我对他的理解。

首先，每当说起JVM大概都会想到Java虚拟机运行时数据区，那么它是怎样划分的呢？话不多说，别跟一个直男程序员谈理论扯理想，最爱看的就是图（图摘自互联网）。

很多人粗略的将它分为堆区和非堆区，由上图可以看出Java虚拟机在执行程序时会把他管理的内存划分为不同的数据区。

堆

首先第一个想到的就是它了，在虚拟机启动时就创建，一坨儿活跃在虚拟机所管理内存中的巨无霸（内存最大），被所有线程共享的内存区域，该区域唯一的目的就是存放对象实例，几乎所有的对象实例以及数组都要在堆上分配，堆是虚拟机收集的主要区域，基本上都采用的是分代收集算法，分为：新生代、老年代，堆大小可通过-Xms、-Xmx控制，如果堆没有内存来完成实例分配且也无法再扩展时，将会OOM。

新生代：新创建的对象在此分配，由于新生代中的对象属于朝生夕死的，其回收算法采用的是复制算法，它由Eden区和两个大小相等的From Survivor区、To Survivor区构成。当Minor GC时，Eden区存活的对象将被移到To Survivor区，而From Survivor区存活的对象根据其年龄决定，当年龄达到阀值（-XX:MaxTenuringThreshold可配，没记错的话默认15岁就老了）则会进入老年代，否则进入To Survivor区，虚拟机会清空Eden区和From Survivor区，最后将To Survivo区与From Survivor区互换角色来保证To Survivo区为空。

这里只说下部分调整年轻代的配置，其它的大家可根据Sun文档选择合适自己的。

1)-XX:NewSize、-XX:MaxNewSize 设置年轻代的大小，建议两个值设为一样大，一般为整个堆大小的1/3或者1/4。

2)-XX:SurvivorRatio 设置Eden和Survivor的比值，默认8:1:1。

3)-XX:+PrintTenuringDistribution 用于显示每次Minor GC时Survivor区中各个年龄段的对象的大小。

4)-XX:InitialTenuringThreshol和-XX:MaxTenuringThreshold用于设置晋升到老年代的对象年龄的最小值和最大值，每扛过一次Minor GC之后，年龄就加1。

5)-Xmn 设置年轻代大小 可代替1) 。整个JVM内存大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，官方推荐配置为整个堆的3/8。

老年代：存放的对象比较稳定，主要存放着那些扛过了好几次Minor GC回收仍然还活着或者特别大（XX：PretenureSizeThreshold 可配）的对象，当老年代的连续空间无法分配给新进入的较大对象时，会触发一次Full GC来腾出更多的空间，Full GC的代价很高，会造成Stop the world，所以要减少Full GC次数。老年代GC采用的是标记-清除或者标记-整理算法（根据收集器选择）。

标记-清除算法：Mark-Sweep顾名思义算法分为标记和清除两个步骤，虚拟机会先标记出所有需要回收的对象，在标记完成后统一回收它们。标记过程大概是：对对象进行可达性分析后，发现木有与GC Roots相连接的引用链，将会第一次被标记并会搞一次筛选活动，活动内容就是看看这个对象有没有必要执行finalize方法，如果没有覆盖这个方法或者已经执行过这个方法，那么虚拟机会认为没有必要去执行。如果虚拟机认为有必要执行这个方法的话，这个对象就会去F-Queue里待着等待一个finalizer线程去执行finalize方法，因为这个方法是脱离死亡的救命草；第二次标记是GC对F-Queue进行小规模标记，如果对象在finalize方法抓住了那根草（与GC Roots引用链上的任何一个对像关联即可），那么它将被移除即将回收的区域，如果没有抓住那根草那么它基本靠别自行车了。标记-清除算法有两个不足点，第一就是它的两个过程效率都不高，另一个就是空间问题，会产生大量不连续的内存碎片，会导致分配较大对象时无法申请到足够的连续空间从而触发一次GC。

复制算法：它的出现就是为了解决标记清除的不足，套路就是将内存划分为两个等量大小的块儿，对象都在其中一块儿上，当这一块儿造完了就将存活的对象复制到另一块儿上，然后将刚刚那块儿一次清理掉，这样就不需要考虑内存碎片问题，动动指针按顺序非配就搞定了，实现简单效率高，但是代价有点大内存直接干了一半，适用于对象存活率低的区域，比如朝生夕死的新生代。

标记-整理算法：复制算法看起来很吊，但是对于对象存活率高的区域就显得力不从心了，而且如果不想浪费一半的空间的话，就需要进行空间分配担保（抵押贷款），所以老年代不能这么搞，进而出现了标记-整理算法，套路跟标记-清除一样，只是不直接清理可回收的对象，而是存活的往一边儿移动，然后根据分界线去干掉另一边儿，可以看出该算法要进行对象的移动，成本相对略高，但好处则是不会产生内存碎片。

方法区

方法区多数人认为的永久代，方法区与堆一样是线程共享的内存区域，类使用要经过加载、连接（验证、准备、解析）和初始化，加载后的类信息就存在方法区特定的数据结构中，主要包括：类的全路径名包括超类(如果这个类是Object则它没有超类)、类的类型、类的访问修饰符、直接接口全限定名的有序列表、运行时常量池(类版本、字段、方法信息、常量、类静态变量、装载器信息) 等等。由于线程都共享方法区，所以方法区的数据必须时线程安全的，如果有2个甚至多个线程同时访问某个类，而这类又没被JVM加载，那么JVM只允许一个线程去加载（双亲委派），其它线程必须等待。方法区的内存不一定是连续的，可以动态扩展大小，可以选择不实现GC，GC的目标主要是常量池的回收和类型的卸载，所以想想就好没多少便宜可捡，因为回收条件比较苛刻，当方法区无法满足内存分配需求时将OOM（String.intern()是个好例子）。

广告时间：

ps:卧槽，好久没写了，感觉比撸代码还难！PM，给我一个需求我还你一个美好的明天，放心，不加班。

上面说完了线程共享区域，接来下逼叨逼叨线程隔离数据区。

程序计数器

程序计数器属于线程私有的，它是当前线程所执行字节码的指示器（执行到那儿了），它是一块较小的内存空间，线程下一步该干撒就是通过字节码解释器改变计数器来执行的，每个线程都有自己的程序计数器，多线程就是轮流切换它来实现，Java方法记录的是虚拟机字节码指令地址，Native方法没有记录，程序计数器在JVM中是唯一一个没有定义OOM的区域。

虚拟机栈

如程序计数器一样，Java虚拟机栈也属于线程私有，所以它的生命周期与线程一样。它属于Java方法执行的内存模型，每个方法执行都会创建一个栈帧，主要存储着方法出口信息、局部变量表、操作数栈、动态链接。当线程请求的栈帧深度大于虚拟机所允许的深度会SOF，若虚拟机栈动态扩展时无法申请到足够的内存会OOM。

方法出口信息：正常方法返回时可能需要在栈帧中保存一些信息，用来帮助恢复它的上层方法的执行状态，如果有返回值，则把它压入调用者栈帧的操作数栈中，调整计数器的值以指向方法调用指令后面的一条指令，若方法异常退出，那么返回地址是通过异常处理器来确定的，栈帧中一般不会保存这部分信息。

局部变量表：所需的内存空间在编译期确定，一旦确定无法更改大小，它存放着编译期的各种基本数据类型、reference类型（可能是对象引用指针，也可能是个句柄）、returnAddress类型（指向某条字节码指令的地址）。

操作数栈：栈帧刚创建时，操作数栈是没有数据的，当执行方法操作时，会存放从局部变量表复制的常量或者变量，包括方法入参和返回值，操作数栈都一个固定的栈深度，入栈按先进后出方式，最大深度由编译期确定，基本类型除了long,double用2个深度，其他都用一个。

动态链接：class的常量池中存在有大量的符号引用，字节码中的方法调用指令就以常量池中指向方法的符号引用为参数，这些符号引用分为两种，一种就是类加载的时候，静态解析的那些final 和static代码块，得到的直接引用，还有一种是运行期间转化的（每个栈帧都包含一个指向运行时常量池中该栈帧所属方法的引用），这种就是动态链接。

本地方法栈

跟虚拟机栈的作用是一个屌样，唯一区别就是虚拟机栈是为字节码服务的，而它是为Native方法服务，与虚拟机栈一样，当线程请求的栈帧深度大于虚拟机所允许的深度会SOF，若虚拟机栈动态扩展时无法申请到足够的内存会OOM。

直接内存

Direct Memory 虽然不属于虚拟机运行数据区，但在被NIO引入后一直频繁使用（比如堆外缓存），可以用Native方法直接分配堆外内存，然后在堆中去引用这块儿区域（DirectByteBuffer就是），如果动态扩展内存时达到物理内存限制会OOM。

内存分配策略以及类加载机制以后再补，先写到这儿吧，未完待续！