JVM合理理解大总结（一）_耐心阅读

​​1.0 Java虚拟机运行时数据区​​

---

经常有人把Java内存区分为堆内存(Heap)和栈内存(Stack)，这种区分方法比较粗糙，Java内存区域的划分实际上远比这复杂。Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域，主要包括：

• ​虚拟机栈​

• ​本地方法栈​

• ​PC寄存器​

• ​方法区​

• ​堆区​

  ​​​这些数据区域中大致可以划分为2类：线程独享、线程共享。

​线程共享数据区：方法区、堆区。随着虚拟机启动而创建，随着虚拟机退出而销毁，并且为为进程的所有子线程共享 。​

​线程独享数据区：虚拟机栈、本地方法栈、PC寄存器。这些数据区与线程一一对应的，这些与线程对应的数据区域会随着线程开始和结束而创建和销毁。每个线程都有自己私有的虚拟机栈、本地方法栈、PC寄存器。​

​下图显示了两个线程的情况下，JVM中的运行时数据区：​

​​一、线程独享数据区​​

​​PC寄存器​​

​Java 虚拟机可以支持多条线程同时执行，每一条 Java虚拟机线程都有自己的 PC（ Program Counter）寄存器。在任意时刻，一条 Java 虚拟机线程只会执行一个方法的代码，这个正在被线程执行的方法称为该线程的当前方法（ Current Method）。PC寄存器中存储的就是当前方法经过JVM汇编后字节码指令的地址。如果这个方法不是 native 的，那 PC 寄存器就保存 Java 虚拟机正在执行的字节码指令的地址，如果该方法是 native 的，那 PC 寄存器的值是 undefined。​

​​Java虚拟机栈​​

​此栈中的元素叫做栈帧​​​（Stack Frame）​​​，线程在调用java方法时，会为每个方法创建一个栈帧，来存储局部变量表、操作栈、动态链接、方法出口等信息。每个方法被调用和完成的过程，都对应着一个栈帧从虚拟机栈上入栈和出栈的过程。虚拟机栈的生命周期和线程相同。​

​下图展示了栈帧的内部结构：​

​栈帧（ Frame）是用来存储数据和部分过程结果的数据结构，同时也被用来处理动态链接（ Dynamic Linking）、方法返回值和异常分派（ Dispatch Exception）。栈帧随着方法调用而创建，随着方法结束而销毁——无论方法是正常完成还是异常完成（抛出了在方法内未被捕获的异常）都算作方法结束。栈帧的存储空间分配在 Java 虚拟机栈之中，每一个栈帧都有自己的局部变量表（ Local Variables）、操作数栈（OperandStack）和指向当前方法所属的类的运行时常量池的引用。局部变量表和操作数栈的容量是在编译期确定，并通过方法的 Code 属性保存及提供给栈帧使用。因此，栈帧容量的大小仅仅取决于 Java 虚拟机的实现和方法调用时可被分配的内存。在一条线程之中，只有目前正在执行的那个方法的栈帧是活动的。这个栈帧就被称为是当前栈帧（ Current Frame），这个栈帧对应的方法就被称为是当前方法（ Current Method），定义这个方法的类就称作当前类（ Current Class）。对局部变量表和操作数栈的各种操作，通常都指的是对当前栈帧的对局部变量表和操作数栈进行的操作。法返回之后，当前栈帧就随之被丢弃，前一个栈帧就重新成为当前栈帧了。​

​请读者特别注意，栈帧是线程本地私有的数据，不可能在一个栈帧之中引用另外一条线程的栈帧。​

​​本地方法栈​​

​Java 虚拟机实现可能会使用到传统的栈（通常称之为“ C Stacks”）来支持 native 方法（ 指使用 Java 以外的其他语言编写的方法）的执行，这个栈就是本地方法栈（ Native Method Stack）。当 Java 虚拟机使用其他语言（例如 C 语言）来实现指令集解释器时，也会使用到本地方法栈。这个栈一般会在线程创建的时候按线程分配，用来存储线程调用本地方法时，本地方法的局部变量表，操作栈等信息。​

​Java 虚拟机规范允许Java虚拟机栈和本地方法栈被实现成固定大小的或者是根据计算动态扩展和收缩的。​

​本地方法栈和虚拟机栈所发挥的作用是非常相似的，区别是虚拟机栈执行Java方法，而本地方法栈则为虚拟机使用的Native方法服务，在sun hotspot 虚拟机中已经把两者合二为一了，本地方法栈区也会抛出StackOverFlowError和OutOfMemeoryError异常。​

​​堆(Heap)​​

​Java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。 此区域的唯一目的就是存放对象实例，几乎所有对象的实例都在这分配内存。 Java堆是垃圾收集器管理的主要区域，因此很多时候也被称为GC堆。Java 堆在虚拟机启动的时候就被创建，它存储了被自动内存管理系统（ Automatic Storage Management System，也即是常说的“ Garbage Collector（垃圾收集器）”）所管理的各种对象，这些受管理的对象无需，也无法显式地被销毁。 Java 堆的容量可以是固定大小的，也可以随着程序执行的需求动态扩展，并在不需要过多空间时自动收缩。​

​​方法区​​

​在 Java 虚拟机中，方法区（ Method Area） 是可供各条线程共享的运行时内存区域。方法区与传统语言中的编译代码储存区（ Storage Area Of Compiled Code）或者操作系统进程的正文段（ Text Segment）的作用非常类似，它存储了每一个类的结构信息，例如运行时常量池（ Runtime Constant Pool）、字段和方法数据、构造函数和普通方法的字节码内容、还包括一些在类、实例、接口初始化时用到的特殊方法。 方法区在虚拟机启动的时候被创建，虽然方法区是堆的逻辑组成部分，但是简单的虚拟机实现可以选择在这个区域不实现垃圾收集。 方法区的容量可以是固定大小的，也可以随着程序执行的需求动态扩展，并在不需要过多空间时自动收缩。​

​下图展示了方法区的内部结构​

​​1.1 Java代码说明JVM内存布局​​

​通常情况下，我们在研究JVM内存布局的时候，主要研究的就是Java虚拟机栈和堆(Heap)。这也是大多人将Java虚拟机内存粗分为栈内存和堆内存的原因。然后从另外一个角度，HotSpot虚拟机已经将Java虚拟机栈和本地方法栈合并了，和方法区也是堆内存的逻辑组成部分。因此这里我们也粗分为堆内存和栈内存，用具体的Java代码来说明对象在内存中的布局。​

​这张图演示了Java内存模型的逻辑视图。​

​每一个运行在Java虚拟机里的线程都拥有自己的线程栈。这个线程栈包含了这个线程调用的方法当前执行点相关的信息。一个线程仅能访问自己的线程栈。一个线程创建的本地变量对其它线程不可见，仅自己可见。即使两个线程执行同样的代码，这两个线程任然在在自己的线程栈中的代码来创建本地变量。因此，每个线程 拥有每个本地变量的独有版本。​

​所有原始类型(int,long...)的本地变量都存放在线程栈上，因此对其它线程不可见。一个线程可能向另一个线程传递一个原始类型变量的拷贝，但是它不能共享这个原始类型变量自身。​

​堆上包含在Java程序中创建的所有对象，无论是哪一个对象创建的。这包括原始类型的对象版本。如果一个对象被创建然后赋值给一个局部变量，或者用来作为另一个对象的成员变量，这个对象任然是存放在堆上。​

