JVM调优

  • JVM内存模型如何分配的？
  • JVM性能调优的原则有哪些？
  • 什么情况下需要JVM调优？
  • 在JVM调优时，你关注哪些指标？
  • JVM常用参数有哪些？
  • JVM常用性能调优工具有哪些？
  • 线上排查问题的一般流程是怎么样的？
  • 什么情况下，会抛出OOM呢？
  • 系统OOM之前都有哪些现象？
  • 如何进行堆Dump文件分析？
  • 如何进行GC日志分析？
  • 线上死锁是如何排查的？
  • 线上YGC耗时过长优化方案有哪些？
  • 线上频繁FullGC优化方案有哪些？
  • 如何进行线上堆外内存泄漏的分析？（Netty尤其居多）
  • 线上元空间内存泄露优化方案有哪些？
  • GC如何判断对象可以被回收？
  • 如何回收内存对象，有哪些回收算法？
  • jvm有哪些垃圾回收器，实际中如何选择？
  • JVM8为什么要增加元空间？
  • JVM8中元空间有哪些特点？
  • 如何解决线上gc频繁的问题？
  • 内存溢出的原因有哪些，如何排查线上问题？

JVM内存模型如何分配的？

JVM性能调优的原则有哪些？

  1. 多数的Java应用不需要在服务器上进行GC优化，虚拟机内部已有很多优化来保证应用的稳定运行，所以不要为了调优而调优，不当的调优可能适得其反
  2. 在应用上线之前，先考虑将机器的JVM参数设置到最优（适合）
  3. 在进行GC优化之前，需要确认项目的架构和代码等已经没有优化空间。我们不能指望一个系统架构有缺陷或者代码层次优化没有穷尽的应用，通过GC优化令其性能达到一个质的飞跃
  4. GC优化是一个系统而复杂的工作，没有万能的调优策略可以满足所有的性能指标。GC优化必须建立在我们深入理解各种垃圾回收器的基础上，才能有事半功倍的效果
  5. 处理吞吐量和延迟问题时，垃圾处理器能使用的内存越大，即java堆空间越大垃圾收集效果越好，应用运行也越流畅。这称之为GC内存最大化原则
  6. 在这三个属性（吞吐量、延迟、内存）中选择其中两个进行jvm调优，称之为GC调优3选2

什么情况下需要JVM调优？

  • Heap内存（老年代）持续上涨达到设置的最大内存值
  • Full GC 次数频繁
  • GC 停顿（Stop World）时间过长（超过1秒，具体值按应用场景而定）
  • 应用出现OutOfMemory 等内存异常
  • 应用出现OutOfDirectMemoryError等内存异常（ failed to allocate 16777216 byte(s) of direct memory (used: 1056964615, max: 1073741824)）
  • 应用中有使用本地缓存且占用大量内存空间
  • 系统吞吐量与响应性能不高或下降
  • 应用的CPU占用过高不下或内存占用过高不下

在JVM调优时，你关注哪些指标？

  1. **吞吐量：**用户代码时间 / （用户代码执行时间 + 垃圾回收时间）。是评价垃圾收集器能力的重要指标之一，是不考虑垃圾收集引起的停顿时间或内存消耗，垃圾收集器能支撑应用程序达到的最高性能指标。吞吐量越高算法越好。
  2. **低延迟：**STW越短，响应时间越好。评价垃圾收集器能力的重要指标，度量标准是缩短由于垃圾收集引起的停顿时间或完全消除因垃圾收集所引起的停顿，避免应用程序运行时发生抖动。暂停时间越短算法越好
  3. 在设计（或使用）GC 算法时，我们必须确定我们的目标：一个 GC 算法只可能针对两个目标之一（即只专注于最大吞吐量或最小暂停时间），或尝试找到一个二者的折衷
  4. MinorGC尽可能多的收集垃圾对象。我们把这个称作MinorGC原则，遵守这一原则可以降低应用程序FullGC 的发生频率。FullGC 较耗时，是应用程序无法达到延迟要求或吞吐量的罪魁祸首
  5. 堆大小调整的着手点、分析点：
    1. 统计Minor GC 持续时间
    2. 统计Minor GC 的次数
    3. 统计Full GC的最长持续时间
    4. 统计最差情况下Full GC频率
    5. 统计GC持续时间和频率对优化堆的大小是主要着手点
    6. 我们按照业务系统对延迟和吞吐量的需求，在按照这些分析我们可以进行各个区大小的调整
  6. 一般来说吞吐量优先的垃圾回收器：-XX:+UseParallelGC -XX:+UseParallelOldGC，即常规的（PS/PO）
  7. 响应时间优先的垃圾回收器：CMS、G1

