JVM工作原理及调优总结

JVM 分为堆区（heap）和栈区(stack)，还有方法区，初始化的对象放在堆里面，引用放在栈里面，class类信息常量池（static常量和static变量）等放在方法区。

 

• 方法区(Method Area)：用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码（字节码）等数据。相对而言，垃圾收集行为在这个区域比较少出现，但并非数据进入了方法区就永久的存在。虽然Java 虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做Non-Heap（非堆），目的应该是与Java 堆区分开来。这区域的内存回收目标主要是针对常量池的回收和堆类型的卸载，一般来说，这个区域的回收情况比较难以令人满意，尤其是类型的卸载，条件相当苛刻，但是这部分区域的回收确实是有必要的。当方法区无法满足内存需求时，将抛出OutOfMemoryError异常。运行时常量池（Runtime Constant Pool）是方法区的一部分。Class 文件中除了有类的版本、字段、方法、接口等描述等信息外，还有一项信息是常量池（Constant Pool Table），用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。运行时常量池相对于Class 文件常量池的另外一个重要特征是具备动态性，Java 语言并不要求常量一定只能在编译期产生，也就是并非预置入Class 文件中常量池的内容才能进入方法区运行时常量池，运行期间也可能将新的常量放入池中，这种特性被开发人员利用得比较多的便是String 类的intern() 方法。既然运行时常量池是方法区的一部分，自然会受到方法区内存的限制，当常量池无法再申请到内存时会抛出OutOfMemoryError 异常。
• Java堆(Java Heap)：被所有线程共享的一块区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例和数组都在这里分配内存，这一点在Java 虚拟机规范中的描述是：所有的对象实例以及数组都要在堆上分配，但是随着JIT 编译器的发展与逃逸分析技术的逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化发生，所有的对象都分配在堆上也渐渐变得不是那么“绝对”了；Java堆是垃圾收集器管理的主要区域，因此很多时候也被称作“GC堆”(Garbage Collected Heap)。从内存回收的角度来看，由于现在收集器基本都是采用分代收集算法，所以Java堆中还可以细分为：新生代和老年代；再细致一点有：Eden空间，From Survivor空间，To Survivor空间等。从内存分配的角度来看，线程共享的Java堆中可能划分出多个线程私有的分配缓冲区(Thread Local Allocation Buffer,TLAB)。不过无论如何划分，都与存放内容无关，无论哪个区域，存储的都是对象的实例，进一步划分的目的是为了更好地回收内存，或更快地分配内存。Java堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可，就像我们的磁盘一样。在实现时，既可以实现成固定大小的，也可以是可扩展的。如果堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError异常。
• 虚拟机栈(Virtual Machine Stacks)：线程私有，生命周期与线程相同。栈的结构是栈帧组成的， 栈帧(Stack Frame)是用于支持虚拟机进行方法调用和方法执行的数据结构。虚拟机栈描述的是Java方法执行的内存模型：每个方法在执行的同时都会创建一个栈帧(Stack Frame)用于存储局部变量表Local Variables（是一组用于存放方法参数和方法内部定义的局部变量变量值的存储空间）、操作数栈（Operand Stack）、动态链接、方法出口等信息。它主要用于存放对象引用。调用一个方法就压入一帧，每一个方法从调用直至执行完成的过程，都对应着一个栈帧在虚拟机栈中入栈到出栈的过程。 在Java虚拟机规范中，对这个区域规定了两种异常的情况：1、如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常；2、如果虚拟机栈可以动态扩展，如果扩展时无法申请到足够的内存，就会抛出OutOfMemoryError异常。

• 本地方法栈(Native Method Stack)：主要为虚拟机使用到的Native方法服务。与虚拟机栈所发挥的作用是非常相似的，他们之间的区别不过是虚拟机栈为虚拟机执行Java方法(也即是字节码)服务。有的虚拟机(如HotSpot)直接把本地方法栈和虚拟机栈合二为一。与虚拟机栈一样，本地方法栈区域也会抛出StackOverflowError和OutOfMemoryError异常。
• 程序计数器(Program Counter Register)：是一块较小的内存空间，它可以看作是当前线程所执行的字节码的行号指示器。在虚拟机的概念模型里，字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。由于Java虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的，在任何一个确定的时刻，一个处理器都只会执行一条线程中的指令。因此，为了线程切换后能恢复到正确的位置，每条线程都需要有一个独立的程序计数器，各条线程之间计数器互不影响，独立存储，称这类内存区域为”线程私有“的内存。如果内存正在执行一个Java方法，这个计数器记录的是正在执行的虚拟机字节码指令地址；如果正在执行的是Native方法。这个计数器值则为空(undefined)。此内存区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。

