Jvm调优

Jvm调优概念

Jvm调优目的

对JVM内存的系统级的调优主要的目的是减少GC的频率和Full GC的次数，过多的GC和Full GC是会占用很多的系统资源（主要是CPU），影响系统的吞吐量。特别要关注Full GC，因为它会对整个堆进行整理。
将转移到老年代的对象数量降低到最小；
减少full GC的执行时间

减少使用全局变量和大对象；
调整新生代的大小到最合适；
设置老年代的大小为最合适；
选择合适的GC收集器；

Jvm调优步骤

在上面的4条方法中，用了几个“合适”，那究竟什么才算合适，一般的，请参考上面“收集器搭配”和“启动内存分配”两节中的建议。但这些建议不是万能的，需要根据您的机器和应用情况进行发展和变化，实际操作中，可以将两台机器分别设置成不同的GC参数，并且进行对比，选用那些确实提高了性能或减少了GC时间的参数。
真正熟练的使用GC调优，是建立在多次进行GC监控和调优的实战经验上的，进行监控和调优的一般步骤为：
1，监控GC的状态
使用各种JVM工具，查看当前日志，分析当前JVM参数设置，并且分析当前堆内存快照和gc日志，根据实际的各区域内存划分和GC执行时间，觉得是否进行优化；
2，分析结果，判断是否需要优化
如果各项参数设置合理，系统没有超时日志出现，GC频率不高，GC耗时不高，那么没有必要进行GC优化；如果GC时间超过1-3秒，或者频繁GC，则必须优化；
注：如果满足下面的指标，则一般不需要进行GC：
Minor GC执行时间不到50ms；
Minor GC执行不频繁，约10秒一次；
Full GC执行时间不到1s；
Full GC执行频率不算频繁，不低于10分钟1次；
3，调整GC类型和内存分配
如果内存分配过大或过小，或者采用的GC收集器比较慢，则应该优先调整这些参数，并且先找1台或几台机器进行beta，然后比较优化过的机器和没有优化的机器的性能对比，并有针对性的做出最后选择；
4，不断的分析和调整
通过不断的试验和试错，分析并找到最合适的参数
5，全面应用参数
如果找到了最合适的参数，则将这些参数应用到所有服务器，并进行后续跟踪。

jvm内存结构

结构

**1. 程序计数器（Program Counter Register）**是一块较小的内存空间，它的作用可以看做是当前线程所执行字节码的行号指示器。是线程私有，生命周期与线程相同。
**2. Java虚拟机栈（Java Virtual Machine Stacks）**也是线程私有的，它的生命周期与线程相同。
Java虚拟机栈描述的是Java方法（区别于native的本地方法）执行的内存模型：每个方法被执行的时候都会同时创建一个栈帧（Stack Frame）用于存储局部变量表、操作栈、动作链接、方法出口等信息。每个方法被调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。
**3. 本地方法栈（Native Method Stacks）**与虚拟机栈所发挥的作用是非常相似的，其区别不过是虚拟机栈为虚拟机执行Java方法(也就是字节码)服务，而本地方法栈则为虚拟机所使用到的Native方法服务。

JDK7,JDK8中JVM内存变化

Java7中已经将运行时常量池从永久代移除，在Java 堆（Heap）中开辟了一块区域存放运行时常量池。
Java8中，已经彻底没有了永久代，将方法区直接放在一个与堆不相连的本地内存区域，这个区域被叫做元空间

JDK1.7之前的版本

其中最上一层是Nursery内存，一个对象被创建以后首先被放到Nursery中的Eden内
存中，如果存活期超两个Survivor之后就会被转移到长时内存中(Old Generation)中。

JDK1.8版本

JDK8中把存放元数据中的永久内存从堆内存中移到了本地内存(native memory)中，这样永久内存就不再占用堆内存，它可以通过自动增长来避免JDK7以及前期版本中常见的永久内存错误(Java.lang.OutOfMemoryError: PermGen)。

JDK8也提供了一个新的设置Matespace内存大小的参数：-XX:MaxMetaspaceSize=128m

内存管理

HotSpot JVM （下简称JVM）的内存管理
JVM将堆分成了 二个大区 Young 和 Old 如下图：

而Young 区又分为 Eden、Servivor1、Servivor2, 两个Survivor 区相对地作为为From 和 To 逻辑区域, 当Servivor1作为 From 时 ， Servivor2 就作为 To, 反之亦然
关于为什么要这样区分Young（将Young区分为Eden、Servivor1、Servivor2以及相对的From和To ），这要牵涉到JVM的垃圾回收算法的讨论。
1）因为引用计数法无法解决循环引用问题，JVM并没有采用这种算法来判断对象是否存活。
2）JVM一般采用GCRoots的方法，只要从任何一个GCRoots的对象可达，就是不被回收的对象
3）判断了对象生死，怎么进行内存的清理呢？
4）标记-清除算法，先标记那些要被回收的对象，然后进行清理，简单可行，但是①标记清除效率低，因为要一个一个标记和清除②造成大量不连续的内存碎片，空间碎片太多可能会导致当程序在以后的运行过程中需要分配较大对象的时候无法找到足够的连续内存而不得不触发另一次垃圾收集动作。
5）采用复制收集算法：将可用内存按照容量分为大小相等的两块，每次只是使用其中的一块。当这一块的内存用完了，就将可用内存中



