JVM规范1.7

一、JVM体系结构

类装载器：Classload，状态class文件；
执行引擎：执行字节码或本地方法；
运行时数据区：方法区、堆区、Java虚拟机栈、本地方法栈、程序计数器；

二、JVM内存区域

2.1 运行时数据区

方法区 

属共享区域，存储已被JVM加载的类信息、常量、静态变量、即时编译后的代码等。《Java虚拟机规范》只规定有方法区概念和作用，并没有规定如何去实现。故在不同的JVM上实现是不同的，Sun公司的HotSpot上把垃圾分代搜集扩展至方法区，或者说使用永久代来实现方法区，即：永久代是HotSpot的概念，方法区是Java虚拟机规范中的定义，是一种规范。 

JDK8中，HotSpot取消了永久代，是不是就没有方法区了？当然不是，方法区是一个规范，规范没变就会一直都在。取代永久代的是元空间，区别：

存储位置：永久代是堆的一部分，和新生代、老年代地址是连续的，而元空间属于本地内存； 
存储内容：元空间存储类的元信息，静态变量和常量池等并入堆中。相当于原永久代的数据被分到堆和元空间中； 

堆区 

属共享区域，主要存放对象实例和数组。在其上进行对象内存的分配需要加锁，这也导致new对象开销比较大。JVM中的堆栈和数据结构中的堆栈是两码事。

Sun HotSpot JVM为了提升对象内存分配的效率，对所创建的线程分配独立的空间TLAB（Thread Local Allocation Buffer）缓冲区。可位于物理上不连续的空间，但逻辑上要连续，大小由JVM运行时动态决定，在TLAB上分配对象不需要加锁，保证效率，因此JVM在给线程的对象分配内存时尽量在TLAB上，但如果对象过大仍需直接使用堆空间分配。 

JVM内存分为：堆内存和非堆内存，非堆内存指的是永久代。

  堆内存分为：年轻代（YoungGen）、老年代（OldGen）；默认比例是1:2;图1 

  年轻代又分为：Eden（生成区）和Survivor（幸存区）；Survivor区由From Space（S0）和To Space（S1）组成；三者默认比例是8:1:1； 

Java虚拟机栈 

属线程私有，生命周期和线程一致。描述Java方法执行的内存模型：每个方法在执行时都会创建一个栈帧（Stack Frame），用来存储存储局部变量表、操作数栈、动态链接、方法出口等信息。每个方法从调用至执行结束，就对应着一个栈帧从虚拟机栈中入栈和出栈的过程。 

本地方法栈 

属线程私有，生命周期和线程一致。调用非Java语言实现的方法，作用域Java虚拟机栈类似，会存放对应的局部变量、返回结果等。 

程序计数器 

属线程私有，生命周期和线程一致，保存当前线程正在执行的方法。如果不是native方法，那么PC寄存器存放的是当前线程正在执行的字节码指令地址。如果是native方法，那PC寄存器保存的值是undefined。 

运行时常量池（Runtime Costant Pool） 

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

直接内存（Direct Memory） 

并不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域。但是这部分内存也经常被使用，而且也可能导致OutOfMemoryError异常出现。Java NIO中有使用，使用native函数直接分配堆外内存，受本机总内存和处理器寻址空间限制。 

2.2 内存溢出

方法区 

OutOfMemoryError：PermGen space。 

-XX:PermSize=64M -XX:MaxPermSize=128M。 

堆区 

OutOfMemoryError：Java heap space，如果堆中没有内存完成对象分配，并且也无法扩展时，抛出该异常。 

初始堆、最大堆、年轻代：-Xms:512M -Xmx:1024M -Xmn:128M，没有提供老年代大小的配置，其实老年代大小等于堆大小减去年轻代大小。 

年轻代中分eden 空间、from 空间、to 空间。设置这部分大小用-XX:SurvivorRatio这个参数，设置eden和from空间的比例关系，该参数公式为：-XX:SurvivorRatio = eden/from = eden/to 

Java虚拟机栈 

StackOverflowError：线程请求的栈深度大于虚拟机所允许的深。 

OutOfMemoryError：如果虚拟机栈可动态扩展，而扩展时无法申请到足够的内存。 

本地方法栈 

同Java虚拟机栈，也有StackOverflowError和OutOfMemoryError异常。 

每个线程可使用内存：-Xss256k。 

程序计数器 

在Java虚拟机规范中唯一一个没有任何OutOfMemoryError情况的区域。 

直接内存 

非虚拟机运行时数据区的部分，at sun.misc.Unsafe.allocateMemory(Native Method)。 

-XX:MaxDirectMemorySize=128M直接内存大小，默认最大堆空间。 

元空间（Java1.8） 

OutOfMemoryError：Metadate space。 