为什么要分代

分代的垃圾回收策略，是基于这样一个事实：不同的对象的生命周期是不一样的。因此，不同生命周期的对象可以采取不同的收集方式，以便提高回收效率。将对象根据存活概率进行分类，对存活时间长的对象，放到固定区，从而减少扫描垃圾时间及GC频率。针对分类进行不同的垃圾回收算法，对算法扬长避短。

在Java程序运行的过程中，会产生大量的对象，其中有些对象是与业务信息相关，比如Http请求中的Session对象、线程、Socket连接，这类对象跟业务直接挂钩，因此生命周期比较长。但是还有一些对象，主要是程序运行过程中生成的临时变量，这些对象生命周期会比较短，比如：String对象，由于其不变类的特性，系统会产生大量的这些对象，有些对象甚至只用一次即可回收。

试想，在不进行对象存活时间区分的情况下，每次垃圾回收都是对整个堆空间进行回收，花费时间相对会长，同时，因为每次回收都需要遍历所有存活对象，但实际上，对于生命周期长的对象而言，这种遍历是没有效果的，因为可能进行了很多次遍历，但是他们依旧存在。因此，分代垃圾回收采用分治的思想，进行代的划分，把不同生命周期的对象放在不同代上，不同代上采用最适合它的垃圾回收方式进行回收。

如何分代

Java堆是被所有线程共享的一块内存区域，所有对象和数组都在堆上进行内存分配。为了进行高效的垃圾回收，虚拟机把堆内存划分成新生代（Young Generation）、老年代（Old Generation）和永久代（Permanent Generation，注：1.8中无永久代，使用metaspace实现）三块区域。其中持久代主要存放的是Java类的类信息，与垃圾收集要收集的Java对象关系不大。年轻代和年老代的划分是对垃圾收集影响比较大的。如下图所示：

 

年轻代（Young Generation）：

所有新生成的对象首先都是放在年轻代的。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。分为Eden和Survivor区。Survivor区由FromSpace和ToSpace组成。Eden区占大容量，Survivor两个区占小容量，默认比例是8:1:1。大部分对象在Eden区中生成。内存回收时，如果用的是复制算法，当Eden区满时，还存活的对象将被复制到Survivor区（两个中的一个），当这个Survivor区满时，此区的存活对象将被复制到另外一个Survivor区，当经过一次或者多次GC之后，这个Survivor去也满了的时候，从第一个Survivor区复制过来的并且此时还存活的对象，将被复制“年老区(Tenured)”，当JVM内存不够用的时候，会触发Full GC，清理JVM老年区。当新生区满了之后会触发YGC,先把存活的对象放到其中一个Survice区，然后进行垃圾清理。因为如果仅仅清理需要删除的对象，这样会导致内存碎片，因此一般会把Eden 进行完全的清理，然后整理内存。那么下次GC 的时候，就会使用下一个Survive，这样循环使用。需要注意，Survivor的两个区是对称的，没先后关系，所以同一个区中可能同时存在从Eden复制过来 对象，和从前一个Survivor复制过来的对象，而复制到年老区的只有从第一个Survivor去过来的对象。而且，Survivor区总有一个是空的。同时，根据程序需要，Survivor区是可以配置为多个的（多于两个），这样可以增加对象在年轻代中的存在时间，减少被放到年老代的可能。

为什么survivor分为两块相等大小的幸存空间？

主要为了解决碎片化。如果内存碎片化严重，也就是两个对象占用不连续的内存，已有的连续内存不够新对象存放，就会触发GC。

年老代（Old Generation）：

在年轻代中经历了N次垃圾回收后仍然存活的对象，就会被放到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。如果有特别大的对象，新生代放不下，就会使用老年代的担保，直接放到老年代里面。因为JVM 认为，一般大对象的存活时间一般比较久远。

永久代（Permanent Generation）：

在HotSpot中也称为方法区，存储程序运行时长期存活的对象，比如类的元数据、方法、常量、属性等，持久代对垃圾回收没有显著影响，但是有些应用可能动态生成或者调用一些class，例如Hibernate等，在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。持久代大小通过-XX:MaxPermSize=<N>进行设置。