​下面这张图演示了调用栈和本地变量存放在线程栈上，对象存放在堆上。​

• ​一个本地变量可能是原始类型，在这种情况下，它总是“呆在”线程栈上。​

• ​一个本地变量也可能是指向一个对象的一个引用。在这种情况下，引用（这个本地变量）存放在线程栈上，但是对象本身存放在堆上。​

• ​一个对象可能包含方法，这些方法可能包含本地变量。这些本地变量任然存放在线程栈上，即使这些方法所属的对象存放在堆上。​

• ​一个对象的成员变量可能随着这个对象自身存放在堆上。不管这个成员变量是原始类型还是引用类型。​

• ​静态成员变量跟随着类定义一起也存放在堆上。​

• ​存放在堆上的对象可以被所有持有对这个对象引用的线程访问。当一个线程可以访问一个对象时，它也可以访问这个对象的成员变量。如果两个线程同时调用同一个对象上的同一个方法，它们将会都访问这个对象的成员变量，但是每一个线程都拥有这个本地变量的私有拷贝。​

​下图演示了上面提到的点：​

​两个线程拥有一些列的本地变量。其中一个本地变量（Local Variable 2）执行堆上的一个共享对象（Object 3）。这两个线程分别拥有同一个对象的不同引用。这些引用都是本地变量，因此存放在各自线程的线程栈上。这两个不同的引用指向堆上同一个对象。​

​注意，这个共享对象（Object 3）持有Object2和Object4一个引用作为其成员变量（如图中Object3指向Object2和Object4的箭头）。通过在Object3中这些成员变量引用，这两个线程就可以访问Object2和Object4。​

​这张图也展示了指向堆上两个不同对象的一个本地变量。在这种情况下，指向两个不同对象的引用不是同一个对象。理论上，两个线程都可以访问Object1和Object5，如果两个线程都拥有两个对象的引用。但是在上图中，每一个线程仅有一个引用指向两个对象其中之一。​

​因此，什么类型的Java代码会导致上面的内存图呢？如下所示：​

1. ​public class MyRunnable implements Runnable() {​

2. ​    public void run() {​

3. ​        methodOne();​

4. ​    }​

5. ​    public void methodOne() {​

6. ​        int localVariable1 = 45;​

7. ​        MySharedObject localVariable2 =​

8. ​            MySharedObject.sharedInstance;​

9. ​        //... do more with local variables.​

10. ​        methodTwo();​

11. ​    }​

12. ​    public void methodTwo() {​

13. ​        Integer localVariable1 = new Integer(99);​

14. ​        //... do more with local variable.​

15. ​    }​

16. ​}​

17. ​public class MySharedObject {​

18. ​    //static variable pointing to instance of MySharedObject​

19. ​    public static final MySharedObject sharedInstance =​

20. ​        new MySharedObject();​

21. ​    //member variables pointing to two objects on the heap​

22. ​    public Integer object2 = new Integer(22);​

23. ​    public Integer object4 = new Integer(44);​

24. ​    public long member1 = 12345;​

25. ​    public long member1 = 67890;​

26. ​}​

​如果两个线程同时执行run()方法，就会出现上图所示的情景。run()方法调用methodOne()方法，methodOne()调用methodTwo()方法。​

​​methodOne()​​​声明了一个原始类型的本地变量和一个引用类型的本地变量。​

​每个线程执行​​​methodOne()​​​都会在它们对应的线程栈上创建​​​localVariable1​​​和​​​localVariable2​​​的私有拷贝。​​​localVariable1​​​变量彼此完全独立，仅“生活”在每个线程的线程栈上。一个线程看不到另一个线程对它的​​​localVariable1​​​私有拷贝做出的修改。​

​每个线程执行​​​methodOne()​​​时也将会创建它们各自的​​​localVariable2​​​拷贝。然而，两个​​​localVariable2​​​的不同拷贝都指向堆上的同一个对象。代码中通过一个静态变量设置​​​localVariable2​​​指向一个对象引用。仅存在一个静态变量的一份拷贝，这份拷贝存放在堆上。因此，​​​localVariable2​​​的两份拷贝都指向由​​​MySharedObject​​​指向的静态变量的同一个实例。​​​MySharedObject​​​实例也存放在堆上。它对应于上图中的Object3。​

​注意，​​​MySharedObject​​​类也包含两个成员变量。这些成员变量随着这个对象存放在堆上。这两个成员变量指向另外两个​​​Integer​​​对象。这些​​​Integer​​​对象对应于上图中的Object2和Object4.​

​注意，​​​methodTwo()​​​创建一个名为​​​localVariable​​​的本地变量。这个成员变量是一个指向一个​​​Integer​​​对象的对象引用。这个方法设置​​​localVariable1​​​引用指向一个新的​​​Integer​​​实例。在执行​​​methodTwo​​​方法时，​​​localVariable1​​​引用将会在每个线程中存放一份拷贝。这两个​​​Integer​​​对象实例化将会被存储堆上，但是每次执行这个方法时，这个方法都会创建一个新的​​​Integer​​​对象，两个线程执行这个方法将会创建两个不同的​​​Integer​​​实例。​​​methodTwo​​​方法创建的​​​Integer​​​对象对应于上图中的Object1和Object5。​

​还有一点，​​​MySharedObject​​​类中的两个​​​long​​​类型的成员变量是原始类型的。因为，这些变量是成员变量，所以它们任然随着该对象存放在堆上，仅有本地变量存放在线程栈上。​

​​1.2 JVM对象分代内存划分与垃圾回收​​

​前面的内容分析了JVM运行时的内存区域划分，并代码进行了实际的讲解。下面我们对象分代年龄的角度对JVM内存进行划分，这与JVM的垃圾回收息息相关。​

​  我们知道，JVM会动态的帮我们进行内存分配，对象没有引用的时候称为垃圾，垃圾回收机就会进行回收。​

​ 有些对象会频繁的创建于销毁，例如我们在方法里面使用到局部变量，每次调用，方法里的局部变量就要经历创建与销毁的过程。​

​ 而另外一些对象可能会常驻内存，例如静态成员变量，又或者我们在J2EE开发中的Servelt、Filter等。​

​来自IBM的一组统计数据：​

​98％的java对象，在创建之后不久就变成了非活动对象；只有2％的对象，会在长时间一直处于活动状态。​

​如果能对这两种对象区分对象，那么会提高GC的效率。在sun jdk gc中（具体的说，是在jdk1.4之后的版本），提出了不同生命周期的GC策略。​

​ 现在我们从另外一个角度对JVM的运行时内存进行划分：​​​堆(Heap)​​​堆和​​​非堆(Non-heap)内存​​

​ 按照官方的说法：“Java 虚拟机具有一个堆，堆是运行时数据区域，所有类实例和数组的内存均从此处分配。堆是在 Java 虚拟机启动时创建的。”“在JVM中堆之外的内存称为非堆内存(Non-heap memory)”。​

​简单来说堆就是Java代码可及的内存，是留给开发人员使用的；​

​非堆就是JVM留给 自己用的，所以方法区、JVM内部处理或优化所需的内存(如JIT编译后的代码缓存)、每个类结构(如运行时常数池、字段和方法数据)以及方法和构造方法 的代码都在非堆内存中。​

​​一、基于对象分代年龄的内存划分​​