-XX:MetaspaceSize:128M -XX:MaxMetaspaceSize=128M。 

2.3 对象创建

对象创建 

（1）先检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，那必须先执行相应的类加载过程。 

（2）然后为新对象分配内存。对象所需内存大小类加载完之后即可确定，在堆的空闲内存中划分一块区域(‘指针碰撞-内存规整’或‘空闲列表-内存交错’的分配方式)，而Java堆是否规整取决于所采用的的垃圾收集器是否带有压缩整理功能，带压缩的采用分配方法是指针碰撞，使用mark-sweep算法的通常采用空闲列表。 

（3）并发情况下的线程安全问题，有两个方案，一种同步进行分配处理，虚拟机采用CAS配上失败重试机制保证跟新操作原子性；另一种把内存分配的动作按照线程划分在不同的空间中进行，即每个线程在Java堆中预先分配一小块内存，称为本地线程缓冲区（TLAB），只有TLAB用完并分配新的TLAB时才需要同步锁定。虚拟机是否使用TLAB，可以通过-XX：+/-UseTLAB参数来设定。 

（4）内存分配完成后，虚拟机需要将分配到的内存空间初始化为零值（不包括对象头），接下来虚拟机要对对象进行必要的设置，填充对象头，把对象是哪个类的实例，如何能找到类的元数据信息，对象的哈希码，对象的GC分代年龄等信息存入对象头。根据虚拟机当前的运行状态的不同，如是否启用偏向锁等，对象头会有不同的设置方式。 

（5）上面工作完成之后，从虚拟机的角度来看，一个新的对象已经产生了，但从Java程序的视角来看，对象的创建才刚刚开始，init方法还没有执行，所有字段都还为零，init方法执行后一个真正可用的对象才算是创建完毕。 

对象内存布局 

Hotspot虚拟机中，对象在内存中的存储布局可以分为3块区域：对象头（Header）、实例数据（Instance Data）、对象填充（Padding）。 

（1）对象头(Header)：包含两部分，第一部分用于存储对象自身的运行时数据，如：哈希吗（HashCode），GC分代年龄，锁状态标志、线程持有的锁、偏向线程 ID、偏向时间戳等，32 位虚拟机占 32 bit，64 位虚拟机占 64 bit。官方称为 ‘Mark Word’。第二部分是类型指针，即对象指向它的类的元数据指针，虚拟机通过这个指针确定这个对象是哪个类的实例。另外，如果是 Java 数组，对象头中还必须有一块用于记录数组长度的数据，因为普通对象可以通过 Java 对象元数据确定大小，而数组对象不可以。 

（2）实例数据(Instance Data)：程序代码中所定义的各种类型的字段内容(包含父类继承下来的和子类中定义的)。 

（3）对齐填充(Padding)：不是必然需要，主要是占位，保证对象大小是某个字节的整数倍（Hotspot虚拟机自动内存管理系统要求对象起始地址必须是8字节的整数倍，换句话就是对象大小必须是8字节的郑书记倍）。 

对象访问定位 

目前主流的方式有使用句柄和直接指针两种。 

句柄访问：Java 堆中会分配一块内存作为句柄池。reference 存储的是句柄地址。对象移动时只改变句柄中实例数据指针，reference本身不用修改。详情见图。 

直接指针：reference 中直接存储对象地址。好处速度快。详情见图。 

三、JVM垃圾回收

3.1 判定垃圾对象

引用计数算法 

对象中添加一个引用计数器，每当一个地方引用它时，计数器就加1；当引用失效时，计数器就减1；任何时刻计数器都为0的对象就是不可能再被使用的。客观讲，这种算法实现简单，判断效率也高，大部分情况下是一个不错的算法。但是，Java语言中没有选用引用计数算法，主要原因是很难解决对象之间相互循环引用的问题。 

可达性分析法 

主流商用程序语言中，都使用根搜索算法（GC Roots Tracing）。思路很简单，把内存中的每一个对象都看作一个节点，并定义了一些对象作为根节点"GC Roots"。从这些节点的对象开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连时，则说明该对象是不可用的。 

Java语言里，可作为GC Roots的对象包含下面几种： 

● 虚拟机栈（栈中的本地变量表）中引用的对象。 

● 方法区中的类静态属性引用的对象。 

● 方法区中常量引用的对象（JDK7后，移到堆中）。 

● 本地方法栈中JNI（常说的Native方法）引用的对象。 

JDK1.2之后，Java对引用的概念做了一些扩充，将分为如下几种： 

● 强引用，类似＂Object obj = new Object()＂，只要强引用还在，垃圾收集器永远不会回收被引用的对象。 

● 软引用，SoftReference类实现软引用。在系统要发生内存溢出之前，将会把这些对象列进回收范围之中进行二次回收。适合做缓存。 