上面的过程就解释了为什么我们的Yong内存需要分为三块，Eden，Survivor1，Survivor2以及FROM TO相对使用的用法

因此当Eden区满的时候 GC执行，这时会将 Eden 区和 From 区中还被引用的对象会被移到 To区 ，个别大对象和部分From对象在To已满的情况下会被放到Old区,如下图：

HotSpot VM 内存堆的两个Servivor区

Java中的static变量和static方法在JVM运行中内存的分配管理有什么不同和一般变量方法？

	静态对象	非静态对象
拥有属性：	是类共同拥有的	是类各对象独立拥有的
内存分配：	内存空间上是固定的	空间在各个附属类里面分配
分配顺序：	先分配静态对象的空间	继而再对非静态对象分配空间,也就是初 始化顺序是先静态

Java类的加载过程？
在heap中没有类实例的时候，类信息还存在于JVM吗？ 存在于什么地方？

内存分配策略

大对象直接进入老年代
-XX PretenureSizeThreshold 指定多大的对象才算大对象 大于这个值就直接进入老年代 大对象一般是字符串或者是数组
大对象如果在新生代 gc执行频率高 大对象频繁移动 性能会降低 所以大对象直接放入老年代 老年代gc频率低 性能相对好很多

长期存活的对象将进入老年代
-XX：MaxTenuringThreshold
年龄计数器 进入servivor开始计算 默认15 jdk6之后改动 不是严格按照这个标准执行
有可能执行一两次就进入了老年代
空间分配担保
-XX：+HandlePromotionFailure 开启空间分配担保 -为禁用 默认启用
禁用可能会抛出异常
开启会有一定风险
进入老年代的大内存前 jvm会检测老年代有没有能容纳下eden所有对象内存
验证老年代最大的可用的连续空间是否大于历次进入到老年代内存的平均大小

Minor gc

发生在新生代 朝生夕死 gc频率高 时间短
触发条件：
1、eden区满时，触发MinorGC。即申请一个对象时，发现eden区不够用，则触发一次MinorGC。

2、Full GC之前调用，仅适用于Parallel Scavenge（-XX:+UseParallelGC），虚拟机运行在Server模式下的默认收集器组合。

Full gc

通过手动调用 或者 系统自动发起 频率低
老年代对象存活时间长 执行耗时长 性能上要10倍以上
触发条件：
1、老生代空间不够分配新的内存
2、System.gc()，见Minor GC触发条件的第2点。
3、通过Minor GC后进入老年代的平均大小大于老年代的可用内存
4、Minor GC时，eden space和from space区大小大于to space且大于老年代内存，触发Full GC。
5、Metaspace空间不足。

收集器介绍

一、Serial收集器

最基本，发展最悠久 单线程垃圾收集器 适合分配内存比较小的比如桌面应用
曾经（在JDK 1.3.1之前）是虚拟机新生代收集的唯一选择
（新生代收集器）

特性：
这个收集器是一个单线程的收集器，但它的“单线程”的意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。Stop The World

优势：
简单而高效（与其他收集器的单线程比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。

二、ParNew收集器

多线程垃圾收集器
（新生代收集器）

特性：
ParNew收集器其实就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一样，在实现上，这两种收集器也共用了相当多的代码。

优势：
除了多线程收集以外，跟Serial收集器一样，很重要的原因是：除了Serial收集器外，目前只有它能与CMS收集器配合工作。CMS作为老年代的收集器，却无法与JDK 1.4.0中已经存在的新生代收集器Parallel Scavenge配合工作，所以在JDK 1.5中使用CMS来收集老年代的时候，新生代只能选择ParNew或者Serial收集器中的一个。
Serial收集器 VS ParNew收集器：
ParNew收集器在单CPU的环境中绝对不会有比Serial收集器更好的效果，甚至由于存在线程交互的开销，该收集器在通过超线程技术实现的两个CPU的环境中都不能百分之百地保证可以超越Serial收集器。
然而，随着可以使用的CPU的数量的增加，它对于GC时系统资源的有效利用还是很有好处的。

三、Parallel Scavenge收集器

jdk是server 默认使用 本机内存大于2G默认server



特性：
Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器。Parallel Scavenge收集器的目标是达到一个可控的吞吐量，可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。

Parallel Scavenge收集器 VS ParNew收集器：

