JVM面试题总结（题目来源JavaGuide）

wanghao6664552025-02-07 21:47

问题1：运行时数据区中包含哪些区域？哪些线程共享？哪些线程独享？哪些区域可能会出现 OutOfMemoryError？哪些区域不会出现OutOfMemoryError?

jdk1.8之前

jdk1.8之后

线程私有的：程序计数器、虚拟机栈、本地方法栈

线程共享的：堆、方法区、直接内存 (非运行时数据区的一部分)

问题2：说一下方法区和永久代的关系

在JVM中，方法区（Method Area） 和 永久代（PermGen） 都用于存储类的元数据、常量池等信息，但它们的定义和实现有所不同。这里是它们的关系和区别：

  1. 方法区（Method Area）：

  • 定义：方法区是JVM规范中规定的一块内存区域，用于存储所有类的元数据（如类名、方法、字段、常量池等信息）、静态变量和JVM运行时常量池。它是JVM运行时数据区的一部分，且所有线程共享。

  • 作用：存储每个类的结构信息，方法区是JVM的运行时数据区的组成部分，所有的类信息和常量池都存放在这里。方法区主要用于类加载过程中的类信息存储以及运行时常量池的管理。

  1. 永久代（PermGen）：

  • 定义：永久代是JVM HotSpot实现中，用于表示方法区的一部分。它是方法区的一个内存区域，专门用于存放类的元数据（如类的结构、常量池等）。

  • 作用：永久代存储的是JVM的运行时数据区中的类信息、方法、字段、常量池以及静态变量等。它通常位于堆之外的内存空间。

  • 特点 ：永久代的大小是固定的，用户可以通过JVM参数调整其大小。如果永久代空间不足，JVM会抛出 java.lang.OutOfMemoryError: PermGen space 异常。

  1. 方法区与永久代的关系：

  • 在 Java 7 及之前的版本中，方法区和永久代是紧密相关的，永久代是方法区的具体实现。永久代用于存放类的元数据、常量池等内容，是方法区的一部分。

  • 在 Java 8 之后，永久代被 Metaspace 替代。Metaspace不再位于JVM堆内存中，而是使用本地内存（Native Memory）。Metaspace的大小不再由-XX:PermSize和-XX:MaxPermSize参数进行控制，而是默认动态扩展。

问题3：Java 对象的创建过程。

  1. 类加载：

  • 在创建对象之前，JVM首先需要加载对应的类。类的加载是通过 类加载器（ClassLoader） 来完成的。加载过程包括从类路径加载类的字节码文件，读取类的元数据（如类名、字段、方法等），并将它们放入方法区中。

  • 如果该类之前没有被加载过，那么会触发类加载机制，直到类加载完毕，才可以创建该类的对象。

  1. 分配内存空间：

  • 堆内存分配：创建对象时，JVM会在堆内存中分配足够的空间来存储该对象。对象的内存空间大小由该对象的实例变量决定（即类的字段）。

  • 这时，JVM会使用一种叫 对象分配算法 的方法来选择合适的内存区域，并通过堆的内存管理（如新生代、老年代等）来完成对象的分配。

  1. 初始化默认值：

  • 在内存分配完成后，JVM会为对象的实例变量分配默认值。例如，数值类型会被初始化为 0，布尔类型为 false，引用类型（如对象、数组）为 null。

  • 这些默认值与类定义中的实例变量的初始值无关，因为这些初始值还未被赋予。

  1. 调用构造函数（Constructor）：

  • 在分配内存并初始化默认值之后，JVM会调用类的构造函数来初始化对象。构造函数的执行顺序如下：

    1. 调用父类构造函数：如果有父类，会先执行父类的构造函数。若父类没有显式的构造函数，则会调用父类的默认构造函数（无参构造函数）。

    2. 初始化当前类的字段：在调用构造函数时，会按照定义的顺序对类的实例变量进行初始化。如果构造函数有参数，会根据传入的参数来赋值。

    3. 执行构造函数体内的代码：构造函数中的其他代码（如初始化对象字段、执行方法等）会被执行。

  1. 对象初始化完成：
  • 当构造函数执行完成，整个对象的初始化就完成了。此时，对象可以在代码中被使用。对象的引用会指向该内存中的位置。
  1. 返回对象的引用：
  • 对象的创建过程中，Java会返回一个指向该对象的引用。这个引用可以在程序中用于访问对象的字段、调用对象的方法等。
  1. 垃圾回收与内存管理：
  • 在对象的生命周期结束时（即没有任何引用指向该对象时），JVM的垃圾回收机制会负责回收该对象的内存空间。

问题4：对象的访问定位的两种方式知道吗？各有什么优缺点。

在Java中，对象的访问定位方式可以分为 句柄 （Handle）和 直接指针（Direct Pointer）两种方式。它们是实现对象访问时的两种不同策略，尤其与JVM内存管理相关。

  1. 直接指针（Direct Pointer）：

定义：直接指针是指通过内存地址直接访问对象。对象的引用变量保存了该对象在内存中的实际地址。通过该指针，可以直接访问对象的字段和方法。

实现方式：在Java的某些JVM实现中，当我们创建一个对象时，JVM会将对象的内存地址直接赋值给引用变量，从而实现对对象的访问。

优点：

  • 访问效率高：直接通过内存地址访问对象，不需要额外的间接计算或查找，速度非常快。

  • 简单明了：代码简洁，易于理解和使用。

缺点：

  • 对象管理较为简单：直接指针的方式使得对象之间的引用关系更加紧密，这可能导致内存管理方面的困难。例如，容易发生内存泄漏或循环引用问题。

  • 依赖实现细节：由于直接指针依赖于内存地址的实现，在某些情况下，如内存分配和管理策略发生变化时（如垃圾回收），会变得不太灵活。

  1. 句柄（Handle）：

定义：句柄是一种间接的访问方式，通过引入一个"句柄对象"来存储对象的实际内存地址或管理信息。对象的引用并不是直接指向对象本身，而是指向一个句柄对象，这个句柄对象再指向实际的对象。

实现方式：在这种方式下，JVM不会直接将对象的内存地址存储在引用变量中，而是存储一个句柄。这个句柄管理对象的实际内存地址以及相关的元数据。通过句柄访问对象时，实际上是通过句柄间接定位对象。

优点：

  • 灵活性高：句柄提供了更加灵活的对象管理方式，句柄可以帮助JVM管理内存、对象生命周期等，并且可以在对象生命周期结束后回收资源。

  • 支持更多特性：例如，通过句柄，可以实现对象的移动，或者在对象的引用关系中进行更多的控制（例如垃圾回收器的工作）。

  • 解耦：句柄使得对象的引用与对象本身的内存位置解耦，提高了对象管理的灵活性。

缺点：

  • 性能开销：使用句柄引入了间接访问的步骤，需要额外的查找或计算，从而会导致访问效率比直接指针略低。

  • 实现复杂度高：句柄增加了对象管理的复杂性，需要更多的内存来存储句柄对象，并且句柄的设计和管理需要更多的实现细节。