​从对象分代的角度来说，JVM的内存划分大致分为3块：分别是​​​Permanent Generation​​​（简称PermGen、持久代）、​​​New Generation​​​(又叫Young Generation，年轻代)和​​​Tenured Generation​​​（又叫Old Generation，年老代）。其中Permanent Generation位于non-heap区。New和Old是Java应用的Heap区，用来存放类的实例Instance的。我们在这里主要讨论的Heap区如何根据对象分代年龄进行划分。如下图所示:​

​​

​其中New Generation的目标就是尽可能快速的收集掉那些生命周期短的对象；New Generation又分为​​​Eden Space​​​，​​​From Survivor Space​​​和To Survivor Space三块，Eden Space用于存放新创建的对象，From区和To区都是救助空间Survivor Space（图中的S0和S1）；当Eden区满时，JVM执行垃圾回收GC（Garbage Collection），垃圾收集器暂停应用程序，并会将Eden Space还存活的对象复制到当前的From救助空间，一旦当前的From救助空间充满，此区的存活对象将被复制到另外一个To区，当To区也满了的时候，从From区复制过来并且依然存活的对象复制到Old区，从而From和To救助空间互换角色，维持活动的对象将在救助空间不断复制，直到最终转入Old域。需要注意，Survivor的两个区是对称的，没先后关系，所以同一个区中可能同时存在从Eden复制过来对象，和从前一个Survivor复制过来的对象，而且，Survivor区总有一个是空的。同时，根据程序需要，Survivor区是可以配置为多个的(多于两个)，这样可以增加对象在年轻代中的存在时间，减少被放到年老代的可能。每一次垃圾回收后，Eden Space都会被清空。​

​Old区用于存放长寿的对象，在New区中经历了N次垃圾回收后仍然存活的对象，就会被放到Old区中；如那些与业务信息相关的对象，包括Http请求中的Session对象、线程、Socket连接，这类对象跟业务直接挂钩，因此生命周期比较长。​

​​二、基于对象分代年龄的垃圾回收​​

​在以上提到的任何一个空间不够用时，都会促使JVM执行垃圾回收。基于回收类型的不同，我们将垃圾回收划分为：​

​Minor GC(又叫Young GC)：回收New Generation内存空间(Eden、From Survivor、To Survivor);​

​Full GC：回收New Generation和Tenured Generation、PermGen内存空间​

​​1 Minor GC/Young GC触发​​

​当新对象生成，并且在Eden申请空间失败时，就会触发Minor GC，对Eden区域进行GC，清除非存活对象，并且把尚且存活的对象移动到Survivor区，然后整理Survivor的两个区。这种方式的GC是对New区的Eden区进行，不会影响到Old区。因为大部分对象都是从Eden区开始的，同时Eden区不会分配的很大，所以Eden区的Minor GC会频繁进行。因而，一般在这里需要使用速度快、效率高的算法，使Eden去能尽快空闲出来。​

​​2 Full GC触发​​

​Full GC要对整个Heap区进行回收，包括New、Old和PermGen，所以比Minor GC要慢，因此应该尽可能减少Full GC的次数。在对JVM性能调优的过程中，很大一部分工作就是对于Full GC的调节。有如下原因可能导致Full GC：​

​·Tenured区被写满​

​·PermGen区被写满​

​·System.gc()被显示调用​

​·上一次GC之后Heap的各域分配策略动态变化​

​需要注意的是，Full GC与YoungGC是无法完全区分开来的，很多情况下，Full GC是由YoungGC导致的。例如在Eden Space中的对象经历过几次垃圾回收，依然还存活，就会移动到Tenured区，而如果此时Tenured区空间不够，就会出发垃圾回收，过程如下图所示：​

​​

​对于Survivor区域，其实际上就是经历过几次垃圾回收依然没有被回收掉的对象(称之为幸存者)过渡到Tenured区的临时存储空间。​

​2.0 垃圾收集器深入​

​Java与C++之间有一堵由内存动态分配和垃圾收集技术所围成的高墙，墙外面的人想进去，墙里面的人却想出来。​

​GC的历史远远比Java久远，1960年诞生于MIT的Lisp是第一门真正使用内存动态分配和垃圾收集技术的语言。当Lisp还在胚胎时期时，人们就在思考GC需要完成的三件事情：​

1. ​哪些内存需要回收？​

2. ​什么时候回收？​

3. ​如何回收？​

​前面介绍了Java内存运行时区域的各个部分，其中程序计数器、虚拟机栈、本地方法栈三个区域随线程而生，随线程而灭；栈中的栈帧随着方法的进入和退出而有条不紊地执行着出栈和入栈操作。每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的（尽管在运行期会由JIT编译器进行一些优化，但在本章基于概念模型的讨论中，大体上可以认为是编译期可知的），因此这几个区域的内存分配和回收都具备确定性，在这几个区域内不需要过多考虑回收的问题，因为方法结束或线程结束时，内存自然就跟随着回收了。​

​而Java堆和方法区则不一样，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序处于运行期间时才能知道会创建哪些对象，这部分内存的分配和回收都是动态的，垃圾收集器所关注的是这部分内存，本教程后续讨论中的“内存”分配与回收也仅指这一部分内存。  ​

​2.1 对象的内存布局​

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

​​1 对象头​​

​​HotSpot虚拟机的对象头包括两部分信息，第一部分用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持 有的锁、偏向线程ID、偏向时间戳等等，这部分数据的长度在32位和64位的虚拟机（暂不考虑开启压缩指针的场景）中分别为32个和64个Bits，官方 称它为“Mark Word”。对象需要存储的运行时数据很多，其实已经超出了32、64位Bitmap结构所能记录的限度，但是对象头信息是与对象自身定义的数据无关的额 外存储成本，考虑到虚拟机的空间效率，Mark Word被设计成一个非固定的数据结构以便在极小的空间内存储尽量多的信息，它会根据对象的状态复用自己的存储空间。例如在32位的HotSpot虚拟机 中对象未被锁定的状态下，Mark Word的32个Bits空间中的25Bits用于存储对象哈希码（HashCode），4Bits用于存储对象分代年龄，2Bits用于存储锁标志 位，1Bit固定为0，在其他状态（轻量级锁定、重量级锁定、GC标记、可偏向）下对象的存储内容如下表所示。​​

​以下是HotSpot虚拟机markOop.cpp中的代码（注释）片段，它描述了32bits下MarkWord的存储状态：对象头的另外一部分是类型指针，即是对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。并不是所有的虚拟机实现都必须在对象 数据上保留类型指针，换句话说查找对象的元数据信息并不一定要经过对象本身，这点我们在下一节讨论。另外，如果对象是一个Java数组，那在对象头中还必 须有一块用于记录数组长度的数据，因为虚拟机可以通过普通Java对象的元数据信息确定Java对象的大小，但是从数组的元数据中无法确定数组的大小。​

1. ​// Bit-format of an object header (most significant first, big endian layout below):​

2. ​//​

3. ​//  32 bits:​

4. ​//  --------​

5. ​//  hash:25 ------------>| age:4    biased_lock:1 lock:2 (normal object)​

6. ​//  JavaThread*:23 epoch:2 age:4    biased_lock:1 lock:2 (biased object)​

7. ​//  size:32 ------------------------------------------>| (CMS free block)​

8. ​//  PromotedObject*:29 ---------->| promo_bits:3 ----->| (CMS promoted object)​