Parallel Scavenge收集器与ParNew收集器的一个重要区别是它具有自适应调节策略。Parallel Scavenge收集器有一个参数-XX:+UseAdaptiveSizePolicy。当这个参数打开之后，就不需要手工指定新生代的大小、Eden与Survivor区的比例、晋升老年代对象年龄等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量，这种调节方式称为GC自适应的调节策略（GC Ergonomics）。

四、Serial Old收集器

特性：
Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用标记－整理算法。它主要有两大用途：一种用途是在JDK 1.5以及之前的版本中与Parallel Scavenge收集器搭配使用，另一种用途就是作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。

五、Parallel Old收集器

特性：
Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记－整理”算法。

优势：
在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。这个收集器是在JDK 1.6中才开始提供的，在此之前，新生代的Parallel Scavenge收集器一直处于比较尴尬的状态。原因是，如果新生代选择了Parallel Scavenge收集器，老年代除了Serial Old收集器外别无选择。由于老年代Serial Old收集器在服务端应用性能上的“拖累”，使用了Parallel Scavenge收集器也未必能在整体应用上获得吞吐量最大化的效果，由于单线程的老年代收集中无法充分利用服务器多CPU的处理能力，在老年代很大而且硬件比较高级的环境中，这种组合的吞吐量甚至还不一定有ParNew加CMS的组合“给力”。直到Parallel Old收集器出现后，“吞吐量优先”收集器终于有了比较名副其实的应用组合。

六、CMS收集器

老年代收集器 标记清除算法是用在老年代收集器的


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

CMS收集器是基于“标记—清除”算法实现的，它的运作过程相对于前面几种收集器来说更复杂一些，整个过程分为4个步骤：

初始标记（CMS initial mark） 初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，需要“Stop The World”。

并发标记（CMS concurrent mark） 并发标记阶段就是进行GC Roots Tracing的过程。

重新标记（CMS remark） 重新标记阶段是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短，仍然需要“Stop
The World”。

并发清除（CMS concurrent sweep） 并发清除阶段会清除对象。

由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。

优点：
CMS是一款优秀的收集器，它的主要优点在名字上已经体现出来了：并发收集、低停顿。

缺点：
CMS收集器对CPU资源非常敏感
其实，面向并发设计的程序都对CPU资源比较敏感。在并发阶段，它虽然不会导致用户线程停顿，但是会因为占用了一部分线程（或者说CPU资源）而导致应用程序变慢，总吞吐量会降低。
CMS默认启动的回收线程数是（CPU数量+3）/ 4，也就是当CPU在4个以上时，并发回收时垃圾收集线程不少于25%的CPU资源，并且随着CPU数量的增加而下降。但是当CPU不足4个（譬如2个）时，CMS对用户程序的影响就可能变得很大。

CMS收集器无法处理浮动垃圾
CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。

由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉它们，只好留待下一次GC时再清理掉。这一部分垃圾就称为“浮动垃圾”。
也是由于在垃圾收集阶段用户线程还需要运行，那也就还需要预留有足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使用。要是CMS运行期间预留的内存无法满足程序需要，就会出现一次“Concurrent Mode Failure”失败，这时虚拟机将启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。

CMS收集器会产生大量空间碎片
CMS是一款基于“标记—清除”算法实现的收集器，这意味着收集结束时会有大量空间碎片产生。

空间碎片过多时，将会给大对象分配带来很大麻烦，往往会出现老年代还有很大空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次Full GC。

七、G1收集器

特性：
G1（Garbage-First）是一款面向服务端应用的垃圾收集器。HotSpot开发团队赋予它的使命是未来可以替换掉JDK 1.5中发布的CMS收集器。与其他GC收集器相比，G1具备如下特点。
并行与并发
G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短Stop-The-World停顿的时间，部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。

分代收集
与其他收集器一样，分代概念在G1中依然得以保留。虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。

空间整合
与CMS的“标记—清理”算法不同，G1从整体来看是基于“标记—整理”算法实现的收集器，从局部（两个Region之间）上来看是基于“复制”算法实现的，但无论如何，这两种算法都意味着G1运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。

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

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

G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region（这也就是Garbage-First名称的来由）。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限的时间内可以获取尽可能高的收集效率。

执行过程：
G1收集器的运作大致可划分为以下几个步骤：

初始标记（Initial Marking）
初始标记阶段仅仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS（Next Top at Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建新对象，这阶段需要停顿线程，但耗时很短。

并发标记（Concurrent Marking）
并发标记阶段是从GCRoot开始对堆中对象进行可达性分析，找出存活的对象，这阶段耗时较长，但可与用户程序并发执行。

最终标记（Final Marking）
最终标记阶段是为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线程Remembered Set Logs里面，最终标记阶段需要把Remembered Set Logs的数据合并到Remembered Set中，这阶段需要停顿线程，但是可并行执行。

筛选回收（Live Data Counting and Evacuation）
筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划，这个阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅提高收集效率。