高频面试题 ----------JVM调优

Posted Connection Reset

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了高频面试题 ----------JVM调优相关的知识，希望对你有一定的参考价值。

JVM调优

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=?）
    3. 低优先级：-XX:NewRatio
  5. 如果想在日志中追踪类加载与类卸载的情况，可以使用启动参数 **-XX:TraceClassLoading -XX:TraceClassUnloading **

JVM常用性能调优工具有哪些？

  1. MAT

    1. 提示可能的内存泄露的点

  2. jvisualvm

  3. jconsole

  4. Arthas

  5. show-busy-java-threads

线上排查问题的一般流程是怎么样的？

  1. CPU占用过高排查流程
    1. 利用 top 命令可以查出占 CPU 最高的的进程pid ，如果pid为 9876
    2. 然后查看该进程下占用最高的线程id【top -Hp 9876】
    3. 假设占用率最高的线程 ID 为 6900，将其转换为 16 进制形式 (因为 java native 线程以 16 进制形式输出) 【printf ‘%x\\n’ 6900】
    4. 利用 jstack 打印出 java 线程调用栈信息【jstack 9876 | grep ‘0x1af4’ -A 50 --color】，这样就可以更好定位问题
  2. 内存占用过高排查流程
    1. 查找进程id: 【top -d 2 -c】
    2. 查看JVM堆内存分配情况：jmap -heap pid
    3. 查看占用内存比较多的对象 jmap -histo pid | head -n 100
    4. 查看占用内存比较多的存活对象 jmap -histo:live pid | head -n 100

什么情况下，会抛出OOM呢？

  • JVM98%的时间都花费在内存回收
  • 每次回收的内存小于2%

  满足这两个条件将触发OutOfMemoryException，这将会留给系统一个微小的间隙以做一些Down之前的操作，比如手动打印Heap Dump。并不是内存被耗空的时候才抛出
​

系统OOM之前都有哪些现象？

  • 每次垃圾回收的时间越来越长，由之前的10ms延长到50ms左右，FullGC的时间也有之前的0.5s延长到4、5s
  • FullGC的次数越来越多，最频繁时隔不到1分钟就进行一次FullGC
  • 老年代的内存越来越大并且每次FullGC后，老年代只有少量的内存被释放掉

如何进行堆Dump文件分析？

  可以通过指定启动参数 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/app/data/dump/heapdump.hpro 在发生OOM的时候自动导出Dump文件
​

如何进行GC日志分析？

  为了方便分析GC日志信息，可以指定启动参数 【-Xloggc: app-gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps】,方便详细地查看GC日志信息

  1. 使用 【jinfo pid】查看当前JVM堆的相关参数
  2. 继续使用 【jstat -gcutil 2315 1s 10】查看10s内当前堆的占用情况
  3. 也可以使用【jmap -heap pid】查看当前JVM堆的情况
  4. 我们可以继续使用 【jmap -F -histo pid | head -n 20】，查看前20行打印，即查看当前top20的大对象，一般从这里可以发现一些异常的大对象，如果没有，那么可以继续排名前50的大对象，分析
  5. 最后使用【jmap -F -dump:file=a.bin pid】，如果dump文件很大，可以压缩一下【tar -czvf a.tar.gz a.bin】
  6. 再之后，就是对dump文件进行分析了，使用MAT分析内存泄露
  7. 参考案例： https://www.lagou.com/lgeduarticle/142372.html

线上死锁是如何排查的？

  1. jps 查找一个可能有问题的进程id
  2. 然后执行 【jstack -F 进程id】
  3. 如果环境允许远程连接JVM，可以使用jconsole或者jvisualvm，图形化界面检测是否存在死锁

线上YGC耗时过长优化方案有哪些？

  1. 如果生命周期过长的对象越来越多（比如全局变量或者静态变量等），会导致标注和复制过程的耗时增加
  2. 对存活对象标注时间过长：比如重载了Object类的Finalize方法，导致标注Final Reference耗时过长；或者String.intern方法使用不当，导致YGC扫描StringTable时间过长。可以通过以下参数显示GC处理Reference的耗时-XX:+PrintReferenceGC
  3. 长周期对象积累过多：比如本地缓存使用不当，积累了太多存活对象；或者锁竞争严重导致线程阻塞，局部变量的生命周期变长