总结：

特性 直接指针（Direct Pointer） 句柄（Handle）
访问效率 高效，直接通过内存地址访问对象 稍低，间接通过句柄访问对象
内存管理 简单，直接引用对象，易产生内存泄漏 灵活，支持复杂内存管理和回收机制
设计复杂度 简单明了，代码易理解 实现复杂，需要处理句柄对象和内存管理
使用场景 适用于简单、性能敏感的场景 适用于需要灵活内存管理或更高级特性的场景

总结：

  • 直接指针适用于需要快速、简单的对象访问场景，通常能提供较高的性能，但在内存管理和对象生命周期管理上相对较弱。

  • 句柄适用于需要更复杂内存管理、更高灵活性的场景，能提供更好的对象生命周期控制，但会引入一定的性能开销和实现复杂度。

问题5：如何判断对象是否死亡（两种方法）。 讲一下可达性分析算法的流程。

在Java中，判断对象是否死亡（即是否可以被垃圾回收）通常使用 可达性分析算法 （Reachability Analysis）。判断一个对象是否死亡的核心思想是检查该对象是否能够通过某些路径从 GC Roots（垃圾回收根对象）可达。如果不可达，则该对象就会被认为是垃圾，可以被回收。以下是判断对象是否死亡的两种方法：

判断对象是否死亡的两种方法：

  1. 引用计数法（Reference Counting）：

  • 原理 ：每个对象都有一个计数器，记录有多少个引用指向该对象。当有一个新的引用指向该对象时，计数器加1；当引用离开作用域或被赋值为 null 时，计数器减1。当计数器为0时，说明该对象没有任何引用指向它，可以被垃圾回收。

  • 缺点：

    • 无法处理循环引用：如果对象之间相互引用（形成循环引用），即使它们已经没有外部引用指向它们，计数器仍然不为0，无法被回收。因此，引用计数法不能正确识别循环引用的对象。
  1. 可达性分析法（Reachability Analysis）：

  • 原理：通过一系列的根对象（GC Roots）开始，遍历所有可达的对象。如果一个对象不能通过GC Roots到达，则认为该对象是不可达的，也就是说，该对象可以被回收。

  • 优点：能够正确识别并处理循环引用，因此是现代JVM垃圾回收的主流方法。

可达性分析算法的流程：

可达性分析算法是基于 GC Roots（垃圾回收根对象）开始，检查所有对象是否可达。具体流程如下：

  1. GC Roots：

    • 定义：GC Roots 是一组可以作为起点的对象，通常包括：

      • 栈上的引用：当前线程中的栈帧中保存的对象引用。

      • 静态引用：类的静态字段所引用的对象。

      • JNI引用：本地方法（Native Method）中引用的对象。

      • 方法区的引用：类的元数据、常量池等信息所引用的对象。

    注意：GC Roots 是固定的对象集，不会被垃圾回收，因此它们是所有对象访问的起点。

  2. 遍历可达对象：

    • 从GC Roots开始，JVM会遍历所有对象的引用链，标记所有可达的对象。

    • 可达性：如果一个对象从GC Roots能够通过引用链访问到，那么该对象就是可达的。

    • 在遍历过程中，JVM会将所有可达的对象标记为"存活"对象，并跳过那些不可达的对象。

  3. 判断是否可达：

    • 在遍历过程中，如果某个对象无法从GC Roots访问到，即该对象不可达，那么该对象就是垃圾，可以被回收。

  4. 回收不可达对象：

    • 不可达对象：被认为不再使用的对象，通常会被垃圾回收。

    • 标记清除：JVM标记所有不可达对象，然后清除它们的内存。

    • 其他回收算法：如标记-清除、复制算法、标记-整理等，JVM会选择合适的垃圾回收算法来清理不可达对象的内存。

总结：

  • 引用计数法：通过维护每个对象的引用计数来判断其是否可回收，简单但无法处理循环引用。

  • 可达性分析法：通过GC Roots遍历所有对象的引用链来判断对象是否可达，适用于大多数JVM，并能处理循环引用。

可达性分析的流程：

  1. 从GC Roots开始，遍历所有可达对象。

  2. 标记所有可达的对象为"存活"。

  3. 未标记的对象即为不可达对象，认为它们是垃圾。

  4. 执行垃圾回收，回收不可达对象的内存。

问题6：堆空间的基本结构了解吗？什么情况下对象会进入老年代？

在JVM的内存管理中，堆空间是存储对象的主要区域。堆空间的基本结构一般由 年轻代（Young Generation） 和 老年代（Old Generation） 组成，此外，堆还包括一个 永久代（PermGen） 或 Metaspace（在Java 8及之后版本中）。下面是堆空间的基本结构和对象进入老年代的条件。

堆空间的基本结构

  1. 年轻代（Young Generation）：

    • 定义：年轻代是堆空间的一部分，主要存放新创建的对象。年轻代的主要特点是对象生命周期较短。

    • 组成：

      • Eden区：大多数新创建的对象都会先分配到Eden区。

      • From Survivor区和To Survivor区：这两个区用来存放从Eden区和其他区复制过来的对象。每次垃圾回收时，对象会从一个Survivor区复制到另一个Survivor区，或者复制到老年代。

    • 特点：

      • 年轻代的垃圾回收叫做 Minor GC，通常比较频繁，但回收的对象大多是短生命周期的，回收效率较高。

  2. 老年代（Old Generation）：

    • 定义：老年代是堆空间的另一部分，主要存放存活时间较长的对象。当一个对象经过多次垃圾回收仍然存活下来时，它会被晋升到老年代。

    • 特点：

      • 老年代的垃圾回收叫做 Major GC（或Full GC），通常较为耗时且影响较大，因为老年代的对象较多且生命周期较长。

      • 老年代相对于年轻代空间较大，并且回收频率低。

  3. 永久代（PermGen）/Metaspace：

    • 定义 ：在Java 7及之前版本中，永久代 用于存放类的元数据、方法区等信息；在Java 8及之后版本中，永久代被Metaspace取代，Metaspace位于本地内存（native memory）中，不再属于堆空间的一部分。

    • 特点：永久代或Metaspace不会参与常规的垃圾回收，只有在类的加载或卸载时才会进行清理。

对象进入老年代的条件

对象进入老年代的主要条件是其生命周期较长。通常，通过以下几种方式对对象进行晋升：

  1. 年龄（Tenuring）：

    • 在年轻代中，对象会经历多次垃圾回收。每次垃圾回收时，幸存的对象会被移动到Survivor区，并且它们的年龄（age）会增加。

    • 当对象在Survivor区的年龄达到一定值时，它将被晋升到老年代。

    • 默认阈值：JVM中有一个默认的年龄阈值（通常为15），当对象在年轻代中经历了多次GC并且年龄达到阈值时，它会被晋升到老年代。

  2. 对象大小：

    • 大对象通常会被直接分配到老年代，而不是年轻代。大对象指的是占用内存比较大的对象，比如长数组、大对象图等。JVM可以通过配置参数（例如 -Xmn）调整对象分配的策略。

  3. 晋升阈值（Promotion Threshold）：

    • JVM有一个配置参数 -XX:MaxTenuringThreshold 来设置对象晋升到老年代的阈值。当对象的年龄（Age）超过该值时，会被晋升到老年代。

    • 例如，-XX:MaxTenuringThreshold=15 表示对象经过15次Minor GC后才会晋升到老年代。

  4. Full GC后晋升：

    • 在某些情况下，老年代的空间不足时，JVM可能会进行 Full GC（Major GC），此时对象的晋升规则会进行调整，以便释放出更多的空间供新对象使用。