JVM常用参数有哪些？

  1. Xms 是指设定程序启动时占用内存大小。一般来讲，大点，程序会启动的快一点，但是也可能会导致机器暂时间变慢
  2. Xmx 是指设定程序运行期间最大可占用的内存大小。如果程序运行需要占用更多的内存，超出了这个设置值，就会抛出OutOfMemory异常
  3. Xss 是指设定每个线程的堆栈大小。这个就要依据你的程序，看一个线程大约需要占用多少内存，可能会有多少线程同时运行等
  4. **-Xmn、-XX:NewSize/-XX:MaxNewSize、-XX:NewRatio **
    1. 高优先级：-XX:NewSize/-XX:MaxNewSize
    2. 中优先级：-Xmn（默认等效 -Xmn=-XX:NewSize=-XX:MaxNewSize=” />

      它的主要不足有两个：

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

      为了解决效率问题，一种称为复制（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）。

      1. 标记-整理算法

      复制收集算法在对象存活率较高时就要进行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种算法。根据老年代的特点，有人提出了另外一种标记-整理（Mark-Compact）算法，标记过程仍然与标记-清除算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

      1. 分代收集算法

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

      jvm有哪些垃圾回收器，实际中如何选择？

      图中展示了7种作用于不同分代的收集器，如果两个收集器之间存在连线，则说明它们可以搭配使用。虚拟机所处的区域则表示它是属于新生代还是老年代收集器。
      新生代收集器（全部的都是复制算法）：Serial、ParNew、Parallel Scavenge
      老年代收集器：CMS（标记-清理）、Serial Old（标记-整理）、Parallel Old（标记整理）
      整堆收集器： G1（一个Region中是标记-清除算法，2个Region之间是复制算法）
      同时，先解释几个名词：
      1，并行（Parallel）：多个垃圾收集线程并行工作，此时用户线程处于等待状态
      2，并发（Concurrent）：用户线程和垃圾收集线程同时执行
      3，吞吐量：运行用户代码时间／（运行用户代码时间＋垃圾回收时间）

      1.Serial收集器是最基本的、发展历史最悠久的收集器。
      **特点：**单线程、简单高效（与其他收集器的单线程相比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程手机效率。收集器进行垃圾回收时，必须暂停其他所有的工作线程，直到它结束（Stop The World）。

      应用场景：适用于Client模式下的虚拟机。
      Serial / Serial Old收集器运行示意图

      2.ParNew收集器其实就是Serial收集器的多线程版本。
      除了使用多线程外其余行为均和Serial收集器一模一样（参数控制、收集算法、Stop The World、对象分配规则、回收策略等）。
      特点：多线程、ParNew收集器默认开启的收集线程数与CPU的数量相同，在CPU非常多的环境中，可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。
      　　　和Serial收集器一样存在Stop The World问题
      应用场景：ParNew收集器是许多运行在Server模式下的虚拟机中首选的新生代收集器，因为它是除了Serial收集器外，唯一一个能与CMS收集器配合工作的。
      ParNew/Serial Old组合收集器运行示意图如下：

      3.Parallel Scavenge 收集器与吞吐量关系密切，故也称为吞吐量优先收集器。
      特点：属于新生代收集器也是采用复制算法的收集器，又是并行的多线程收集器（与ParNew收集器类似）。
      该收集器的目标是达到一个可控制的吞吐量。还有一个值得关注的点是：GC自适应调节策略（与ParNew收集器最重要的一个区别）

      GC自适应调节策略：Parallel Scavenge收集器可设置-XX:+UseAdptiveSizePolicy参数。当开关打开时不需要手动指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SurvivorRation）、晋升老年代的对象年龄（-XX:PretenureSizeThreshold）等，虚拟机会根据系统的运行状况收集性能监控信息，动态设置这些参数以提供最优的停顿时间和最高的吞吐量，这种调节方式称为GC的自适应调节策略。
      Parallel Scavenge收集器使用两个参数控制吞吐量：

      • XX:MaxGCPauseMillis 控制最大的垃圾收集停顿时间
      • XX:GCRatio 直接设置吞吐量的大小。

      4.Serial Old是Serial收集器的老年代版本。
      特点：同样是单线程收集器，采用标记-整理算法。
      应用场景：主要也是使用在Client模式下的虚拟机中。也可在Server模式下使用。
      Server模式下主要的两大用途（在后续中详细讲解···）：

      1. 在JDK1.5以及以前的版本中与Parallel Scavenge收集器搭配使用。
      2. 作为CMS收集器的后备方案，在并发收集Concurent Mode Failure时使用。

      Serial / Serial Old收集器工作过程图（Serial收集器图示相同）：

      5.Parallel Old是Parallel Scavenge收集器的老年代版本。
      特点：多线程，采用标记-整理算法。
      应用场景：注重高吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge+Parallel Old 收集器。
      Parallel Scavenge/Parallel Old收集器工作过程图：
      6.CMS收集器是一种以获取最短回收停顿时间为目标的收集器。
      特点：基于标记-清除算法实现。并发收集、低停顿。
      应用场景：适用于注重服务的响应速度，希望系统停顿时间最短，给用户带来更好的体验等场景下。如web程序、b/s服务。
      CMS收集器的运行过程分为下列4步：
      初始标记：标记GC Roots能直接到的对象。速度很快但是仍存在Stop The World问题。
      并发标记：进行GC Roots Tracing 的过程，找出存活对象且用户线程可并发执行。
      重新标记：为了修正并发标记期间因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录。仍然存在Stop The World问题。
      并发清除：对标记的对象进行清除回收。
      CMS收集器的内存回收过程是与用户线程一起并发执行的。
      CMS收集器的工作过程图：

      CMS收集器的缺点：

      • 对CPU资源非常敏感。
      • 无法处理浮动垃圾，可能出现Concurrent Model Failure失败而导致另一次Full GC的产生。
      • 因为采用标记-清除算法所以会存在空间碎片的问题，导致大对象无法分配空间，不得不提前触发一次Full GC。

      ​

      7.G1收集器一款面向服务端应用的垃圾收集器。
      特点如下：
      并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短Stop-The-World停顿时间。部分收集器原本需要停顿Java线程来执行GC动作，G1收集器仍然可以通过并发的方式让Java程序继续运行。
      分代收集：G1能够独自管理整个Java堆，并且采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。
      空间整合：G1运作期间不会产生空间碎片，收集后能提供规整的可用内存。
      可预测的停顿：G1除了追求低停顿外，还能建立可预测的停顿时间模型。能让使用者明确指定在一个长度为M毫秒的时间段内，消耗在垃圾收集上的时间不得超过N毫秒。
      G1收集器运行示意图：

      ​

      关于gc的选择
      除非应用程序有非常严格的暂停时间要求，否则请先运行应用程序并允许VM选择收集器（如果没有特别要求。使用VM提供给的默认GC就好）。
      如有必要，调整堆大小以提高性能。 如果性能仍然不能满足目标，请使用以下准则作为选择收集器的起点：

      • 如果应用程序的数据集较小（最大约100 MB），则选择带有选项-XX：+ UseSerialGC的串行收集器。
      • 如果应用程序将在单个处理器上运行，并且没有暂停时间要求，则选择带有选项-XX：+ UseSerialGC的串行收集器。
      • 如果（a）峰值应用程序性能是第一要务，并且（b）没有暂停时间要求或可接受一秒或更长时间的暂停，则让VM选择收集器或使用-XX：+ UseParallelGC选择并行收集器 。
      • 如果响应时间比整体吞吐量更重要，并且垃圾收集暂停时间必须保持在大约一秒钟以内，则选择具有-XX：+ UseG1GC。（值得注意的是JDK9中CMS已经被Deprecated，不可使用！移除该选项）
      • 如果使用的是jdk8，并且堆内存达到了16G，那么推荐使用G1收集器，来控制每次垃圾收集的时间。
      • 如果响应时间是高优先级，或使用的堆非常大，请使用-XX：UseZGC选择完全并发的收集器。（值得注意的是JDK11开始可以启动ZGC，但是此时ZGC具有实验性质，在JDK15中[202009发布]才取消实验性质的标签，可以直接显示启用，但是JDK15默认GC仍然是G1）

        这些准则仅提供选择收集器的起点，因为性能取决于堆的大小，应用程序维护的实时数据量以及可用处理器的数量和速度。

        如果推荐的收集器没有达到所需的性能，则首先尝试调整堆和新生代大小以达到所需的目标。 如果性能仍然不足，尝试使用其他收集器。

      总体原则：减少STOP THE WORD时间，使用并发收集器（比CMS+ParNew，G1）来减少暂停时间，加快响应时间，并使用并行收集器来增加多处理器硬件上的总体吞吐量。

      JVM8为什么要增加元空间？

      原因：
       1、字符串存在永久代中，容易出现性能问题和内存溢出。
       2、类及方法的信息等比较难确定其大小，因此对于永久代的大小指定比较困难，太小容易出现永久代溢出，太大则容易导致老年代溢出。
       3、永久代会为 GC 带来不必要的复杂度，并且回收效率偏低。

      JVM8中元空间有哪些特点？

      1，每个加载器有专门的存储空间。
      2，不会单独回收某个类。
      3，元空间里的对象的位置是固定的。
      4，如果发现某个加载器不再存货了，会把相关的空间整个回收

      如何解决线上gc频繁的问题？

      1. 查看监控，以了解出现问题的时间点以及当前FGC的频率（可对比正常情况看频率是否正常）
      2. 了解该时间点之前有没有程序上线、基础组件升级等情况。
      3. 了解JVM的参数设置，包括：堆空间各个区域的大小设置，新生代和老年代分别采用了哪些垃圾收集器，然后分析JVM参数设置是否合理。
      4. 再对步骤1中列出的可能原因做排除法，其中元空间被打满、内存泄漏、代码显式调用gc方法比较容易排查。
      5. 针对大对象或者长生命周期对象导致的FGC，可通过 jmap -histo 命令并结合dump堆内存文件作进一步分析，需要先定位到可疑对象。
      6. 通过可疑对象定位到具体代码再次分析，这时候要结合GC原理和JVM参数设置，弄清楚可疑对象是否满足了进入到老年代的条件才能下结论。

      内存溢出的原因有哪些，如何排查线上问题？

      1. java.lang.OutOfMemoryError: …java heap space… 堆栈溢出，代码问题的可能性极大
      2. java.lang.OutOfMemoryError: GC over head limit exceeded 系统处于高频的GC状态，而且回收的效果依然不佳的情况，就会开始报这个错误，这种情况一般是产生了很多不可以被释放的对象，有可能是引用使用不当导致，或申请大对象导致，但是java heap space的内存溢出有可能提前不会报这个错误，也就是可能内存就直接不够导致，而不是高频GC.
      3. java.lang.OutOfMemoryError: PermGen space jdk1.7之前才会出现的问题 ，原因是系统的代码非常多或引用的第三方包非常多、或代码中使用了大量的常量、或通过intern注入常量、或者通过动态代码加载等方法，导致常量池的膨胀
      4. java.lang.OutOfMemoryError: Direct buffer memory 直接内存不足，因为jvm垃圾回收不会回收掉直接内存这部分的内存，所以可能原因是直接或间接使用了ByteBuffer中的allocateDirect方法的时候，而没有做clear
      5. java.lang.StackOverflowError – Xss设置的太小了
      6. java.lang.OutOfMemoryError: unable to create new native thread 堆外内存不足，无法为线程分配内存区域
      7. java.lang.OutOfMemoryError: request {} byte for {}out of swap 地址空间不够