线上频繁FullGC优化方案有哪些？

  1. 线上频繁FullGC一般会有这么几个特征：
    1. 线上多个线程的CPU都超过了100%，通过jstack命令可以看到这些线程主要是垃圾回收线程
    2. 通过jstat命令监控GC情况，可以看到Full GC次数非常多，并且次数在不断增加
  2. 排查流程：
    1. top找到cpu占用最高的一个 进程id
    2. 然后 【top -Hp 进程id】，找到cpu占用最高的 线程id
    3. 【printf “%x\\n” 线程id 】，假设16进制结果为 a
    4. jstack 线程id | grep ‘0xa’ -A 50 --color
    5. 如果是正常的用户线程， 则通过该线程的堆栈信息查看其具体是在哪处用户代码处运行比较消耗CPU
    6. 如果该线程是 VMThread，则通过 jstat-gcutil命令监控当前系统的GC状况，然后通过 jmapdump:format=b,file=导出系统当前的内存数据。导出之后将内存情况放到eclipse的mat工具中进行分析即可得出内存中主要是什么对象比较消耗内存，进而可以处理相关代码；正常情况下会发现VM Thread指的就是垃圾回收的线程
    7. 再执行【jstat -gcutil **进程id】, **看到结果，如果FGC的数量很高，且在不断增长，那么可以定位是由于内存溢出导致FullGC频繁，系统缓慢
    8. 然后就可以Dump出内存日志，然后使用MAT的工具分析哪些对象占用内存较大，然后找到对象的创建位置，处理即可
  3. 参考案例：https://mp.weixin.qq.com/s/g8KJhOtiBHWb6wNFrCcLVg

如何进行线上堆外内存泄漏的分析？（Netty尤其居多）

  1. JVM的堆外内存泄露的定位一直是个比较棘手的问题
  2. 对外内存的泄漏分析一般都是先从堆内内存分析的过程中衍生出来的。有可能我们分析堆内内存泄露过程中发现，我们计算出来的JVM堆内存竟然大于了整个JVM的Xmx的大小，那说明多出来的是堆外内存
  3. 如果使用了 Netty 堆外内存，那么可以自行监控堆外内存的使用情况，不需要借助第三方工具，我们是使用的“反射”拿到的堆外内存的情况
  4. 逐渐缩小范围，直到 Bug 被找到。当我们确认某个线程的执行带来 Bug 时，可单步执行，可二分执行，定位到某行代码之后，跟到这段代码，然后继续单步执行或者二分的方式来定位最终出 Bug 的代码。这个方法屡试不爽，最后总能找到想要的 Bug
  5. 熟练掌握 idea 的调试，让我们的“捉虫”速度快如闪电（“闪电侠”就是这么来的）。这里，最常见的调试方式是预执行表达式，以及通过线程调用栈，死盯某个对象，就能够掌握这个对象的定义、赋值之类
  6. 在使用直接内存的项目中，最好建议配置 -XX:MaxDirectMemorySize，设定一个系统实际可达的最大的直接内存的值，默认的最大直接内存大小等于 -Xmx的值
  7. 排查堆外泄露，建议指定启动参数： -XX:NativeMemoryTracking=summary - Dio.netty.leakDetection.targetRecords=100-Dio.netty.leakDetection.level=PARANOID，后面两个参数是Netty的相关内存泄露检测的级别与采样级别
  8. 参考案例： https://tech.meituan.com/2018/10/18/netty-direct-memory-screening.html

线上元空间内存泄露优化方案有哪些？

  1. 需要注意的一点是 Java8以及Java8+的JVM已经将永久代废弃了，取而代之的是元空间，且元空间是不是在JVM堆中的，而属于堆外内存，受最大物理内存限制。最佳实践就是我们在启动参数中最好设置上 -XX:MetaspaceSize=1024m -XX:MaxMetaspaceSize=1024m。具体的值根据情况设置。为避免动态申请，可以直接都设置为最大值
  2. 元空间主要存放的是类元数据，而且metaspace判断类元数据是否可以回收，是根据加载这些类元数据的Classloader是否可以回收来判断的，只要Classloader不能回收，通过其加载的类元数据就不会被回收。所以线上有时候会出现一种问题，由于框架中，往往大量采用类似ASM、javassist等工具进行字节码增强，生成代理类。如果项目中由主线程频繁生成动态代理类，那么就会导致元空间迅速占满，无法回收
  3. 具体案例可以参见： https://zhuanlan.zhihu.com/p/200802910