● 弱引用，WeakReference类实现弱引用。对象只能生存到下一次垃圾收集之前，无论内存是否足够都会回收掉只被弱引用关联的对象。 

● 虚引用，PhantomReference类实现虚引用。也称幽灵引用或者幻影引用，是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不影响其生存时间，也无法通过一个虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是希望能在这个对象被收集器回收时收到一个系统通知。 

很多人认为方法区是没有垃圾收集的，Java虚拟机规范中确实说过可以不要求虚拟机在方法区实现垃圾收集，在方法区进行垃圾收集的“性价比”比较低；在堆中，尤其是新生代中，常规应用进行一次垃圾收集一般可以回收70%-95%的空间，而永久代的垃圾收集效率远低于此。 

永久代的垃圾收集主要是废弃常量和无用的类。判断废弃常量与堆中对象回收类似，如果没有被引用，这时候发生内存回收，必要的话就会被移除常量池；而要判断一个类是否是无用的类条件则比较严苛： 

● 该类所有实例都已被回收，即：Java堆中不存在改对象的实例。 

● 加载该类的ClassLoader已经被回收。 

● 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。 

虚拟机会对满足以上3个条件的类进行回收，但不是一定回收。是否对类进行回收，HoptSpot虚拟机提供了-Xnoclassgc参数进行控制，还可以使用-verbose:class及-XX:+TraceClassLoading/-XX:+TraceClassUnloading查看类的加载和卸载信息。 

3.2 垃圾收集算法

垃圾收集算法的实现涉及大量的程序细节，而且各个平台的虚拟机操作内存的方法又各不相同，因此，只介绍几种算法的思想和发展过程。 

标记-清除算法 

该算法最基础的收集算法，分为“标记”和“清除”两个阶段（Mark-Sweep）：首先标出所有需要回收的对象，在标记完成后统一收掉所有被标记的对象。之所以说是最基本的收集算法，是因为后续的收集算法都是基于这种思路并对其缺点进行改进而得到的。它的主要缺点有两个： 

● 效率问题，标记和清除过程效率都不高。 

● 空间问题，标记清除之后会产生大量不连续的内存碎片，太多可能会导致给较大对象分配内存时无法找到足够的连续内存空间，最后不得不提前触发另一次垃圾收集动作。 

复制算法 

将可用内存按容量划分为大小相等的两块，每次只是用其中的一块。当这一块的内存用完了，将或者的对象复制到另外一块内存上，然后再把已使用过的内存空间一次清理掉，这样就不用考虑内存碎片等复杂情况了，只要移动堆顶指针，按顺序分配内存即可，简单高效。缺点是将内存缩小为原来的一半，太高了些。 

现代商业虚拟机都采用这种收集算法来回收新生代，IBM的专门研究表明，新生代中对象98%都是朝生夕死，所以并不需要按照1：1的比例来划分内存空间，而是将内存空间分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中的一块Survivor。当回收时，将Eden和Survivor中存活的对象一次性拷贝到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。HotSpot虚拟机默认的Eden和Survivor比例是8：1，也就是新生代中可用的空间是整个新生代容量的90%（80%+10%），只有10%会被浪费掉。但是不能每次回收都只有不多于10%的对象存活，当Survivor空间不够用时，需要依赖其他内存（这里指老年代）进行分配担保，对象将直接通过分配担保机制进入老年代。缺点：对象存活率高时，复制效率低。 

标记-整理算法 

复制算法在对象存活率较高时就要执行较多的复制操作，效率会变低，极端情况下所有对象100%都存活，就需要有同等大小的空间进行分配担保。 

根据老年代的特点，有人提出另外一种“标记-整理”算法（Compact），标记过程同“标记-清除”算法一样，但后续步骤不是直接对可回收对 象进行清理，而是让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存。 

分代收集算法 

当前商业虚拟机的垃圾收集都采用“分代收集”（Generational Collection）算法，这并不是什么新的思想，只是根据对象存活周期的不同将内存划分为几块。一般是把Java堆划分为新生代和老年代，这样就可以根据各个年代的特点采用合适的收集算法。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记-清除”或者“标记-整理”算法来进行回收。 

3.3 垃圾收集器

如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。Java虚拟机规范中对垃圾收集器应如何实现并没有任何规定，因此不同厂商、不同版本的虚拟机所提供的垃圾收集器可能会有很大差别，并且一般都会提供参数，供用户根据自己的应用特点和要求组合出各个年代所使用的收集器。这里基于Sun HotSpot虚拟机。。 

Serial收集器（复制算法） 

新生代单线程收集器，标记和清理都是单线程，优点是简单高效。垃圾收集时必须暂停其他线程，直到收集结束。是client模式默认的GC方式，可通过-XX:+UseSerialGC来强制指定。 

● 需要stop the word，停顿时间长。 