在JDK1.8版本废弃了永久代(为融合HotSpot JVM与JRockit VM（新JVM技术）而做出的改变，因为JRockit没有永久代。
有了元空间就不再会出现永久代OOM问题了)，替代的是元空间（MetaSpace），元空间与永久代上类似，都是方法区的实现，他们最大区别是：元空间并不在JVM中，而是使用本地内存。
元空间有注意有两个参数：

• MetaspaceSize ：初始化元空间大小，控制发生GC阈值
• MaxMetaspaceSize ： 限制元空间大小上限，防止异常占用过多物理内存

JVM堆内存常用参数

参数	描述
-Xms	堆内存初始大小，单位m、g
-Xmx（MaxHeapSize）	堆内存最大允许大小，一般不要大于物理内存的80%
-XX:PermSize	非堆内存初始大小，一般应用设置初始化200m，最大1024m就够了
-XX:MaxPermSize	非堆内存最大允许大小
-XX:NewSize（-Xns）	年轻代内存初始大小
-XX:MaxNewSize（-Xmn）	年轻代内存最大允许大小，也可以缩写
-XX:SurvivorRatio=8	年轻代中Eden区与Survivor区的容量比例值，默认为8，即8:1
-Xss	堆栈内存大小

分代概念

新生成的对象首先放到年轻代Eden区，当Eden空间满了，触发Minor GC，存活下来的对象移动到Survivor0区，Survivor0区满后触发执行Minor GC，Survivor0区存活对象移动到Suvivor1区，这样保证了一段时间内总有一个survivor区为空。经过多次Minor GC仍然存活的对象移动到老年代。
老年代存储长期存活的对象，占满时会触发Major GC=Full GC，GC期间会停止所有线程等待GC完成，所以对响应要求高的应用尽量减少发生Major GC，避免响应超时。
Minor GC ： 清理年轻代 
Major GC ： 清理老年代
Full GC ： 清理整个堆空间，包括年轻代和永久代
所有GC都会停止应用所有线程。

什么情况下触发垃圾回收

由于对象进行了分代处理，因此垃圾回收区域、时间也不一样。GC有两种类型：Scavenge GC和Full GC。Serial收集器（串行收集器）、Parallel 收集器（并行收集器）、CMS收集器（并发收集器）、G1收集器。

1.新生代收集器
Serial：是新生代的一个单线程的GC，，进行GC时，停掉所有用户线程，直至回收结束，“stop-the-world”。但是其单线程的简单高效，没有线程交互的开销，常被JVM运行在client模式下的默认新生代收集器。

ParNew：并行收集器，是serial收集器的多线程的版本。是运行在server模式下的首先的新生代的收集器。

Parallel Scavenge ：新生代收集器，多线程，并行收集。 此收集器与之前的收集器目的不同：（特点）达到一个可控制的吞吐量。吞吐量=运行用户代码时间/CPU总执行时间。 用于精确吞吐量的两个参数：1.控制最大垃圾收集停顿时间参数 2.直接设置吞吐量大小的参数。Parallel scavenge收集器与ParNew收集器重要区别是： 垃圾自适应调节策略。
 

2.老年代收集器
Serial Old：老年代收集器版本，单线程。 在JDK1.5版本之前与parallel scavenge 收集器搭配使用。作为CMS收集器的后备预案。

Parallel Old ：使用多线程收集。吞吐量优先。

CMS： 
1.目标是：尽量缩短垃圾回收时间和用户线程的停顿时间 
2.严格意义上第一款并发垃圾回收器 
3.主要场景在 互联网 B/S 架构上 
4.使用标记清除算法 
5.步骤 
5.1 初始标记：STW、快；GC Root 能直接关联的对象 
5.2 并发标记：并发；GC Root Tracing 的过程 
5.3 重新标记：STW、快；修复并发标记阶段 用户线程运行时变动的对象 
5.4 并发清除：并发 
6.因为整个过程中耗时最长的 “并发标记”和“并发清除”是和用户线程并发执行的，所以可认为CMS回收器是和用户线程并发执行的
 

Scavenge GC

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

Full GC

对整个堆进行整理，包括Young、Tenured和Perm。Full GC因为需要对整个对进行回收，所以比Scavenge GC要慢，因此应该尽可能减少Full GC的次数。在对JVM调优的过程中，很大一部分工作就是对于FullGC的调节。有如下原因可能导致Full GC：

1. 年老代（Tenured）被写满
2. 持久代（Perm）被写满
3. System.gc()被显示调用
4. 上一次GC之后Heap的各域分配策略动态变化

选择合适的垃圾收集算法