GC如何判断对象可以被回收？

  1. 引用计数法（已被淘汰的算法）
    1. 每一个对象有一个引用属性，新增一个引用时加一，引用释放时减一，计数为0的时候可以回收。

但是这种计算方法，有一个致命的问题，无法解决循环引用的问题

  1. 可达性分析算法（根引用）
    1. 从GcRoot开始向下搜索，搜索所走过的路径被称为引用链，当一个对象到GcRoot没有任何引用链相连时，则证明此对象是不可用的，那么虚拟机就可以判定回收。
    2. 那么GcRoot有哪些？
      1. 虚拟机栈中引用的对象
      2. 方法区中静态属性引用的对象。
      3. 方法区中常量引用的对象
      4. 本地方法栈中（即一般说的native方法）引用的对象
  2. 此外，不同的引用类型的回收机制是不一样的
    1. 强引用：通过关键字new的对象就是强引用对象，强引用指向的对象任何时候都不会被回收，宁愿OOM也不会回收。
    2. 软引用：如果一个对象持有软引用，那么当JVM堆空间不足时，会被回收。一个类的软引用可以通过java.lang.ref.SoftReference持有。
    3. 弱引用：如果一个对象持有弱引用，那么在GC时，只要发现弱引用对象，就会被回收。一个类的弱引用可以通过java.lang.ref.WeakReference持有。
    4. 虚引用：几乎和没有一样，随时可以被回收。通过PhantomReference持有。

如何回收内存对象，有哪些回收算法？

1.标记-清除（Mark-Sweep）算法

分为标记和清除两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。

它的主要不足有两个：

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

大数据面试题：ZooKeeper核心高频面试题

文章目录

ZooKeeper核心高频面试题

一、请简述ZooKeeper的选举机制

二、客户端对ZooKeeper的ServerList的轮询机制

三、客户端如何正确处理CONNECTIONLOSS(连接断开) 和 SESSIONEXPIRED(Session 过期)两类连接异常？

四、一个客户端修改了某个节点的数据，其他客户端能够马上获取到这个最新数据吗？

五、ZooKeeper对节点的watch监听是永久的吗？为什么？

六、ZooKeeper中使用watch的注意事项有哪些？

七、能否收到每次节点变化的通知？ 

八、能否为临时节点创建子节点？

九、是否可以拒绝单个IP对ZooKeeper的访问？如何实现？

十、ZooKeeper集群中服务器之间是怎样通信的？

十一、ZooKeeper是否会自动进行日志清理？如何进行日志清理？

十二、谈谈你对ZooKeeper的理解？ 

十三、ZooKeeper节点类型？

1、Znode有两种类型

2、Znode有四种形式的目录节点（默认是persistent ）

十四、请说明ZooKeeper的通知机制？ 

十五、ZooKeeper的监听原理是什么？ 

十六、请说明ZooKeeper使用到的各个端口的作用？ 

十七、ZooKeeper的部署方式有哪几种？集群中的角色有哪些？集群最少需要几台机器？

十八、ZooKeeper集群如果有3台机器，挂掉一台是否还能工作？

十九、ZooKeeper使用的ZAB协议与Paxo算法的异同？

二十、请谈谈对ZooKeeper对事务性的支持？

ZooKeeper核心高频面试题

一、请简述ZooKeeper的选举机制

假设有五台服务器组成的zookeeper集群，它们的id从1-5，同时它们都是最新启动的，也就是没有历史数据， 在存放数据量这一点上，都是一样的。假设这些服务器依序启动，来看看会发生什么。

1、服务器1启动，此时只有它一台服务器启动了，它发出去的报没有任何响应，所以它的选举状态一直是LOOKING状态。

2、服务器2启动，它与最开始启动的服务器1进行通信，互相交换自己的选举结果，由于两者都没有历史数据，所以id值较大的服务器2胜出，但是由于没有达到超过半数以上的服务器都同意选举它（这个例子中的半数以上是3），所以服务器1、2还是继续保持LOOKING状态。