​接下来实例数据部分是对象真正存储的有效信息，也既是我们在程序代码里面所定义的各种类型的字段内容，无论是从父类继承下来的，还是在子类中定义的都需要 记录袭来。这部分的存储顺序会受到虚拟机分配策略参数（FieldsAllocationStyle）和字段在Java源码中定义顺序的影响。 HotSpot虚拟机默认的分配策略为longs/doubles、ints、shorts/chars、bytes/booleans、 oops（Ordinary Object Pointers），从分配策略中可以看出，相同宽度的字段总是被分配到一起。在满足这个前提条件的情况下，在父类中定义的变量会出现在子类之前。如果 CompactFields参数值为true（默认为true），那子类之中较窄的变量也可能会插入到父类变量的空隙之中。
　　第三部分对齐填充并不是必然存在的，也没有特别的含义，它仅仅起着占位符的作用。由于HotSpot VM的自动内存管理系统要求对象起始地址必须是8字节的整数倍，换句话说就是对象的大小必须是8字节的整数倍。对象头部分正好似8字节的倍数（1倍或者2 倍），因此当对象实例数据部分没有对齐的话，就需要通过对齐填充来补全。 ​

​​2 实例数据（Instance Data）​​

​接下来实例数据部分是对象真正存储的有效信息，也既是我们在程序代码里面所定义的各种类型的字段内容，无论是从父类继承下来的，还是在子类中定义的都需 要记录袭来。这部分的存储顺序会受到虚拟机分配策略参数（FieldsAllocationStyle）和字段在Java源码中定义顺序的影响。 HotSpot虚拟机默认的分配策略为longs/doubles、ints、shorts/chars、bytes/booleans、 oops（Ordinary Object Pointers），从分配策略中可以看出，相同宽度的字段总是被分配到一起。在满足这个前提条件的情况下，在父类中定义的变量会出现在子类之前。如果 CompactFields参数值为true（默认为true），那子类之中较窄的变量也可能会插入到父类变量的空隙之中。​

​3 对齐填充 ​

​第三部分对齐填充并不是必然存在的，也没有特别的含义，它仅仅起着占位符的作用。由于HotSpot VM的自动内存管理系统要求对象起始地址必须是8字节的整数倍，换句话说就是对象的大小必须是8字节的整数倍。对象头部分正好似8字节的倍数（1倍或者2 倍），因此当对象实例数据部分没有对齐的话，就需要通过对齐填充来补全。 ​

​​2.2 判断对象是否已死​​

​​对象已死？​​

​堆中几乎存放着Java世界中所有的对象实例，垃圾收集器在对堆进行回收前，第一件事情就是要确定这些对象有哪些还“存活”着，哪些已经“死去”（即不可能再被任何途径使用的对象）。判断对象是否已死的方法包括。​

​​1、引用计数算法判断​​

​很多教科书判断对象是否存活的算法是这样的：给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器都为0的对象就是不可能再被使用的。笔者面试过很多的应届生和一些有多年工作经验的开发人员，他们对于这个问题给予的都是这个答案。​

​客观地说，引用计数算法（Reference Counting）的实现简单，判定效率也很高，在大部分情况下它都是一个不错的算法，也有一些比较著名的应用案例，例如微软的COM（Component Object Model）技术、使用ActionScript 3的FlashPlayer、Python语言以及在游戏脚本领域中被广泛应用的Squirrel中都使用了引用计数算法进行内存管理。但是，Java语言中没有选用引用计数算法来管理内存，其中最主要的原因是它很难解决对象之间的相互循环引用的问题。​

​​2、根搜索算法​​

​在主流的商用程序语言中（Java和C#，甚至包括前面提到的古老的Lisp），都是使用根搜索算法（GC Roots Tracing）判定对象是否存活的。这个算法的基本思路就是通过一系列的名为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连（用图论的话来说就是从GC Roots到这个对象不可达）时，则证明此对象是不可用的。如下图所示，对象object 5、object 6、object 7虽然互相有关联，但是它们到GC Roots是不可达的，所以它们将会被判定为是可回收的对象。 ​

​​ ​

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

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

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

​方法区中的常量引用的对象。​

​本地方法栈中JNI（即一般说的Native方法）的引用的对象。​

​2.3 垃圾收集算法​

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

​目前常见垃圾回收算法有：​

• ​标记-清除算法​

• ​复制算法​

• ​标记-整理算法​

• ​分代收集算法​

​​标记-清除算法​​

​最基础的收集算法是“标记-清除”（Mark-Sweep）算法，如它的名字一样，算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收掉所有被标记的对象，它的标记过程其实在前一节讲述对象标记判定时已经基本介绍过了。​

​​

​之所以说它是最基础的收集算法，是因为后续的收集算法都是基于这种思路并对其缺点进行改进而得到的。它的主要缺点有两个：​

​一个是效率问题，标记和清除过程的效率都不高；​

​​另外一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致，当程序在以后的运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。​​

​​复制算法​​

​为了解决效率问题，一种称为“复制”（Copying）的收集算法出现了，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对其中的一块进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为原来的一半，未免太高了一点。复制算法的执行过程如图所示。​

​​

​现在的商业虚拟机都采用这种收集算法来回收新生代，IBM的专门研究表明，新生代中的对象98%是朝生夕死的，所以并不需要按照1∶1的比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中的一块Survivor。当回收时，将Eden和Survivor中还存活着的对象一次性地拷贝到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor的空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8∶1，也就是每次新生代中可用内存空间为整个新生代容量的90%（80%+10%），只有10%的内存是会被“浪费”的。当然，98%的对象可回收只是一般场景下的数据，我们没有办法保证每次回收都只有不多于10%的对象存活，当Survivor空间不够用时，需要依赖其他内存（这里指老年代）进行分配担保（Handle Promotion）。​

​内存的分配担保就好比我们去银行借款，如果我们信誉很好，在98%的情况下都能按时偿还，于是银行可能会默认我们下一次也能按时按量地偿还贷款，只需要有一个担保人能保证如果我不能还款时，可以从他的账户扣钱，那银行就认为没有风险了。内存的分配担保也一样，如果另外一块Survivor空间没有足够的空间存放上一次新生代收集下来的存活对象，这些对象将直接通过分配担保机制进入老年代。关于对新生代进行分配担保的内容，本章稍后在讲解垃圾收集器执行规则时还会再详细讲解。​

​​标记-整理算法​​

​复制收集算法在对象存活率较高时就要执行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种算法。​

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

​​

​​分代收集算法​​

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

​2.4 垃圾收集器​

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

​上图展示了7种作用于不同分代的收集器（包括JDK 1.6_Update14后引入的Early Access版G1收集器），如果两个收集器之间存在连线，就说明它们可以搭配使用。虚拟机所处的区域，则表示它是属于新生代收集器还是老年代收集器。​

​在介绍这些收集器各自的特性之前，我们先来明确一个观点：虽然我们是在对各个收集器进行比较，但并非为了挑选一个最好的收集器出来。因为直到现在为止还没有最好的收集器出现，更加没有万能的收集器，所以我们选择的只是对具体应用最合适的收集器。这点不需要多加解释就能证明：如果有一种放之四海皆准、任何场景下都适用的完美收集器存在，那HotSpot虚拟机就没必要实现那么多不同的收集器了。​

​​概念理解​​

​​1 并发和并行​​