总结

  • 堆空间结构：

    • 年轻代 ：存放大多数新创建的对象。通过 Minor GC 回收。

    • 老年代 ：存放长生命周期的对象。通过 Major GC 或 Full GC 回收。

    • 永久代/Metaspace：存储类的元数据，Java 8后Metaspace使用本地内存。

  • 对象进入老年代的条件：

    1. 对象在年轻代存活多次，且年龄超过设定的阈值。

    2. 对象较大时，直接分配到老年代。

    3. 配置参数设置（如 -XX:MaxTenuringThreshold）控制对象的晋升条件。

问题7： 垃圾收集有哪些算法，各自的特点？

算法 优点 缺点
标记-清除算法 实现简单，能处理复杂引用关系 内存碎片，效率较低
复制算法 不产生碎片，效率较高 需要额外的内存，复制过程开销大
标记-整理算法 解决了碎片化问题 需要移动大量对象，可能产生较长的停顿时间
分代收集算法 提高回收效率，减少老年代GC次数 配置复杂，老年代回收可能停顿较长
增量收集算法 减少长时间的GC停顿 总回收时间可能增加，效率较低
并行收集算法 提高回收效率，适合多核处理器 需要更多CPU资源，可能影响其他程序
并发收集算法 低停顿时间，适合实时系统 性能开销较大，复杂性较高
G1垃圾回收器 控制停顿时间，适合大内存，适应性强 回收复杂，可能导致性能损失

问题8： 有哪些常见的 GC?谈谈你对 Minor GC、还有 Full GC 的理解。Minor GC 与 Full GC 分别在什么时候 发生？ Minor GC 会发生 stop the world 现象吗？

在JVM中，垃圾收集（GC）是自动管理内存的重要机制。不同的垃圾回收器（GC）会根据不同的垃圾收集算法来回收不再使用的对象，减少内存占用。以下是一些常见的GC类型，并对 Minor GC 和 Full GC 的理解进行了说明。

常见的GC类型

  1. Serial GC：

    • 这是最基础的垃圾回收器，适用于单核处理器。它采用单线程进行垃圾回收，处理过程简单，但是会导致较长的停顿时间。

    • 通常用于客户端应用或内存较小的设备。

  2. Parallel GC（吞吐量优先GC）：

    • 使用多线程来进行垃圾回收，适合多核处理器。主要目的是提高垃圾回收的吞吐量，减少垃圾回收所占的时间。

    • Parallel Old GC：用于老年代的垃圾回收，采用多线程并行处理。

  3. Concurrent Mark-Sweep (CMS) GC：

    • CMS GC旨在减少垃圾回收的停顿时间，通过并发和分阶段的标记清除过程，在应用程序线程执行时进行垃圾回收。

    • 特别适合对低延迟要求较高的应用。

  4. G1 GC（Garbage-First GC）：

    • G1垃圾回收器将堆划分为多个小的区域，通过优先回收垃圾最多的区域来尽量减少停顿时间，提供可预测的停顿时间。

    • G1是目前常用的默认垃圾回收器（在JVM 9及之后版本中），适用于大内存和高并发的应用。

Minor GC 与 Full GC 的理解

Minor GC（年轻代垃圾回收）

  • 发生时机：

    • Minor GC 发生在 年轻代 （Young Generation）内存空间不足时。当年轻代的 Eden区 被填满且发生垃圾回收时，会触发Minor GC。回收的主要目的是回收 年轻代 中不再使用的对象。

    • 在 Minor GC 过程中，存活的对象会被移动到 Survivor区 ，如果它们在经过几次回收后依然存活，则会被晋升到 老年代。

  • 停顿时间：

    • Minor GC 会导致 Stop-The-World 现象，即在垃圾回收进行时，所有应用程序线程都会暂停执行，直到GC完成。

    • 尽管Minor GC的停顿时间通常较短，但它仍然会引起应用程序的暂停，特别是在年轻代的空间较小、对象较多时，可能会造成频繁的停顿。

  • 触发条件：

    • Eden区内存不足。

    • GC频率与年轻代的大小、应用程序创建对象的速率有关。

  • 是否会发生 Stop-The-World：

    • 会，Minor GC 发生时，所有应用程序线程都会暂停，直到垃圾回收完成。即使它的回收过程较短，仍会有停顿时间。

Full GC（老年代垃圾回收）

  • 发生时机：

    • Full GC 会在 老年代 （Old Generation）内存不足时触发，通常发生在以下情况：

      • 老年代空间不足，无法为新晋升的对象提供内存。

      • 当 Minor GC 无法清理足够空间时，JVM会尝试进行 Full GC，以释放老年代内存。

      • 在永久代（或Metaspace）内存不足时，也会触发 Full GC（在Java 8之前是永久代，Java 8之后是Metaspace）。

  • 停顿时间：

    • Full GC 会导致较长的 Stop-The-World 停顿时间，因为它需要标记和清理整个堆（包括年轻代和老年代），并且可能涉及大量的对象整理。

    • 在Full GC期间，JVM会回收老年代和永久代中的所有不可达对象，可能需要移动大量的对象，因此停顿时间通常较长。

  • 触发条件：

    • 老年代空间不足。

    • JVM内存回收策略的阈值调整，例如在大规模的对象被晋升到老年代时。

    • Metaspace 或 永久代 区域空间不足时（Java 8之前）。

  • 是否会发生 Stop-The-World：

    • 会 ，Full GC 也会导致 Stop-The-World 现象。由于需要回收整个堆（包括年轻代和老年代），所以回收过程通常需要暂停应用程序线程。

总结：Minor GC 与 Full GC 的区别

特性 Minor GC Full GC
回收区域 主要回收年轻代（Young Generation）。 回收整个堆，包括年轻代和老年代。
触发条件 年轻代空间不足，通常是 Eden 区满时触发。 老年代空间不足，或者 Metaspace/永久代空间不足。
停顿时间 相对较短，虽然会导致 Stop-the-World，但停顿时间较短。 通常较长，由于需要回收整个堆。
发生频率 频繁发生，通常是每当年轻代空间被填满时。 较少发生，通常发生在内存压力较大时。
回收策略 采用复制算法或其他年轻代专用算法。 采用标记-清除或标记-整理等算法。

Minor GC 是否会发生 Stop-The-World 现象？