3、服务器3启动，根据前面的理论分析，服务器3成为服务器1、2、3中的Leader，而与上面不同的是，此时 有三台服务器选举了它，所以它成为了这次选举的Leader。

4、服务器4启动，根据前面的分析，理论上服务器4应该是服务器1、2、3、4中最大的，但是由于前面已经有半数以上的服务器选举了服务器3，所以它成为Follower。

5、服务器5启动，同4一样成为Follower。

注意：如果按照5,4,3,2,1的顺序启动，那么5将成为Leader，因为在满足半数条件后，ZooKeeper集群启动，5 的Id最大，被选举为Leader。

二、客户端对ZooKeeper的ServerList的轮询机制

随机，客户端在初始化( new ZooKeeper(String connectString, int sessionTimeout, Watcher watcher) )的过程中，将所有Server保存在一个List中，然后随机打散，形成一个环。之后从0号位开始一个一个使用。

两个注意点：

Server地址能够重复配置，这样能够弥补客户端无法设置Server权重的缺陷，但是也会加大风险。（比如: 192.168.1.1:2181,192.168.1.1:2181,192.168.1.2:2181).

如果客户端在进行Server切换过程中耗时过长，那么将会收到SESSION_EXPIRED. 这也是上面第1点中的加大风险之处。

三、客户端如何正确处理CONNECTIONLOSS(连接断开) 和 SESSIONEXPIRED(Session 过期)两类连接异常？

在ZooKeeper中，服务器和客户端之间维持的是一个长连接，在 SESSION_TIMEOUT 时间内，服务器会确定客户端是否正常连接(客户端会定时向服务器发送heart_beat),服务器重置下次SESSION_TIMEOUT时间。因此，在正常情况下，Session一直有效，并且zk集群所有机器上都保存这个Session信息。在出现问题的情况下，客户端与服务器之间连接断了（客户端所连接的那台zk机器挂了，或是其它原因的网络闪断），这个时候客户端会主动在地址列表（初始化的时候传入构造方法的那个参数connectString）中选择新的地址进行连接。

以上即为服务器与客户端之间维持长连接的过程，在这个过程中，用户可能会看到两类异常CONNECTIONLOSS(连接断开) 和SESSIONEXPIRED(Session 过期)。

发生CONNECTIONLOSS后，此时用户不需要关心我的会话是否可用，应用所要做的就是等待客户端帮我们自动连接上新的zk机器，一旦成功连接上新的zk机器后，确认之前的操作是否执行成功了。

四、一个客户端修改了某个节点的数据，其他客户端能够马上获取到这个最新数据吗？

ZooKeeper不能确保任何客户端能够获取（即Read Request）到一样的数据，除非客户端自己要求，方法是客户端在获取数据之前调用org.apache.zookeeper.AsyncCallbac k.VoidCallback, java.lang.Object) sync。

通常情况下（这里所说的通常情况满足：1. 对获取的数据是否是最新版本不敏感，2. 一个客户端修改了数据， 其它客户端是否需要立即能够获取最新数据），可以不关心这点。

在其它情况下，最清晰的场景是这样：ZK客户端A对 /my_test 的内容从 v1->v2, 但是ZK客户端B对 /my_test 的内容获取，依然得到的是 v1. 请注意，这个是实际存在的现象，当然延时很短。解决的方法是客户端B先调用 sync(), 再调用 getData()。

五、ZooKeeper对节点的watch监听是永久的吗？为什么？

不是。

官方声明：一个Watch事件是一个一次性的触发器，当被设置了Watch的数据发生了改变的时候，则服务器将这个改变发送给设置了Watch的客户端，以便通知它们。

为什么不是永久的，举个例子，如果服务端变动频繁，而监听的客户端很多情况下，每次变动都要通知到所有的客户端，这太消耗性能了。

一般是客户端执行getData(“/节点A”,true)，如果节点A发生了变更或删除，客户端会得到它的watch事件，但是在之后节点A又发生了变更，而客户端又没有设置watch事件，就不再给客户端发送。

在实际应用中，很多情况下，我们的客户端不需要知道服务端的每一次变动，我只要最新的数据即可。

六、ZooKeeper中使用watch的注意事项有哪些？