​这两个名词都是并发编程中的概念，在谈论垃圾收集器的上下文语境中，它们可以解释如下。​

• ​并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。​

• ​并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），用户程序在继续运行，而垃圾收集程序运行于另一个CPU上。​

​2 Minor GC 和 Full GC​

• ​新生代GC（Minor GC）：指发生在新生代的垃圾收集动作，因为Java对象大多都具备朝生夕灭的特性，所以Minor GC非常频繁，一般回收速度也比较快。​

• ​老年代GC（Major GC / Full GC）：指发生在老年代的GC，出现了Major GC，经常会伴随至少一次的Minor GC（但非绝对的，在Parallel Scavenge收集器的收集策略里就有直接进行Major GC的策略选择过程）。Major GC的速度一般会比Minor GC慢10倍以上。​

​​3 吞吐量​​

​吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量 = 运行用户代码时间 /（运行用户代码时间 + 垃圾收集时间）。​

​虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。​

​​一、Serial收集器​​

​Serial收集器是最基本、历史最悠久的收集器，曾经（在JDK 1.3.1之前）是虚拟机新生代收集的唯一选择。大家看名字就知道，这个收集器是一个单线程的收集器，但它的“单线程”的意义并不仅仅是说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程（Sun将这件事情称之为“Stop The World”），直到它收集结束。“Stop The World”这个名字也许听起来很酷，但这项工作实际上是由虚拟机在后台自动发起和自动完成的，在用户不可见的情况下把用户的正常工作的线程全部停掉，这对很多应用来说都是难以接受的。你想想，要是你的电脑每运行一个小时就会暂停响应5分钟，你会有什么样的心情？图3-6示意了Serial / Serial Old收集器的运行过程。​

​对于“Stop The World”带给用户的恶劣体验，虚拟机的设计者们表示完全理解，但也表示非常委屈：“你妈妈在给你打扫房间的时候，肯定也会让你老老实实地在椅子上或房间外待着，如果她一边打扫，你一边乱扔纸屑，这房间还能打扫完吗？”这确实是一个合情合理的矛盾，虽然垃圾收集这项工作听起来和打扫房间属于一个性质的，但实际上肯定还要比打扫房间复杂得多啊！​

​​二、ParNew收集器​​

​ParNew收集器其实就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数（例如：-XX:SurvivorRatio、 -XX:PretenureSizeThreshold、-XX:HandlePromotionFailure等）、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一样，实现上这两种收集器也共用了相当多的代码。ParNew收集器的工作过程如图所示。​

​​

​ParNew收集器除了多线程收集之外，其他与Serial收集器相比并没有太多创新之处，但它却是许多运行在Server模式下的虚拟机中首选的新生代收集器，其中有一个与性能无关但很重要的原因是，除了Serial收集器外，目前只有它能与CMS收集器配合工作。在JDK 1.5时期，HotSpot推出了一款在强交互应用中几乎可称为有划时代意义的垃圾收集器—CMS收集器（Concurrent Mark Sweep，本节稍后将详细介绍这款收集器），这款收集器是HotSpot虚拟机中第一款真正意义上的并发（Concurrent）收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作，用前面那个例子的话来说，就是做到了在你妈妈打扫房间的时候你还能同时往地上扔纸屑。​

​不幸的是，它作为老年代的收集器，却无法与JDK 1.4.0中已经存在的新生代收集器Parallel Scavenge配合工作，所以在JDK 1.5中使用CMS来收集老年代的时候，新生代只能选择ParNew或Serial收集器中的一个。ParNew收集器也是使用 -XX: +UseConcMarkSweepGC选项后的默认新生代收集器，也可以使用 -XX:+UseParNewGC选项来强制指定它。​

​ParNew收集器在单CPU的环境中绝对不会有比Serial收集器更好的效果，甚至由于存在线程交互的开销，该收集器在通过超线程技术实现的两个CPU的环境中都不能百分之百地保证能超越Serial收集器。当然，随着可以使用的CPU的数量的增加，它对于GC时系统资源的利用还是很有好处的。它默认开启的收集线程数与CPU的数量相同，在CPU非常多（譬如32个，现在CPU动辄就4核加超线程，服务器超过32个逻辑CPU的情况越来越多了）的环境下，可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。​

​​三、Parallel Scavenge收集器​​

​Parallel Scavenge收集器也是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器……看上去和ParNew都一样，那它有什么特别之处呢？​

​Parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughput）。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量 = 运行用户代码时间 /（运行用户代码时间 + 垃圾收集时间），虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。​

​停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户的体验；而高吞吐量则可以最高效率地利用CPU时间，尽快地完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。​

​Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX:MaxGCPauseMillis参数及直接设置吞吐量大小的 -XX:GCTimeRatio参数。​

​MaxGCPauseMillis参数允许的值是一个大于0的毫秒数，收集器将尽力保证内存回收花费的时间不超过设定值。不过大家不要异想天开地认为如果把这个参数的值设置得稍小一点就能使得系统的垃圾收集速度变得更快，GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的：系统把新生代调小一些，收集300MB新生代肯定比收集500MB快吧，这也直接导致垃圾收集发生得更频繁一些，原来10秒收集一次、每次停顿100毫秒，现在变成5秒收集一次、每次停顿70毫秒。停顿时间的确在下降，但吞吐量也降下来了。​

​GCTimeRatio参数的值应当是一个大于0小于100的整数，也就是垃圾收集时间占总时间的比率，相当于是吞吐量的倒数。如果把此参数设置为19，那允许的最大GC时间就占总时间的5%（即1 /（1+19）），默认值为99，就是允许最大1%（即1 /（1+99））的垃圾收集时间。​

​由于与吞吐量关系密切，Parallel Scavenge收集器也经常被称为“吞吐量优先”收集器。除上述两个参数之外，Parallel Scavenge收集器还有一个参数-XX:+UseAdaptiveSizePolicy值得关注。这是一个开关参数，当这个参数打开之后，就不需要手工指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SurvivorRatio）、晋升老年代对象年龄（-XX:PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或最大的吞吐量，这种调节方式称为GC自适应的调节策略（GC Ergonomics）。如果读者对于收集器运作原理不太了解，手工优化存在困难的时候，使用Parallel Scavenge收集器配合自适应调节策略，把内存管理的调优任务交给虚拟机去完成将是一个很不错的选择。只需要把基本的内存数据设置好（如-Xmx设置最大堆），然后使用MaxGCPauseMillis参数（更关注最大停顿时间）或GCTimeRatio参数（更关注吞吐量）给虚拟机设立一个优化目标，那具体细节参数的调节工作就由虚拟机完成了。自适应调节策略也是Parallel Scavenge收集器与ParNew收集器的一个重要区别。​

​​四、Serial Old收集器​​

​Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用“标记-整理”算法。​

​这个收集器的主要意义也是被​​​Client模式​​​下的虚拟机使用。如果在​​​Server模式​​​下，它主要还有两大用途：一个是在JDK 1.5及之前的版本中与Parallel Scavenge收集器搭配使用，另外一个就是作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure的时候使用。​

​这两点都将在后面的内容中详细讲解。Serial Old收集器的工作过程如图所示。​

​​五、Parallel Old收集器​​

​Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记－整理”算法。这个收集器是在JDK 1.6中才开始提供的，在此之前，新生代的Parallel Scavenge收集器一直处于比较尴尬的状态。原因是，如果新生代选择了Parallel Scavenge收集器，老年代除了Serial Old（PS MarkSweep）收集器外别无选择（还记得上面说过Parallel Scavenge收集器无法与CMS收集器配合工作吗？）。由于单线程的老年代Serial Old收集器在服务端应用性能上的“拖累”，即便使用了Parallel Scavenge收集器也未必能在整体应用上获得吞吐量最大化的效果，又因为老年代收集中无法充分利用服务器多CPU的处理能力，在老年代很大而且硬件比较高级的环境中，这种组合的吞吐量甚至还不一定有ParNew加CMS的组合“给力”。​

​直到Parallel Old收集器出现后，“吞吐量优先”收集器终于有了比较名副其实的应用组合，在注重吞吐量及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。Parallel Old收集器的工作过程如图所示。​

​​六、CMS收集器​​

​CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用都集中在互联网站或B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。​

​从名字（包含“Mark Sweep”）上就可以看出CMS收集器是基于“标记-清除”算法实现的，它的运作过程相对于前面几种收集器来说要更复杂一些，整个过程分为4个步骤，包括：​

1. ​初始标记（CMS initial mark）​

2. ​并发标记（CMS concurrent mark）​

3. ​重新标记（CMS remark）​

4. ​并发清除（CMS concurrent sweep）​

​其中初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。​

​由于整个过程中耗时最长的并发标记和并发清除过程中，收集器线程都可以与用户线程一起工作，所以总体上来说，CMS收集器的内存回收过程是与用户线程一起并发地执行的。通过图3-10可以比较清楚地看到CMS收集器的运作步骤中并发和需要停顿的时间。​

​CMS是一款优秀的收集器，它的最主要优点在名字上已经体现出来了：并发收集、低停顿，Sun的一些官方文档里面也称之为并发低停顿收集器（Concurrent Low Pause Collector）。但是CMS还远达不到完美的程度，它有以下三个显著的缺点：​

​CMS收集器对CPU资源非常敏感。其实，面向并发设计的程序都对CPU资源比较敏感。在并发阶段，它虽然不会导致用户线程停顿，但是会因为占用了一部分线程（或者说CPU资源）而导致应用程序变慢，总吞吐量会降低。CMS默认启动的回收线程数是（CPU数量+3）/ 4，也就是当CPU在4个以上时，并发回收时垃圾收集线程最多占用不超过25%的CPU资源。但是当CPU不足4个时（譬如2个），那么CMS对用户程序的影响就可能变得很大，如果CPU负载本来就比较大的时候，还分出一半的运算能力去执行收集器线程，就可能导致用户程序的执行速度忽然降低了50%，这也很让人受不了。为了解决这种情况，虚拟机提供了一种称为“增量式并发收集器”（Incremental Concurrent Mark Sweep / i-CMS）的CMS收集器变种，所做的事情和单CPU年代PC机操作系统使用抢占式来模拟多任务机制的思想一样，就是在并发标记和并发清理的时候让GC线程、用户线程交替运行，尽量减少GC线程的独占资源的时间，这样整个垃圾收集的过程会更长，但对用户程序的影响就会显得少一些，速度下降也就没有那么明显，但是目前版本中，i-CMS已经被声明为“deprecated”，即不再提倡用户使用。​

​CMS收集器无法处理浮动垃圾（Floating Garbage），可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行着，伴随程序的运行自然还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在本次收集中处理掉它们，只好留待下一次GC时再将其清理掉。这一部分垃圾就称为“浮动垃圾”。也是由于在垃圾收集阶段用户线程还需要运行，即还需要预留足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使用。在默认设置下，CMS收集器在老年代使用了68%的空间后就会被激活，这是一个偏保守的设置，如果在应用中老年代增长不是太快，可以适当调高参数-XX:CMSInitiatingOccupancyFraction的值来提高触发百分比，以便降低内存回收次数以获取更好的性能。要是CMS运行期间预留的内存无法满足程序需要，就会出现一次“Concurrent Mode Failure”失败，这时候虚拟机将启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。所以说参数-XX:CMSInitiatingOccupancyFraction设置得太高将会很容易导致大量“Concurrent Mode Failure”失败，性能反而降低。​

​还有最后一个缺点，在本节在开头说过，CMS是一款基于“标记-清除”算法实现的收集器，如果读者对前面这种算法介绍还有印象的话，就可能想到这意味着收集结束时会产生大量空间碎片。空间碎片过多时，将会给大对象分配带来很大的麻烦，往往会出现老年代还有很大的空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次Full GC。为了解决这个问题，CMS收集器提供了一个-XX:+UseCMSCompactAtFullCollection开关参数，用于在“享受”完Full GC服务之后额外免费附送一个碎片整理过程，内存整理的过程是无法并发的。空间碎片问题没有了，但停顿时间不得不变长了。虚拟机设计者们还提供了另外一个参数-XX: CMSFullGCsBeforeCompaction，这个参数用于设置在执行多少次不压缩的Full GC后，跟着来一次带压缩的。​

​​七、G1收集器​​

​G1（Garbage First）收集器是当前收集器技术发展的最前沿成果，在JDK 1.6_Update14中提供了Early Access版本的G1收集器以供试用。在JDK 1.7正式发布的时候，G1收集器称为成熟的商用版本随之发布。这里只对G1收集器进行简单介绍。​

​G1收集器是垃圾收集器理论进一步发展的产物，它与前面的CMS收集器相比有两个显著的改进：一是G1收集器是基于“标记-整理”算法实现的收集器，也就是说它不会产生空间碎片，这对于长时间运行的应用系统来说非常重要。二是它可以非常精确地控制停顿，既能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实时Java（RTSJ）的垃圾收集器的特征了。​

​G1收集器可以实现在基本不牺牲吞吐量的前提下完成低停顿的内存回收，这是由于它能够极力地避免全区域的垃圾收集，之前的收集器进行收集的范围都是整个新生代或老年代，而G1将整个Java堆（包括新生代、老年代）划分为多个大小固定的独立区域（Region），并且跟踪这些区域里面的垃圾堆积程度，在后台维护一个优先列表，每次根据允许的收集时间，优先回收垃圾最多的区域（这就是Garbage First名称的来由）。区域划分及有优先级的区域回收，保证了G1收集器在有限的时间内可以获得最高的收集效率。​

​3.0 JVM启动参数大全及默认值​

​Java启动参数共分为三类；​

​其一是标准参数（-），所有的JVM实现都必须实现这些参数的功能，而且向后兼容；​

​其二是非标准参数（-X），默认jvm实现这些参数的功能，但是并不保证所有jvm实现都满足，且不保证向后兼容；​

​其三是非Stable参数（-XX），此类参数各个jvm实现会有所不同，将来可能会随时取消，需要慎重使用；​

​​一、JVM标准参数(-)​​

​JVM的标准参数都是以"-"开头，通过输入"​​​java -help​​​"或者"​​​java -?​​​"，可以查看JVM标准参数列表。如​

​以下是JVM标准参数的详细介绍(红色标记的参数请着重注意):​

​​-client ​​

​ 设置jvm使用client模式，特点是启动速度比较快，但运行时性能和内存管理效率不高，通常用于客户端应用程序或者PC应用开发和调试。​

​​-server​​

​ 设置jvm使server模式，特点是启动速度比较慢，但运行时性能和内存管理效率很高，适用于生产环境。在具有64位能力的jdk环境下将默认启用该模式，而忽略-client参数。​