是的，Minor GC 会发生 Stop-The-World 现象。无论回收的对象是年轻代的对象，还是老年代的对象，垃圾回收过程中都会暂停所有应用程序线程，直到垃圾回收完成。虽然Minor GC的停顿时间通常较短，但它仍会影响应用程序的实时性，尤其是在频繁发生时。为了减少停顿时间，可以通过调整年轻代的大小、使用不同的垃圾回收器（如G1）等手段来优化垃圾回收的效果。

问题9：讲一下 CMS 垃圾收集器的四个步骤。CMS 有什么缺点？

CMS（Concurrent Mark-Sweep）垃圾收集器 是JVM中的一种低停顿垃圾回收器，旨在减少垃圾回收的停顿时间，尤其是对那些要求低延迟的应用程序。CMS GC通过并发和分阶段的标记清除过程，在应用程序线程执行时进行垃圾回收。CMS的目标是尽量减少应用程序停顿的时间，并保证回收的效率。

CMS的四个步骤

CMS垃圾回收器的垃圾回收过程主要包括以下四个步骤：

  1. 初始标记阶段（Initial Mark）

    • 作用：在该阶段，CMS会标记所有根对象（GC Root）。根对象是程序中直接可以访问的对象，例如栈上的对象、静态变量、方法区中的类等。

    • 特点：

      • Stop-The-World：这个阶段是停顿应用程序的，因为需要暂停所有应用程序线程，确保能准确找到所有根对象。

      • 此阶段通常较短，只需要标记出所有可达的根对象。

  2. 并发标记阶段（Concurrent Mark）

    • 作用：在这个阶段，CMS会遍历堆中的所有对象，标记出所有可达的对象。通过并发的方式，它会在应用程序继续运行的同时标记对象。

    • 特点：

      • 并发进行：这个阶段并不需要停顿应用程序的线程，应用程序可以继续运行，只是会有一些CPU资源被用来标记对象。

      • 如果在此阶段内存中有新增的对象或者对象被修改，CMS也会实时标记。

  3. 重新标记阶段（Re-mark）

    • 作用：在并发标记阶段结束后，CMS会处理一些标记不完全的情况，确保所有的可达对象都被标记出来。

    • 特点：

      • Stop-The-World：与初始标记阶段一样，重新标记阶段需要暂停应用程序的线程。由于在并发标记阶段应用程序继续运行，可能有些对象的状态发生了变化，因此需要再次停顿并进行补充标记。

      • 这个阶段的停顿时间通常较短，主要是为了确保标记的准确性。

  4. 并发清理阶段（Concurrent Sweep）

    • 作用：在并发标记和重新标记阶段完成之后，CMS会并发地回收堆中那些不可达的对象，并释放其占用的内存。

    • 特点：

      • 并发进行：与并发标记阶段一样，清理阶段也是在应用程序线程运行时并发执行，不会造成长时间的停顿。

      • 清理阶段会清理掉无用的对象，但并不会压缩堆中的内存空间，因此在某些情况下可能会导致堆中的内存碎片问题。

CMS的缺点

尽管CMS垃圾回收器旨在减少停顿时间，但它仍然存在一些缺点：

  1. 内存碎片问题

    • CMS使用 标记-清除 算法来回收不可达对象，但它不会进行内存整理（compact），这意味着老年代的内存可能会产生碎片。

    • 如果堆中的内存碎片过多，可能会导致JVM无法分配足够的连续内存给大对象，从而触发 Full GC。

  2. Full GC 的频繁发生

    • 在CMS中，老年代的回收采用的是标记-清除算法。由于不进行整理，可能会导致频繁的 Full GC（完全垃圾回收），从而影响系统性能。

    • Full GC 需要暂停所有应用程序线程，通常会造成较长的停顿时间，尤其是在老年代内存很大或者内存碎片严重时。

  3. 并发标记阶段的性能影响

    • 虽然 并发标记 阶段允许应用程序继续执行，但并发标记需要消耗额外的CPU资源。如果系统的CPU资源有限，可能导致标记过程的性能下降，影响应用程序的响应速度。

  4. 无法处理老年代的内存碎片

    • 如果CMS无法清理掉足够的内存，尤其是老年代内存较小、内存碎片较严重时，可能会触发 Full GC。而在Full GC时，整个应用程序会停止，这时可能会造成长时间的停顿。

  5. 对多核处理器的利用不充分

    • 在 CMS 中，并发标记和并发清理会并行执行，但在某些阶段（比如 初始标记 和 重新标记），仍然需要暂停应用程序线程。这个暂停时间可能较长，并且无法充分利用多核处理器的资源。

总结：CMS的优缺点

优点：

  • 低停顿：CMS的设计目标是尽量减少GC停顿时间，特别适用于需要低延迟的应用程序。

  • 并发执行：通过并发标记和清理，尽量减少了应用程序线程的暂停，提升了响应性。

缺点：

  • 内存碎片：不进行内存整理，可能导致堆空间碎片化，导致Full GC的发生。

  • Full GC停顿：在老年代内存不足时，CMS可能会触发Full GC，停顿时间较长。

  • 资源消耗：并发标记阶段需要消耗一定的CPU资源，如果系统资源有限，可能影响应用程序性能。

  • 复杂性高：对于大规模系统的垃圾回收调优比较复杂，可能需要精细配置。

问题10：并发标记要解决什么问题？并发标记带来了什么问题？如何解决并发扫描时对象消失问题？

并发标记 是垃圾回收过程中的一个重要环节，尤其是在 CMS（Concurrent Mark-Sweep）垃圾回收器 中。它旨在尽量减少停顿时间，但同时也带来了一些问题和挑战，尤其是在并发执行时。下面我将详细讲解并发标记要解决的问题、带来的问题以及如何解决并发扫描时对象消失的问题。

并发标记要解决的问题

并发标记的主要目标是减少垃圾回收时的 停顿时间 。在传统的 标记-清除 或 标记-整理 垃圾回收过程中，GC通常会停止应用程序线程（Stop-The-World），使得垃圾回收操作期间应用程序不能执行。并发标记阶段通过与应用程序的并发执行来标记对象，避免了在回收过程中应用程序长时间停顿的问题。

具体而言，并发标记的目标是：

  1. 避免长时间的停顿：通过并发标记，在回收的同时让应用程序线程继续执行。减少了长时间停顿对应用程序性能的影响，特别是对于需要低延迟的实时应用。

  2. 提高吞吐量：在垃圾回收期间允许应用程序继续执行，从而最大化 CPU 资源的利用，提升整体系统吞吐量。

并发标记带来的问题

尽管并发标记能够减少停顿时间，但它带来了一些新的挑战：

  1. 对象的变化问题：

    • 并发标记 是在应用程序线程继续运行的同时进行的。因此，在标记阶段，可能会有新的对象被创建，或者对象的引用关系可能发生变化（例如，某个对象被从堆栈上移除，或者某个对象的引用指向了一个新对象）。

    • 由于对象在并发标记时可能会发生变化（如对象被回收，或者引用被改变），这就导致了并发标记过程中的不确定性，可能导致部分对象被漏标或误标。

  2. 并发标记过程中对象消失的问题：

    • 在并发标记过程中，应用程序线程可能会修改对象的引用，导致原本应该标记为"可达"的对象在并发标记时被漏掉，或错误地标记为"不可达"。

    • 这种问题如果没有妥善处理，可能会导致垃圾回收器无法准确标记所有的存活对象，最终导致 内存泄漏 或 误回收（即将一些活跃的对象回收，导致应用程序出现异常）。