使用watch需要注意的几点：

  1. Watches通知是一次性的，必须重复注册
  2. 发生CONNECTIONLOSS之后，只要在session_timeout之内再次连接上（即不发生SESSIONEXPIRED），那么这个连接注册的watches依然在。
  3. 节点数据的版本变化会触发NodeDataChanged，注意，这里特意说明了是版本变化。存在这样的情况，只要成功执行了setData()方法，无论内容是否和之前一致，都会触发NodeDataChanged。
  4. 对某个节点注册了watch，但是节点被删除了，那么注册在这个节点上的watches都会被移除。
  5. 同一个zk客户端对某一个节点注册相同的watch，只会收到一次通知。
  6. Watcher对象只会保存在客户端，不会传递到服务端。

七、能否收到每次节点变化的通知？ 

如果节点数据的更新频率很高的话，不能。

原因在于：当一次数据修改，通知客户端，客户端再次注册watch，在这个过程中，可能数据已经发生了许多次数据修改，因此，千万不要做这样的测试：“数据被修改了n次，一定会收到n次通知”来测试server是否正常工作。

八、能否为临时节点创建子节点？

ZooKeeper中不能为临时节点创建子节点，如果需要创建子节点，应该将要创建子节点的节点创建为永久性节点。

九、是否可以拒绝单个IP对ZooKeeper的访问？如何实现？

ZK本身不提供这样的功能，它仅仅提供了对单个IP的连接数的限制。你可以通过修改iptables来实现对单个ip的限制。

十、ZooKeeper集群中服务器之间是怎样通信的？

Leader服务器会和每一个Follower/Observer服务器都建立TCP连接，同时为每个F/O都创建一个叫做LearnerHandler的实体。LearnerHandler主要负责Leader和F/O之间的网络通讯，包括数据同步，请求转发和Proposal提议的投票等。Leader服务器保存了所有F/O的LearnerHandler。

十一、ZooKeeper是否会自动进行日志清理？如何进行日志清理？

ZooKeeper自己不会进行日志清理，需要运维人员进行日志清理。

十二、谈谈你对ZooKeeper的理解？ 

Zookeeper作为一个分布式的服务框架，主要用来解决分布式集群中应用系统的一致性问题。ZooKeeper提供的服务包括：分布式消息同步和协调机制、服务器节点动态上下线、统一配置管理、负载均衡、集群管理等。

ZooKeeper提供基于类似于Linux文件系统的目录节点树方式的数据存储，即分层命名空间。Zookeeper并不是用来专门存储数据的，它的作用主要是用来维护和监控你存储的数据的状态变化，通过监控这些数据状态的变化，从而可以达到基于数据的集群管理，ZooKeeper节点的数据上限是1MB。

我们可以认为Zookeeper=文件系统+通知机制，对于ZooKeeper的数据结构，每个子目录项如NameService 都被称作为znode，这个znode是被它所在的路径唯一标识，如 Server1 这个 znode 的标识为 /NameService/Server1；

znode可以有子节点目录，并且每个 znode 可以存储数据，注意 EPHEMERAL 类型的目录节点不能有子节点目录（因为它是临时节点）；

znode是有版本的，每个znode中存储的数据可以有多个版本，也就是一个访问路径中可以存储多份数据；

znode可以是临时节点，一旦创建这个znode的客户端与服务器失去联系，这个znode也将自动删除，Zookeeper的客户端和服务器通信采用长连接方式，每个客户端和服务器通过心跳来保持连接，这个连接状态称为session，如果znode是临时节点，这个session 失效，znode也就删除了；

znode的目录名可以自动编号，如 App1 已经存在，再创建的话，将会自动命名为 App2；

znode可以被监控，包括这个目录节点中存储的数据的修改，子节点目录的变化等，一旦变化可以通知设置监控的客户端，这个是 Zookeeper 的核心特性，Zookeeper 的很多功能都是基于这个特性实现的，后面在典型的应用场景中会有实例介绍。

十三、ZooKeeper节点类型？

1、Znode有两种类型

  • 短暂（ephemeral）：客户端和服务器端断开连接后，创建的节点自己删除 。
  • 持久（persistent）：客户端和服务器端断开连接后，创建的节点不删除 。

2、Znode有四种形式的目录节点（默认是persistent ）

2.1、持久化目录节点（PERSISTENT）