​​-agentlib:libname[=options] ​​

​ 用于装载本地lib包；​

​ 其中libname为本地代理库文件名，默认搜索路径为环境变量PATH中的路径，options为传给本地库启动时的参数，多个参数之间用逗号分隔。在Windows平台上jvm搜索本地库名为libname.dll的文件，在linux上jvm搜索本地库名为libname.so的文件，搜索路径环境变量在不同系统上有所不同，比如Solaries上就默认搜索LD_LIBRARY_PATH。​

​ 比如：-agentlib:hprof​

​ 用来获取jvm的运行情况，包括CPU、内存、线程等的运行数据，并可输出到指定文件中；windows中搜索路径为JRE_HOME/bin/hprof.dll。​

​​-agentpath:pathname[=options] ​​

​ 按全路径装载本地库，不再搜索PATH中的路径；其他功能和agentlib相同；更多的信息待续，在后续的JVMTI部分会详述。​

​​-classpath classpath ​​

​​-cp classpath ​​

​ 告知jvm搜索目录名、jar文档名、zip文档名，之间用分号;分隔；使用-classpath后jvm将不再使用CLASSPATH中的类搜索路径，如果-classpath和CLASSPATH都没有设置，则jvm使用当前路径(.)作为类搜索路径。​

​ jvm搜索类的方式和顺序为：Bootstrap，Extension，User。​

​ Bootstrap中的路径是jvm自带的jar或zip文件，jvm首先搜索这些包文件，用System.getProperty("sun.boot.class.path")可得到搜索路径。​

​ Extension是位于JRE_HOME/lib/ext目录下的jar文件，jvm在搜索完Bootstrap后就搜索该目录下的jar文件，用System.getProperty("java.ext.dirs")可得到搜索路径。​

​ User搜索顺序为当前路径.、CLASSPATH、-classpath，jvm最后搜索这些目录，用System.getProperty("java.class.path")可得到搜索路径。​

​​-Dproperty=value​​

​ 设置系统属性名/值对，运行在此jvm之上的应用程序可用System.getProperty("property")得到value的值。​

​ 如果value中有空格，则需要用双引号将该值括起来，如-Dname="space string"。​

​ 该参数通常用于设置系统级全局变量值，如配置文件路径，以便该属性在程序中任何地方都可访问。​

​​-enableassertions[:<package name>"..." | :<class name> ] ​​

​​-ea[:<package name>"..." | :<class name> ] ​​

​ 上述参数就用来设置jvm是否启动断言机制（从JDK 1.4开始支持），缺省时jvm关闭断言机制。​

​ 用-ea 可打开断言机制，不加<packagename>和classname时运行所有包和类中的断言，如果希望只运行某些包或类中的断言，可将包名或类名加到-ea之后。例如要启动包com.wombat.fruitbat中的断言，可用命令java -ea:com.wombat.fruitbat...<Main Class>。​

​-disableassertions[:<package name>"..." | :<class ; ] ​

​-da[:<package name>"..." | :<class name> ]​

​ 用来设置jvm关闭断言处理，packagename和classname的使用方法和-ea相同，jvm默认就是关闭状态。​

​ 该参数一般用于相同package内某些class不需要断言的场景，比如com.wombat.fruitbat需要断言，但是com.wombat.fruitbat.Brickbat该类不需要，则可以如下运行：​

​ java -ea:com.wombat.fruitbat...-da:com.wombat.fruitbat.Brickbat <Main Class>。​

​​-enablesystemassertions ​​

​​-esa ​​

​ 激活系统类的断言。​

​​-disablesystemassertions ​​

​​-dsa ​​

​ 关闭系统类的断言。​

​​-jar ​​

​ 指定以jar包的形式执行一个应用程序。​

​ 要这样执行一个应用程序，必须让jar包的manifest文件中声明初始加载的Main-class，当然那Main-class必须有public static void main(String[] args)方法。​

​​-javaagent:jarpath[=options] ​​

​ 指定jvm启动时装入java语言设备代理。​

​ Jarpath文件中的mainfest文件必须有Agent-Class属性。代理类也必须实现公共的静态public static void premain(String agentArgs, Instrumentation inst)方法（和main方法类似）。当jvm初始化时，将按代理类的说明顺序调用premain方法；具体参见java.lang.instrument软件包的描述。​

​​-verbose ​​

​​-verbose:class ​​

​ 输出jvm载入类的相关信息，当jvm报告说找不到类或者类冲突时可此进行诊断。​

​​-verbose:gc ​​

​ 输出每次GC的相关情况。​

​​-verbose:jni ​​

​ 输出native方法调用的相关情况，一般用于诊断jni调用错误信息。​

​​-version ​​

​ 输出java的版本信息，比如jdk版本、vendor、model。​

​​-version:release ​​

​ 指定class或者jar运行时需要的jdk版本信息；若指定版本未找到，则以能找到的系统默认jdk版本执行；一般情况下，对于jar文件，可以在manifest文件中指定需要的版本信息，而不是在命令行。​

​ release中可以指定单个版本，也可以指定一个列表，中间用空格隔开，且支持复杂组合，比如：​

​ -version:"1.5.0_04 1.5*&1.5.1_02+"​

​ 指定class或者jar需要jdk版本为1.5.0_04或者是1.5系列中比1.5.1_02更高的所有版本。​

​​-showversion ​​

​ 输出java版本信息（与-version相同）之后，继续输出java的标准参数列表及其描述。​

​​-? ​​

​​-help ​​

​ 输出java标准参数列表及其描述。​

​​二、JVM非标准参数(-X)​​

​通过"​​​java -X​​​"可以输出非标准参数列表，如下所示：​

​非标准参数又称为扩展参数，其列表如下：​

​​-Xint​​

​ 设置jvm以解释模式运行，所有的字节码将被直接执行，而不会编译成本地码。​

​​-Xbatch​​

​ 关闭后台代码编译，强制在前台编译，编译完成之后才能进行代码执行；​

​ 默认情况下，jvm在后台进行编译，若没有编译完成，则前台运行代码时以解释模式运行。​

​​-Xbootclasspath:bootclasspath​​

​ 让jvm从指定路径（可以是分号分隔的目录、jar、或者zip）中加载bootclass，用来替换jdk的rt.jar；若非必要，一般不会用到；​

​​-Xbootclasspath/a:path​​

​ 将指定路径的所有文件追加到默认bootstrap路径中；​

​​-Xbootclasspath/p:path​​

​ 让jvm优先于bootstrap默认路径加载指定路径的所有文件；​

​​-Xcheck:jni​​

​ 对JNI函数进行附加check；此时jvm将校验传递给JNI函数参数的合法性，在本地代码中遇到非法数据时，jmv将报一个致命错误而终止；使用该参数后将造成性能下降，请慎用。​

​​-Xfuture​​

​ 让jvm对类文件执行严格的格式检查（默认jvm不进行严格格式检查），以符合类文件格式规范，推荐开发人员使用该参数。​

​​-Xnoclassgc​​

​ 关闭针对class的gc功能；因为其阻止内存回收，所以可能会导致OutOfMemoryError错误，慎用；​

​​-Xincgc​​

​ 开启增量gc（默认为关闭）；这有助于减少长时间GC时应用程序出现的停顿；但由于可能和应用程序并发执行，所以会降低CPU对应用的处理能力。​