如何解决并发扫描时对象消失问题？

为了解决 并发扫描时对象消失 的问题，通常采用以下几种策略：

  1. 通过"卡表"机制（Card Marking）来处理对象的变化

  • 卡表（Card Table） 是一种优化技术，用来跟踪年轻代和老年代之间的引用关系。在CMS垃圾回收器中，卡表主要用于记录对象引用的修改情况。

  • 在并发标记阶段，CMS会记录哪些对象的引用发生了变化（例如，某个对象的引用从年轻代指向了老年代）。这个过程称为 卡片清理，它通过更新卡表来追踪哪些对象可能被修改了引用关系。

  • 卡表机制 可以解决对象在并发标记期间变化的问题。具体来说：

    • 如果对象的引用发生了变化（例如引用了其他对象），CMS会将这一变化记录在卡表中。

    • 在标记阶段，CMS会在扫描对象时检查卡表，确保没有遗漏任何因为引用变化而未被标记的对象。

  1. 通过"写屏障"（Write Barrier）来保证标记一致性

  • 写屏障 是另一种技术，用来保证在并发标记期间对象引用的一致性。写屏障的作用是在对象引用发生变化时，及时地将修改信息传递给垃圾回收器，以便在后续标记过程中处理这些变化。

  • 具体来说，当应用程序线程修改对象的引用时，写屏障会触发一个记录操作，将这种修改记录下来。这样，垃圾回收器可以在标记阶段重新检查这些被修改的对象，确保它们不会漏标或误标。

  1. 并发标记的重新标记（Re-mark）阶段

  • 在并发标记完成后，CMS会进行一个 重新标记（Re-mark）阶段。这个阶段会暂停应用程序线程，并修正并发标记期间漏掉或误标的对象。通过这种方式，可以确保并发标记的结果是准确的。

  • 重新标记 通过停止应用程序线程来确保标记的准确性。由于在并发标记过程中可能有些对象的引用关系发生了变化，因此需要通过重新标记来修正这些变化。

  1. 并发清理（Concurrent Sweep）
  • 在并发标记和重新标记之后，CMS会进行 并发清理，这时会回收那些已经标记为不可达的对象。由于并发标记的准确性较高（通过卡表和写屏障的机制），并发清理可以在不影响应用程序的情况下顺利进行。

总结

  • 并发标记 主要解决了垃圾回收过程中应用程序停顿时间过长的问题，允许应用程序在垃圾回收期间继续执行。

  • 然而，并发标记也带来了对象消失的问题，主要因为在并发标记期间，应用程序线程可能会修改对象的引用，导致一些对象的标记不准确。

  • 卡表机制 和 写屏障 是解决并发标记过程中对象引用变化问题的两种有效方法。通过这两种机制，垃圾回收器能够在并发标记期间追踪引用的变化，保证标记的准确性。

  • 在并发标记结束后，重新标记阶段会暂停应用程序线程，以修正并发标记期间可能遗漏或误标的对象，从而确保垃圾回收的正确性。

问题11：G1 垃圾收集器的步骤。有什么缺点？

G1垃圾收集器（Garbage-First Garbage Collector）是JVM中一种相对较新的垃圾回收器，旨在提供更可预测的停顿时间，并改进垃圾回收的效率，尤其适用于大内存应用。G1垃圾收集器在垃圾回收过程中将堆划分为多个小的区域（Region），并且通过并发和增量的方式来回收垃圾，优先回收垃圾最多的区域，从而实现低延迟的垃圾回收目标。

G1垃圾收集器的步骤

G1垃圾收集器的回收过程大致可以分为以下几个步骤：

  1. 初始标记阶段（Initial Mark）

    • 作用：在此阶段，G1会标记所有的GC根对象（根对象是程序中所有可达对象的入口点），类似于其他垃圾回收器的初始标记过程。

    • 特点：

      • Stop-The-World：这一阶段会停顿应用程序线程，确保能够准确标记所有可达的根对象。

      • 通常较短，因为它仅需要标记GC根对象。

  2. 并发标记阶段（Concurrent Mark）

    • 作用：G1开始并发标记整个堆中的所有可达对象。它会扫描堆中的所有对象并标记出哪些是可达的。这个阶段是与应用程序线程并发执行的，应用程序线程可以继续运行。

    • 特点：

      • 并发执行：与应用程序线程并行执行，不会造成长时间的停顿。

      • 通过并行的方式，G1可以快速遍历和标记堆中的对象。

  3. 最终标记阶段（Final Mark）

    • 作用：这一阶段修正并发标记期间未能标记的对象。由于并发标记阶段中，应用程序线程可能会修改对象的引用关系，导致某些对象未被标记。最终标记会确保所有存活对象都被标记。

    • 特点：

      • Stop-The-World：这一阶段需要暂停应用程序线程，进行最终的标记。

      • 该阶段停顿时间相对较短，通常用于完成并发标记后标记遗漏的对象。

  4. 垃圾回收阶段（Collection）

    • 作用：在这一阶段，G1会回收那些已标记为不可达的对象。回收过程会根据回收的区域优先回收垃圾最多的区域（即垃圾最多的Region）。

    • 特点：

      • G1通过将堆划分为多个区域（Region），根据不同的区域回收策略来选择垃圾回收的优先级。每次回收过程中，G1会优先回收那些包含最多垃圾的区域。

      • 并发回收：回收过程中会尽量减少停顿时间，尤其是在并发回收阶段，应用程序线程仍然可以执行。

  5. 整理阶段（Evacuation）

    • 作用：G1会对回收后的对象进行整理和压缩，确保堆空间没有碎片。这一阶段主要是将存活的对象迁移到新的区域，从而减少内存碎片。

    • 特点：

      • Stop-The-World：这一阶段通常需要暂停应用程序线程，因为对象需要移动到不同的内存区域。

      • G1通过整理来优化内存的使用，确保堆中存活的对象尽量位于相邻区域，减少碎片化。

G1垃圾收集器的缺点