• 串行收集器（Serial）:比较老的收集器，单线程。收集时，必须暂停应用的工作线程，直到收集结束。

◆  适用情况：数据量比较小（100M左右）；单处理器下并且对响应时间无要求的应用。

◆   缺点：只能用于小型应用。

• 并行收集器（Parallel）:多条垃圾收集线程并行工作，在多核CPU下效率更高，应用线程仍然处于等待状态。

对年轻代进行并行垃圾回收，因此可以减少垃圾回收时间。一般在多线程多处理器机器上使用。使用-XX:+UseParallelGC.打开。并行收集器在J2SE5.0第六6更新上引入，在Java SE6.0中进行了增强--可以对年老代进行并行收集。如果年老代不使用并发收集的话，默认是使用单线程进行垃圾回收，因此会制约扩展能力。使用-XX:+UseParallelOldGC打开。

使用-XX:ParallelGCThreads=<N>设置并行垃圾回收的线程数。此值可以设置与机器处理器数量相等。

此收集器可以进行如下配置：

• 最大垃圾回收暂停：指定垃圾回收时的最长暂停时间，通过-XX:MaxGCPauseMillis=<N>指定。<N>为毫秒.如果指定了此值的话，堆大小和垃圾回收相关参数会进行调整以达到指定值。设定此值可能会减少应用的吞吐量。
• 吞吐量：吞吐量为垃圾回收时间与非垃圾回收时间的比值，通过-XX:GCTimeRatio=<N>来设定，公式为1/（1+N）。例如，-XX:GCTimeRatio=19时，表示5%的时间用于垃圾回收。默认情况为99，即1%的时间用于垃圾回收。

◆ 适用情况：“对吞吐量有高要求”，多CPU、对应用响应时间无要求的中、大型应用。举例：后台处理、科学计算。 
◆ 缺点：垃圾收集过程中应用响应时间可能加长。

• 并发CMS收集器（Concurrent Mark Sweep）:CMS收集器是缩短暂停应用时间为目标而设计的，是基于标记-清除算法实现，整个过程分为4个步骤，包括：
  • 初始标记（Initial Mark）
  • 并发标记（Concurrent Mark）
  • 重新标记（Remark）
  • 并发清除（Concurrent Sweep）;

其中，初始标记、重新标记这两个步骤仍然需要暂停应用线程。初始标记只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段是标记可回收对象，而重新标记阶段则是为了修正并发标记期间因用户程序继续运作导致标记产生变动的那一部分对象的标记记录，这个阶段暂停时间比初始标记阶段稍长一点，但远比并发标记时间段。由于整个过程中消耗最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，CMS收集器内存回收与用户一起并发执行的，大大减少了暂停时间。

可以保证大部分工作都并发进行（应用不停止），垃圾回收只暂停很少的时间，此收集器适合对响应时间要求比较高的中、大规模应用。使用-XX:+UseConcMarkSweepGC打开。

并发收集器主要减少年老代的暂停时间，他在应用不停止的情况下使用独立的垃圾回收线程，跟踪可达对象。在每个年老代垃圾回收周期中，在收集初期并发收集器 会对整个应用进行简短的暂停，在收集中还会再暂停一次。第二次暂停会比第一次稍长，在此过程中多个线程同时进行垃圾回收工作。

并发收集器使用处理器换来短暂的停顿时间。在一个N个处理器的系统上，并发收集部分使用K/N个可用处理器进行回收，一般情况下1<=K<=N/4。

在只有一个处理器的主机上使用并发收集器，设置为incremental mode模式也可获得较短的停顿时间。

浮动垃圾：由于在应用运行的同时进行垃圾回收，所以有些垃圾可能在垃圾回收进行完成时产生，这样就造成了“Floating Garbage”，这些垃圾需要在下次垃圾回收周期时才能回收掉。所以，并发收集器一般需要20%的预留空间用于这些浮动垃圾。

Concurrent Mode Failure：并发收集器在应用运行时进行收集，所以需要保证堆在垃圾回收的这段时间有足够的空间供程序使用，否则，垃圾回收还未完成，堆空间先满了。这种情况下将会发生“并发模式失败”，此时整个应用将会暂停，进行垃圾回收。

启动并发收集器：因为并发收集在应用运行时进行收集，所以必须保证收集完成之前有足够的内存空间供程序使用，否则会出现“Concurrent Mode Failure”。通过设置-XX:CMSInitiatingOccupancyFraction=<N>指定还有多少剩余堆时开始执行并发收集。

 ◆ 适用情况：“对响应时间有高要求”，多CPU、对应用响应时间有较高要求的中、大型应用。举例：Web服务器/应用服务器、电信交换、集成开发环境。