客户端与zookeeper断开连接后，该节点依旧存在 。

2.2、持久化顺序编号目录节点（PERSISTENT_SEQUENTIAL）

客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号 。

2.3、临时目录节点（EPHEMERAL）

客户端与zookeeper断开连接后，该节点被删除 。

2.4、临时顺序编号目录节点（EPHEMERAL_SEQUENTIAL）

客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号。

十四、请说明ZooKeeper的通知机制？ 

ZooKeeper选择了基于通知（notification）的机制，即：客户端向ZooKeeper注册需要接受通知的znode，通 过znode设置监控点（watch）来接受通知。监视点是一个单次触发的操作，意即监视点会触发一个通知。为了接收多个通知，客户端必须在每次通知后设置一个新的监视点。在下图阐述的情况下，当节点/task发生变化时，客户端会受到一个通知，并从ZooKeeper读取一个新值。

十五、ZooKeeper的监听原理是什么？ 

在应用程序中，mian()方法首先会创建zkClient，创建zkClient的同时就会产生两个进程，即Listener进程（监听进程）和connect进程（网络连接/传输进程），当zkClient调用getChildren()等方法注册监视器时，connect进程向ZooKeeper注册监听器，注册后的监听器位于ZooKeeper的监听器列表中，监听器列表中记录了zkClient的IP，端口号以及要监控的路径，一旦目标文件发生变化，ZooKeeper就会把这条消息发送给对应的zkClient的Listener() 进程，Listener进程接收到后，就会执行process()方法，在process()方法中针对发生的事件进行处理。

十六、请说明ZooKeeper使用到的各个端口的作用？ 

2888：Follower与Leader交换信息的端口。

3888：万一集群中的Leader服务器挂了，需要一个端口来重新进行选举，选出一个新的Leader，而这个端口就是用来执行选举时服务器相互通信的端口。

十七、ZooKeeper的部署方式有哪几种？集群中的角色有哪些？集群最少需要几台机器？

ZooKeeper的部署方式有单机模式和集群模式，集群中的角色有Leader和Follower，集群最少3（2N+1）台，根据选举算法，应保证奇数。

十八、ZooKeeper集群如果有3台机器，挂掉一台是否还能工作？

对于ZooKeeper集群，过半存活即可使用。

十九、ZooKeeper使用的ZAB协议与Paxo算法的异同？

Paxos算法是分布式选举算法，Zookeeper使用的 ZAB协议（Zookeeper原子广播），两者的异同如下：

1、相同之处：

比如都有一个Leader，用来协调N个Follower的运行；Leader要等待超半数的Follower做出正确反馈之后才进行提 案；二者都有一个值来代表Leader的周期。

2、不同之处：

ZAB用来构建高可用的分布式数据主备系统（Zookeeper），Paxos是用来构建分布式一致性状态机系统。

二十、请谈谈对ZooKeeper对事务性的支持？

ZooKeeper对于事务性的支持主要依赖于四个函数，zoo_create_op_init， zoo_delete_op_init， zoo_set_op_init 以及zoo_check_op_init。每一个函数都会在客户端初始化一个operation，客户端程序有义务保留这些operations。 当准备好一个事务中的所有操作后，可以使用zoo_multi来提交所有的操作，由zookeeper服务来保证这一系列操作 的原子性。也就是说只要其中有一个操作失败了，相当于此次提交的任何一个操作都没有对服务端的数据造成影响。 Zoo_multi的返回值是第一个失败操作的状态信号。

  • 📢博客主页：https://lansonli.blog.csdn.net
  • 📢欢迎点赞 👍 收藏 ⭐留言 📝 如有错误敬请指正！
  • 📢本文由 Lansonli 原创，首发于 CSDN博客🙉
  • 📢停下休息的时候不要忘了别人还在奔跑，希望大家抓紧时间学习，全力奔赴更美好的生活✨

以上是关于高频面试题 ----------JVM调优的主要内容，如果未能解决你的问题，请参考以下文章

大数据面试题：ZooKeeper核心高频面试题

大数据面试题：Hadoop的联邦机制核心高频面试题

LinkedHashMap实现LRU算法--高频面试题

阿里面试必备：100个高频Spring面试题，助你一臂之力！

大数据面试题：Yarn核心高频面试题

高频面试题