尽管G1垃圾收集器比旧的垃圾回收器（如CMS）提供了更多的控制，并且对大内存系统和低延迟应用进行了优化，但它也有一些缺点和局限性：

  1. 复杂的调优：

    • G1垃圾收集器相对复杂，需要精细的调优才能达到最佳性能。特别是在大内存系统中，如何合理配置G1的内存区域划分、并发线程数等参数，可能会对回收效果和性能产生重大影响。

    • 对于内存和停顿时间的调节需要专业的监控和调优经验，否则可能无法充分发挥G1的优势。

  2. 可能较长的停顿时间：

    • 尽管G1的目标是减少停顿时间，并提供可预测的停顿，但在某些情况下，Final Mark阶段的停顿时间仍然可能较长，特别是在堆非常大的情况下，标记和整理过程可能需要更多的时间。

    • 在应用负载较高或垃圾回收区域不均衡的情况下，G1可能会出现较长的GC停顿，影响系统的响应性。

  3. 内存碎片问题：

    • G1垃圾回收器虽然能有效地管理堆内存，但在某些情况下，尤其是在大内存系统中，G1可能会面临内存碎片问题。尽管G1会尝试将存活的对象移到相邻区域，但在长时间运行后，堆中的内存碎片仍然可能影响性能。

    • 特别是在老年代回收时，内存碎片问题可能更加明显。

  4. 较高的内存开销：

    • G1将堆划分为多个小区域，并使用额外的内存结构来管理这些区域。这使得G1在内存开销上相较于其他垃圾回收器（如Serial或Parallel GC）要更高。

    • 额外的内存开销会影响系统的内存使用效率，特别是在内存较小的系统中。

  5. 回收过程的不确定性：

    • G1垃圾收集器的回收过程是基于回收优先级的，这可能导致一些Region的回收优先级较低，垃圾积累较多，最终可能导致某些区域出现长时间的停顿。

    • 在某些应用场景下，虽然G1的停顿时间通常较短，但由于回收过程的不可预见性，仍可能出现短时间内的高延迟现象。

总结：G1垃圾收集器的缺点

缺点 说明
调优复杂性 G1需要进行精细的调优，尤其是对大内存系统进行内存区域划分、线程数等设置，调优难度较大。
可能的较长停顿时间 在标记和整理阶段可能会有较长的停顿时间，特别是在堆非常大的情况下。
内存碎片问题 尽管G1有垃圾回收整理，但长时间运行后仍可能会出现内存碎片问题，影响系统性能。
较高的内存开销 G1将堆划分为多个小区域，可能导致额外的内存开销，特别是内存较小的系统。
回收过程的不确定性 回收过程中优先回收的区域可能导致某些区域积累垃圾，最终造成不可预见的停顿。

尽管G1垃圾收集器有这些缺点，它仍然是JVM中常用的垃圾回收器，尤其是在处理大内存和需要低延迟的应用时。在合适的调优下，G1能够在可控的停顿时间内实现高效的垃圾回收，确保系统的稳定性和性能。

问题12： ZGC 了解吗？

ZGC是JVM中的一种新型垃圾回收器，它通过极低的停顿时间和支持大内存的设计，适用于低延迟、高并发、大内存的应用场景。它的回收过程几乎是全并发的，并能够有效处理内存碎片问题，提供高效的垃圾回收机制。然而，作为相对较新的垃圾回收器，ZGC的调优和内存开销较大，需要根据实际需求进行精细配置。

问题13：JVM 中的安全点和安全区各代表什么？写屏障你了解吗？

概念 描述
安全点 JVM执行过程中，允许进行垃圾回收的时刻，线程会在此暂停，以便垃圾收集器可以安全地操作。
安全区 某些线程执行的代码区域可以安全地进行垃圾回收，而无需暂停线程。
写屏障 监控和处理对象引用修改的技术，确保在垃圾回收过程中，引用变化不会导致回收错误。
  • 安全点用于确保GC时线程可以停下来，避免GC过程中出现对象引用的不一致。
  • 安全区允许在某些代码区域并行执行GC，减少停顿时间。
  • 写屏障主要用于处理对象引用变化，确保并发垃圾回收能够正确地处理引用关系。

问题14：虚拟机基础故障处理工具有哪些？

  • jps：用于列出当前正在运行的Java进程，可以帮助快速查看JVM进程ID。
  • jstack：获取Java进程的线程堆栈信息，常用于诊断线程死锁和阻塞问题。
  • jmap：生成堆转储文件和查看堆内存使用情况，适用于内存泄漏分析。
  • jstat：实时监控JVM的垃圾回收和内存使用，帮助分析GC活动。
  • VisualVM：提供图形化界面，集成多种性能监控功能，帮助分析JVM性能、内存、线程等。

问题15：什么是字节码？类文件结构的组成了解吗？

在 Java 中，JVM 可以理解的代码就叫做字节码（即扩展名为 .class 的文件）。

问题16：类的生命周期？类加载的过程了解么？加载这一步主要做了什么事情？初始化阶段中哪几种情况必须对 类初始化？

类的生命周期

类的生命周期主要由类加载过程控制，从类加载开始，到类被卸载，类的生命周期经历了以下几个阶段：

  1. 加载（Loading） ：JVM根据类的全限定名（例如 com.example.MyClass）加载类的字节码（.class文件）。

  2. 链接（Linking）：

    • 验证（Verification）：验证字节码文件是否符合JVM的要求，保证其正确性和安全性。

    • 准备（Preparation） ：为类的静态变量分配内存，并将它们初始化为默认值（例如 null, 0 等）。

    • 解析（Resolution）：将类中的符号引用（例如类、方法、字段的引用）解析为直接引用（例如内存地址）。

  3. 初始化（Initialization）：对类的静态变量和静态代码块进行初始化。

  4. 使用（Usage）：类可以被实例化，方法可以被调用，程序正常运行。

  5. 卸载（Unloading）：当类不再被使用并且没有任何引用时，JVM会卸载类，释放其占用的内存。

类加载过程

类加载是指JVM根据类的全限定名（包括包名）加载类文件（.class文件），并将其转换为java.lang.Class对象。类加载的过程通常是由类加载器（ClassLoader）来完成的。加载过程大致可以分为以下几个步骤：

  1. 类加载器获取类的字节码：

    • JVM会通过类加载器（ClassLoader）查找指定类的字节码文件，通常字节码可以从以下地方获取：

      • Bootstrap ClassLoader：从JVM内置的类路径中加载基础类库。

      • Extension ClassLoader：从JVM的扩展目录加载类库。

      • Application ClassLoader：从应用程序的类路径（classpath）加载类库。

  2. 读取字节码文件：类加载器根据类名查找并读取字节码文件，存储在内存中。

  3. 验证（Verification）：JVM对字节码进行验证，确保其格式和内容符合JVM的规范，避免加载恶意的或损坏的类。

  4. 解析（Resolution）：在类的符号引用（例如类名、方法名）被转换为直接引用（内存地址）时，JVM会解析这些符号引用，建立类之间的引用关系。

  5. 初始化（Initialization）：当类的字节码成功加载、链接并解析之后，类就进入初始化阶段。

类加载的关键点

类加载主要做了以下几件事：

  1. 读取字节码文件：从磁盘或网络获取类的字节码。

  2. 验证字节码：验证类的字节码是否符合JVM的规范，确保它不会破坏JVM的安全性。

  3. 解析符号引用：将类文件中使用的符号引用解析为实际的内存地址引用。

  4. 初始化类的静态变量：为类分配内存并初始化静态变量。

  5. 调用静态代码块：执行类的静态初始化代码块（如果有的话）。