G1收集器（Garbage First）
G1收集器将堆内存划分多个大小相等的独立区域（Region），并且能预测暂停时间，能预测原因它能避免对整个堆进行全区收集。G1跟踪各个Region里的垃圾堆积价值大小（所获得空间大小以及回收所需时间），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region，从而保证了再有限时间内获得更高的收集效率。
G1收集器工作工程分为4个步骤，包括：

• 初始标记（Initial Mark）
• 并发标记（Concurrent Mark）
• 最终标记（Final Mark）
• 筛选回收（Live Data Counting and Evacuation）

初始标记与CMS一样，标记一下GC Roots能直接关联到的对象。并发标记从GC Root开始标记存活对象，这个阶段耗时比较长，但也可以与应用线程并发执行。而最终标记也是为了修正在并发标记期间因用户程序继续运作而导致标记产生变化的那一部分标记记录。最后在筛选回收阶段对各个Region回收价值和成本进行排序，根据用户所期望的GC暂停时间来执行回收。

垃圾收集器参数

参数	描述
-XX:+UseSerialGC	串行收集器
-XX:+UseParallelGC	并行收集器
-XX:+UseParallelGCThreads=8	并行收集器线程数，同时有多少个线程进行垃圾回收，一般与CPU数量相等
-XX:+UseParallelOldGC	指定老年代为并行收集
-XX:+UseConcMarkSweepGC	CMS收集器（并发收集器）
-XX:+UseCMSCompactAtFullCollection	开启内存空间压缩和整理，防止过多内存碎片
-XX:CMSFullGCsBeforeCompaction=0	表示多少次Full GC后开始压缩和整理，0表示每次Full GC后立即执行压缩和整理
-XX:CMSInitiatingOccupancyFraction=80%	表示老年代内存空间使用80%时开始执行CMS收集，防止过多的Full GC
-XX:+UseG1GC	G1收集器
-XX:MaxTenuringThreshold=0	在年轻代经过几次GC后还存活，就进入老年代，0表示直接进入老年代

JVM 运行模式

目前（JDK8u）HotSpot VM里，默认有两个JIT编译器，C1（Client Compiler）和C2（Server Compiler）。-XX:+DoEscapeAnalysis（逃逸分析） 和 -XX:+EliminateLocks （锁消除）都是C2特有的功能，只在一个方法被C2编译后才会得到体现。

jvm虚拟机运行模式有三种，分别为Server模式与Client模式和mixed模式，最主要的差别在于：-Server模式启动时，速度较慢，但是一旦运行起来后，性能将会有很大的提升，原因是当虚拟机运行在-client模式的时候,使用的是一个代号为C1的轻量级编译器, 而-server模式启动的虚拟机采用相对重量级代号为C2的编译器。 C2比C1编译器编译的相对彻底,,服务起来之后,性能更高。

• server模式启动慢，编译更完全，编译器是自适应编译器，效率高，针对服务端应用优化，在服务器环境中最大化程序执行速度而设计。
• client模式快速启动，内存占用少，编译快，针对桌面应用程序优化，为在客户端环境中减少启动时间而优化；

 

所以通常用于做服务器的时候我们用服务端模式，如果你的电脑只是运行一下java程序，就客户端模式就可以了。当然这些都是我们做程序优化程序才需要这些东西的，普通人并不关注这些专业的东西了。其实服务器模式即使编译更彻底，然后垃圾回收优化更好，这当然吃的内存要多点相对于客户端模式。当JVM用于启动GUI界面的交互应用时适合于使用client模式，当JVM用于运行服务器后台程序时建议用Server模式。

可以通过运行:java -version来查看jvm默认工作在什么模式:

C:\Users\Administrator>java -version

java version "1.8.0_131"

Java(TM) SE Runtime Environment (build 1.8.0_131-b11)

Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

怎么修改JVM的启动模式呢？

64位系统默认在 JAVA_HOME/jre/lib/amd64/jvm.cfg(64位只支持server模式)

32在目录JAVA_HOME/jre/lib/i386/jvm.cfg

我的配置是这样的，所以是已服务器模式启动的，当然，你想换成client模式的话，把两个对调一下就可以了。

#

-server KNOWN

-client IGNORE

server 模式下才可以进行逃逸分析

使用jmap -heap pid 命令查看堆栈内存：

JVM 参数优化：

https://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html