​​-Xloggc:file​​

​ 与-verbose:gc功能类似，只是将每次GC事件的相关情况记录到一个文件中，文件的位置最好在本地，以避免网络的潜在问题。​

​ 若与verbose命令同时出现在命令行中，则以-Xloggc为准。​

​​-Xms<size>​​

​ 指定jvm堆的初始大小，默认为物理内存的1/64，最小为1M；可以指定单位，比如k、m，若不指定，则默认为字节。​

​​-Xmx<size>​​

​ 指定jvm堆的最大值，默认为物理内存的1/4或者1G，最小为2M；单位与-Xms一致。​

​​-Xss<size>​​

​ 设置单个线程栈的大小，一般默认为512k。 ​

​​-Xprof​​

​ 输出 cpu 配置文件数据​

​​-Xrs​​

​ 减少jvm对操作系统信号（signals）的使用，该参数从1.3.1开始有效；​

​ 从jdk1.3.0开始，jvm允许程序在关闭之前还可以执行一些代码（比如关闭数据库的连接池），即使jvm被突然终止；​

​ jvm关闭工具通过监控控制台的相关事件而满足以上的功能；更确切的说，通知在关闭工具执行之前，先注册控制台的控制handler，然后对CTRL_C_EVENT, CTRL_CLOSE_EVENT, CTRL_LOGOFF_EVENT, and CTRL_SHUTDOWN_EVENT这几类事件直接返回true。​

​ 但如果jvm以服务的形式在后台运行（比如servlet引擎），他能接收CTRL_LOGOFF_EVENT事件，但此时并不需要初始化关闭程序；为了避免类似冲突的再次出现，从jdk1.3.1开始提供-Xrs参数；当此参数被设置之后，jvm将不接收控制台的控制handler，也就是说他不监控和处理CTRL_C_EVENT, CTRL_CLOSE_EVENT, CTRL_LOGOFF_EVENT, or CTRL_SHUTDOWN_EVENT事件。​

​上面这些参数中，比如-Xmsn、-Xmxn……都是我们性能优化中很重要的参数；​

​-Xprof、-Xloggc:file等都是在没有专业跟踪工具情况下排错的好手；​

​​三、JVM非Stable参数（-XX）​​

​Java 6（update 21oder 21之后）版本， HotSpot JVM 提供给了两个新的参数，在JVM启动后，在命令行中可以输出所有XX参数和值。​

1. ​-XX:+PrintFlagsFinal and -XX:+PrintFlagsInitial​

​读者可以使用以下语句输出所有的参数和默认值​

1. ​java -XX:+PrintFlagsInitial  -XX:+PrintFlagsInitial>>1.txt​

​由于非State参数非常的多，因此这里就不列出所有参数进行讲解。只介绍我们比较常用的。​

​Java HotSpot VM中-XX:的可配置参数列表进行描述；​

​这些参数可以被松散的聚合成三类：​

​行为参数（Behavioral Options）：用于改变jvm的一些基础行为；​

​性能调优（Performance Tuning）：用于jvm的性能调优；​

​调试参数（Debugging Options）：一般用于打开跟踪、打印、输出等jvm参数，用于显示jvm更加详细的信息；​

​​行为参数(功能开关)​​

​-XX:-DisableExplicitGC 禁止调用System.gc()；但jvm的gc仍然有效​

​-XX:+MaxFDLimit 最大化文件描述符的数量限制​

​-XX:+ScavengeBeforeFullGC 新生代GC优先于Full GC执行​

​-XX:+UseGCOverheadLimit 在抛出OOM之前限制jvm耗费在GC上的时间比例​

​-XX:-UseConcMarkSweepGC 对老生代采用并发标记交换算法进行GC​

​-XX:-UseParallelGC 启用并行GC​

​-XX:-UseParallelOldGC 对Full GC启用并行，当-XX:-UseParallelGC启用时该项自动启用​

​-XX:-UseSerialGC 启用串行GC​

​-XX:+UseThreadPriorities 启用本地线程优先级​

​​性能调优​​

​-XX:LargePageSizeInBytes=4m 设置用于Java堆的大页面尺寸​

​-XX:MaxHeapFreeRatio=70 GC后java堆中空闲量占的最大比例​

​-XX:MaxNewSize=size 新生成对象能占用内存的最大值​

​-XX:MaxPermSize=64m 老生代对象能占用内存的最大值​

​-XX:MinHeapFreeRatio=40 GC后java堆中空闲量占的最小比例​

​-XX:NewRatio=2 新生代内存容量与老生代内存容量的比例​

​-XX:NewSize=2.125m 新生代对象生成时占用内存的默认值​

​-XX:ReservedCodeCacheSize=32m 保留代码占用的内存容量​

​-XX:ThreadStackSize=512 设置线程栈大小，若为0则使用系统默认值​

​-XX:+UseLargePages 使用大页面内存​

​​调试参数​​

​-XX:-CITime 打印消耗在JIT编译的时间​

​-XX:ErrorFile=./hs_err_pid<pid>.log 保存错误日志或者数据到文件中​

​-XX:-ExtendedDTraceProbes 开启solaris特有的dtrace探针​

​-XX:HeapDumpPath=./java_pid<pid>.hprof 指定导出堆信息时的路径或文件名​

​-XX:-HeapDumpOnOutOfMemoryError 当首次遭遇OOM时导出此时堆中相关信息​

​-XX:OnError="<cmd args>;<cmd args>" 出现致命ERROR之后运行自定义命令​

​-XX:OnOutOfMemoryError="<cmd args>;<cmd args>" 当首次遭遇OOM时执行自定义命令​

​-XX:-PrintClassHistogram 遇到Ctrl-Break后打印类实例的柱状信息，与jmap -histo功能相同​

​-XX:-PrintConcurrentLocks 遇到Ctrl-Break后打印并发锁的相关信息，与jstack -l功能相同​

​-XX:-PrintCommandLineFlags 打印在命令行中出现过的标记​

​-XX:-PrintCompilation 当一个方法被编译时打印相关信息​

​-XX:-PrintGC 每次GC时打印相关信息​

​-XX:-PrintGC Details 每次GC时打印详细信息​

​-XX:-PrintGCTimeStamps 打印每次GC的时间戳​

​-XX:-TraceClassLoading 跟踪类的加载信息​

​-XX:-TraceClassLoadingPreorder 跟踪被引用到的所有类的加载信息​

​-XX:-TraceClassResolution 跟踪常量池​

​-XX:-TraceClassUnloading 跟踪类的卸载信息​

​-XX:-TraceLoaderConstraints 跟踪类加载器约束的相关信息​

​​4.0 Java自带的性能监测工具​​

​JDK内置工具使用​

​一、javah命令(C Header and Stub File Generator)​

​二、jps命令(Java Virtual Machine Process Status Tool)​

​三、jstack命令(Java Stack Trace)​

​四、jstat命令(Java Virtual Machine Statistics Monitoring Tool)​

​五、jmap命令(Java Memory Map)​

​六、jinfo命令(Java Configuration Info)​

​七、jconsole命令(Java Monitoring and Management Console)​

​八、jvisualvm命令(Java Virtual Machine Monitoring, Troubleshooting, and Profiling Tool)​

​九、jhat命令(Java Heap Analyse Tool)​

​十、Jdb命令(The Java Debugger)​