**问题17： 双亲委派模型了解么？如果我们不想用双亲委派模型怎么办？**双亲委派模型有什么好处？双亲委派模型是为了保证一个 Java 类在 JVM 中是唯一的？

方案 破坏双亲委派的方法 适用场景
自定义 ClassLoader，重写 loadClass() 直接修改 ClassLoader 的加载逻辑，不再委派给父类 插件加载、动态代理
使用 Thread.setContextClassLoader() 修改线程的上下文类加载器 SPI 机制（JDBC、Tomcat、OSGi）
使用 defineClass() 直接加载类字节码，绕过父类委派 动态代码生成（Javassist、ASM）

✅ 问：为什么 Java 使用双亲委派机制？

  • 避免类的重复加载
  • 保护核心类库安全
  • 提高加载效率

✅ 问：如何破坏双亲委派？

  • 重写 loadClass()
  • 修改 Thread.setContextClassLoader()
  • 使用 defineClass() 手动加载类

✅ 问：哪些场景下需要破坏双亲委派？

  • 动态类加载（热部署）（如 Tomcat、Spring Boot）
  • SPI 机制（JDBC、ServiceLoader）
  • 自定义插件加载（如 OSGi、JavaAgent）

双亲委派模型能否保证 Java 类的唯一性？

✅ 不一定能保证类的唯一性 ，但可以在同一个 ClassLoader 作用域内保证类的唯一性。

  • 双亲委派模型不能跨 ClassLoader 保证类的唯一性：

    • 例如，在 Tomcat 这样的 Web 容器 中，不同的 ClassLoader 可以加载 相同名称的类 ，它们在 JVM 中是不同的类。
java 复制代码 
ClassLoader loader1 = new MyClassLoader("/path/to/classes/");
ClassLoader loader2 = new MyClassLoader("/path/to/classes/");

Class<?> class1 = loader1.loadClass("MyClass");
Class<?> class2 = loader2.loadClass("MyClass");

System.out.println(class1 == class2); // false

问题18：JDK 中有哪些默认的类加载器？

类加载器 作用 加载路径 继承 ClassLoader
BootstrapClassLoader 加载 JDK 核心类库 $JAVA_HOME/lib/ 或 -Xbootclasspath ❌（C++实现）
ExtClassLoader 加载 JDK 扩展类库 $JAVA_HOME/lib/ext/ 或 -Djava.ext.dirs ✅
AppClassLoader 加载 应用程序类 classpath（开发者代码） ✅

问题19：堆内存相关的 JVM 参数有哪些？你在项目中实际配置过了吗？

优化点 推荐参数
固定堆大小 -Xms8g -Xmx8g
调整新生代 -Xmn4g -XX:NewRatio=2 -XX:SurvivorRatio=8
使用合适的 GC -XX:+UseG1GC（高吞吐）或 -XX:+UseZGC（低延迟）
OOM 诊断 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dump
GC 日志 -XX:+PrintGCDetails

问题20：如何对栈进行参数调优？

（1）设置单个线程栈的大小

参数 作用
-Xss<size> 每个线程的栈大小（默认 1MB）

示例：

bash 复制代码 
java -Xss512k MyApplication
  • -Xss512k：设置 单个线程的栈大小为 512KB（默认 1MB）。
  • 影响：
    • 减小 -Xss 值 ➝ 可以创建更多线程（适用于高并发）。
    • 增大 -Xss 值 ➝ 可以支持更深的递归或更大的局部变量（适用于深度递归算法）。

（2）调整 JVM 最大线程数量

参数 作用
ulimit -s 查看 / 设置 Linux 线程栈大小
/proc/sys/kernel/threads-max 系统最大线程数
/proc/sys/vm/max_map_count 影响 JVM 可分配线程的上限

示例（Linux 查看线程栈大小）：

bash 复制代码 
ulimit -s

示例（调整最大线程数）：

bash 复制代码 
echo 100000 > /proc/sys/kernel/threads-max

问题21：你在项目中遇到过 GC 问题吗？怎么分析和解决的？

📌 GC 问题常见表现

GC 可能导致的 问题 主要有：

  1. GC 频繁导致 CPU 飙升（Full GC 过于频繁）

  2. GC 停顿时间过长（影响用户请求响应）

  3. 内存溢出（OOM） （OutOfMemoryError）

  4. 对象回收缓慢导致内存膨胀（老年代占用过高）

案例 1：Full GC 过于频繁，导致应用卡顿

🚨 现象

  • 线上 Java 服务在高并发请求时，CPU 使用率突然飙升，然后短暂恢复，过一会儿又复现。

  • 通过 jstat -gcutil <pid> 1000 监控 GC 频率异常高：

    bash 复制代码 
    S0     S1     E      O      M     CCS   YGC    YGCT   FGC    FGCT     GCT
0.00  85.34  90.23  75.45  80.12  70.67  12988  124.5   1023   425.3   549.8

    • FGC（Full GC 触发次数）远高于预期

    • O（Old Gen）使用率 75.45% 说明老年代占用过高

    • E（Eden）使用率 90.23% 说明年轻代对象分配很快

🔍 问题分析

  1. 老年代占用高，频繁触发 Full GC

    • 可能是大对象直接进入老年代

    • 或者对象晋升到老年代过快

  2. Eden 区满了，导致 Minor GC 频繁

    • 说明短生命周期对象过多

  3. 元空间（Metaspace）使用率高

    • 可能存在类加载泄漏

💡 解决方案

1.增大新生代，减少对象快速进入老年代

bash 复制代码 
-XX:NewRatio=2   # 新生代和老年代的比例调整为 1:2
-XX:SurvivorRatio=8  # Eden:Survivor 调整为 8:1:1

2.避免大对象直接进入老年代

bash 复制代码 
-XX:PretenureSizeThreshold=10M  # 大于 10MB 的对象直接进入老年代

3.减少 Full GC 频率

bash 复制代码 
-XX:+UseG1GC  # 使用 G1 垃圾回收器（低延迟）
-XX:MaxGCPauseMillis=200  # 控制 GC 停顿时间（200ms 内）

案例 2：内存溢出（OutOfMemoryError: Java heap space）

🚨 现象

  • 线上服务 运行一段时间后崩溃 ，日志报 java.lang.OutOfMemoryError: Java heap space

  • 使用 jmap -histo:live <pid> 查看堆内存：

    bash 复制代码 
    num     #instances    #bytes    class name