● 对单CPU环境而言简单高效，没有线程交互开销。 

Serial Old收集器（标记-整理算法） 

老年代单线程收集器，Serial收集器的老年代版本。 

● 优点实现简单高效，缺点给用户带来停顿。 

ParNew收集器（复制算法） 

新生代收集器，可以认为是Serial收集器的多线程版本，使用多线程进行垃圾收集，多核环境下比Serial有更好表现。是Server模式下首选新生代收集器，其中有一个很重要的和性能无关的原因是，除了Serial收集器外，目前只有它能与CMS收集器配合工作。它默认开启的收集线程数与CPU数量相同，在CPU数量非常多的情况下，可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。 

Parallel Scavenge收集器（复制算法） 

是一个新生代的多线程收集器（并行收集器），它在回收期间不需要暂停其他用户线程，其采用的是Copying算法。它追求高吞吐量，高效利用CPU，主要是为了达到一个可控的吞吐量。Parallel Scavenge收集器是虚拟机运行在Server模式下的默认垃圾收集器。Parallel Scavenge收集器也被称为“吞吐量优先收集器”。 

● 吞吐量 = 运行用户代码时间 /（运行用户代码时间 + 垃圾收集时间）。 

● 适合后台应用等对交互相应要求不高的场景。是server级别默认采用的GC方式。 

Parallel Old收集器（标记-整理算法） 

Parallel Scavenge收集器的老年代版本，并行收集器，吞吐量优先。 

● 使用多线程和标记-整理（Mark-Compact）算法。 

● 注重吞吐量及CPU资源敏感的场景，可以优先考虑Parallel 。 

CMS（Concurrent Mark Sweep）收集器（标记-清除算法） 

是一种以获取最短回收停顿时间为目标的收集器，是一种并发收集器，采用Mark-Sweep算法。高并发、低停顿，追求最短GC回收停顿时间，cpu占用比较高，响应时间快，停顿时间短，多核cpu 追求高响应时间的选择。目前大部分Java应用集中在互联网站或B/S系统的服务端上，这类应用尤其注重响应速度，CMS收集器就非常适合。整个过程分为4个步骤： 

● 初始标记，标记GCRoots能直接关联到的对象，时间很短。 

● 并发标记，进行GCRoots Tracing（可达性分析）过程，时间很长。 

● 重新标记，修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，时间较长。 

● 并发清除，回收内存空间，时间很长。 

但是有3个明显的缺点： 

● 对CPU资源非常敏感。可能会导致应用程序变慢，吞吐率下降。 

● 无法处理浮动垃圾，因为在并发清理阶段用户线程还在运行，自然就会产生新的垃圾，而在此次收集中无法收集他们，只能留到下次收集，这部分垃圾为浮动垃圾，同时，由于用户线程并发执行，所以需要预留一部分老年代空间提供并发收集时程序运行使用。 

● 由于采用的标记 - 清除算法，会产生大量的内存碎片，不利于大对象的分配，可能会提前触发一次Full GC。 

G1（Garbage-First） 

G1收集器是当今收集器技术发展的最前沿成果之一，它是一款面向服务器端应用的收集器，有如下特点：。 

● 并行和并发。G1能充分利用多CPU、多核优势，缩短stop the word时间，可以通过并发方式让Java程序继续执行。 

● 分代收集。G1不需要其他收集器配合可独立管理整个GC堆，但是能够采用不同的方式去处理新创建对象和已经存活了一段时间、熬过多次GC的旧对象，以获取更好的收集效果。 

● 空间整合。G1从整体上看是基于“标记-整理”算法，从局部（两个Region之间）上来看是基于“复制”算法，但无论如何，都不会产生内存空间碎片，收集后可提供规整的可用内存。 

●可预测的停顿 。这是G1相对于CMS的另一大优势，降低停顿时间是G1和CMS共同的关注点，能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。 

使用G1收集器时，Java堆的内存布局就与其他收集器有很大区别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代概念，但是不再是物理隔离，他们都是一部分Region（不需要连续）的集合。 

新生代收集器还是老年代收集器 

● 新生代收集器：Serial、ParNew、Parallel Scavenge； 

● 老年代收集器：Serial Old、Parallel Old、CMS； 

● 整堆收集器：G1； 

吞吐量优先、停顿时间优先 

● 吞吐量优先：Parallel Scavenge收集器、Parallel Old 收集器。 

● 停顿时间优先：CMS（Concurrent Mark-Sweep）收集器。 

串行并行并发 

● 串行：Serial、Serial Old； 

● 并行：ParNew、Parallel Scavenge、Parallel Old； 

● 并发：CMS、G1； 

3.4 垃圾回收过程

四、JVM类加载

概念 

JVM把描述类数据的字节码.class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型。 

五、图例

图1图2