----------------------------------------------
1:      1245000       198000000  java.lang.String
2:       784210       123452000  [Ljava.lang.Object;
3:       560120        78502400  java.util.HashMap$Node

    • String 占用 198MB

    • HashMap$Node 占用 78MB

    • Object[] 占用 123MB

🔍 问题分析

  • String 对象数量太多，且不可回收

  • HashMap$Node 说明可能有 Map 过大或缓存泄漏

  • Object[] 说明可能数组数据未及时释放

💡 解决方案

  1. 优化 String 处理

    • String.intern() 让字符串进入字符串池，减少内存占用

    • 使用 StringBuilder 代替 String + 拼接

  2. 优化 HashMap

    • 检查是否有 缓存未清理 （使用 WeakHashMap 或 SoftReference）

    • 限制缓存的最大大小（如 LinkedHashMap + LRU 策略）

  3. 调整 JVM 堆大小

    bash 复制代码 
    -Xms4g -Xmx4g -XX:+UseG1GC
    • 适当增大 堆空间，但避免过大导致 GC 延迟增加

案例 3：GC 停顿时间过长

🚨 现象

  • 应用请求延迟波动大 ，偶尔出现 长时间卡顿

  • GC log 发现 Full GC 发生时间过长（> 1s）

bash 复制代码 
[GC (Allocation Failure) Pause time: 2.356s]
  • jstat -gc <pid> 发现 老年代使用率高，FGC 触发频繁

🔍 问题分析

  • 长 GC 停顿说明 Stop-The-World（STW）时间长

  • 老年代使用率高 ➝ 可能是长生命周期对象未及时回收

  • 吞吐量下降 ➝ 可能是 GC 线程不足

💡 解决方案

  1. 减少 Full GC 触发
bash 复制代码 
-XX:+UseG1GC  # 使用 G1 垃圾回收器
-XX:MaxGCPauseMillis=100  # 目标 GC 停顿时间 100ms

2.增加 GC 线程

bash 复制代码 
-XX:ParallelGCThreads=8
-XX:ConcGCThreads=4

3.调整老年代回收策略

bash 复制代码 
-XX:G1MixedGCCountTarget=8  # 每次 Mixed GC 目标

问题22：GC 性能指标了解吗？调优原则呢？

  • GC 关键指标 ：
    • 吞吐量：减少 GC 对应用影响
    • 停顿时间：保证应用实时性
    • GC 频率：避免频繁 GC 影响性能
  • GC 调优原则 ：
    1. 减少 Full GC 触发
    2. 控制 GC 停顿时间
    3. 减少老年代占用
    4. 优化 GC 日志分析
  • 实际项目优化经验 ：
    • G1 GC + 低延迟配置 适用于高并发场景
    • Parallel GC 适用于高吞吐量系统
    • 合理的内存分配，减少 OOM

问题23： 如何降低 Full GC 的频率？

1. 增大堆内存及调整老年代大小

  • 问题：老年代内存不足，导致对象频繁晋升到老年代并触发 Full GC。

  • 解决方法：

    • 增大 老年代 （-Xmx），提供更多空间给长期存活的对象。

    • 调整 新生代与老年代的比例 ，增加 新生代 空间，减少对象过早晋升到老年代的机会。

bash 复制代码 
-Xmx4g -Xms4g -XX:NewRatio=3  # 新生代占总堆内存的 1/4，老年代占 3/4
-XX:SurvivorRatio=8  # 新生代 Eden 区和两个 Survivor 区的比例

2. 调整垃圾回收器及其参数

  • 问题：选择的垃圾回收器不适合当前的应用场景，导致 Full GC 频繁。

  • 解决方法：

    • 使用 G1 GC ，G1 GC 适用于长时间运行的应用，可以通过 分代管理 来减少 Full GC 的发生。
bash 复制代码 
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200  # 最大 GC 停顿时间 200ms

3. 减少对象晋升到老年代的频率

  • 问题：大量短生命周期的对象提前晋升到老年代，占用老年代空间，导致老年代空间紧张，最终触发 Full GC。

  • 解决方法：

    • 增大新生代空间，减少对象在新生代中存活的时间，从而减少晋升到老年代的对象数量。
bash 复制代码 
-XX:NewRatio=2  # 新生代占堆内存的比例为 1/3
-XX:MaxTenuringThreshold=15  # 控制短生命周期的对象在 Survivor 区的存活时间，避免它们过早晋升

4. 避免大对象直接进入老年代

  • 问题：大对象直接进入老年代会导致老年代迅速占满，进而触发 Full GC。

  • 解决方法：

    • 使用 -XX:PretenureSizeThreshold 设置大对象的阈值，避免它们直接进入老年代。
bash 复制代码 
-XX:PretenureSizeThreshold=10M  # 大于 10MB 的对象直接分配到老年代

5. 监控和优化内存分配

  • 问题：内存分配不合理，导致老年代空间被快速占满。

  • 解决方法：

    • 定期查看 堆内存分配情况，并调整对象分配策略。

    • 监控 GC 日志，通过 jstat 等工具查看 Full GC 的发生频率及内存分配情况。

6. 使用内存池（Metaspace）优化

  • 问题：类的加载和卸载导致内存碎片，影响老年代的回收，导致 Full GC。

  • 解决方法：

    • 调整 Metaspace（类元数据空间）大小，避免频繁的类加载和卸载。
bash 复制代码 
-XX:MetaspaceSize=256m  # 初始化 Metaspace 大小
-XX:MaxMetaspaceSize=1g  # 设置最大 Metaspace 大小

7. 分析 Full GC 日志

  • 问题：没有及时发现并处理 Full GC 问题，导致应用出现性能下降。

  • 解决方法：

    • 开启 GC 日志，分析 Full GC 的原因，并做相应的优化。
bash 复制代码 
-Xloggc:/path/to/gc.log  # 配置 GC 日志文件路径
-XX:+PrintGCDetails  # 打印详细的 GC 信息
-XX:+PrintGCDateStamps  # 打印 GC 时间戳
相关推荐
半聋半瞎3 分钟前
【进程和线程】（面试高频考点）
java·jvm·面试
功德+n15 分钟前
在 Maven 中使用 ＜scope＞ 元素：全面指南
java·maven
Java_young25 分钟前
(十七) Nginx解析：架构设计、负载均衡实战与常见面试问题
nginx·面试·负载均衡
枣仁_30 分钟前
大型语言模型（LLM）深度解析
前端·javascript·面试
失业写写八股文34 分钟前
Java类加载阶段深度解析：三步走全流程详解
java
鱼樱前端39 分钟前
36道我命由我不由天的JavaScript 基础面试题详解
前端·javascript·面试
yyueshen42 分钟前
单例模式，有必要用volatile么？
java·单例模式·设计模式
阿卡好可爱42 分钟前
锐势信息的面试
面试·职场和发展
一条闲鱼_mytube43 分钟前
[Kubernetes] 7控制平面组件
java·平面·kubernetes
Y雨何时停T1 小时前
Spring IoC 详解
java·spring·rpc
热门推荐
01如何在WPS和Word/Excel中直接使用DeepSeek功能02DeepSeek各版本说明与优缺点分析03本地部署DeepSeek教程（Mac版本）04从零安装 LLaMA-Factory 微调 Qwen 大模型成功及所有的坑05DeepSeek R1本地化部署 Ollama + Chatbox 打造最强 AI 工具06保姆级教程：利用Ollama与Open-WebUI本地部署 DeedSeek-R1大模型07DeepSeek RAGFlow构建本地知识库系统08Windows 11 安装 Dify 完整指南 非docker环境09DeepSeek r1本地安装全指南10本地化部署AI知识库：基于Ollama+DeepSeek+AnythingLLM保姆级教程