migo_的专栏

本文详细记录了公司服务因连续Full GC后自动重启的排查过程。关键词：Java服务、Full GC、自动重启、OOM、元空间溢出、内存泄漏、自定义MyBatis代理。通过深入分析系统监控日志、排查启动命令与配置，最终定位问题为元空间大小限制导致的OOM，并发现自定义MyBatis代理可能引发内存泄漏。文章提供了解决方案，并强调了后续版本优化的重要性。

随着应用程序的复杂性和负载的不断增加，对JVM进行调优，也是保障系统稳定性的一个重要方向。需要注意，调优并非首选方案，一般来说解决性能问题还是要从应用程序本身入手（业务日志，慢请求等），只有在必要时才对jvm进行调优（gc日志和监控异常）。下面会提供一个线上案例，说明gc调优的重要性。

在Java中，对象的生命周期通常包括以下几个阶段，这些阶段与JVM的内存管理和垃圾收集机制密切相关。（1）：当使用new关键字或其他方式（如反射、克隆、反序列化等）创建一个对象时，JVM首先会在堆内存中为其分配相应的存储空间。（2）：在分配了内存空间后，JVM会调用对象的构造函数来初始化对象的实例变量。（3）：从超类到子类，对静态成员变量进行初始化。这通常是在类加载时完成的，而不是在对象创建时。（4）：首先递归调用超类的构造方法，对超类的成员变量进行初始化；

这种机制可以确保在垃圾收集过程中，对象间的引用关系不会发生变化，从而简化了垃圾收集的过程。然而，由于“Stop The World”会导致应用程序的短暂停顿，因此在一些对响应时间要求较高的应用中，可能需要考虑使用其他类型的收集器。在垃圾收集时，串行收集器会将Eden区和From区中存活的对象复制到To区，然后清空Eden区和From区。这个算法分为两个阶段：首先是标记阶段，收集器从根对象（如静态变量、常量等）开始，递归地访问对象的所有引用，并标记所有存活的对象；在新生代中，串行收集器主要使用。

应用程序有时会使用 finalization 和弱引用、软引用或虚引用与垃圾收集进行交互。然而，不鼓励使用 finalization。它可能会导致安全、性能和可靠性问题。例如，依赖 finalization 来关闭文件描述符会使外部资源（描述符）依赖于垃圾收集的及时性，这可能会带来问题。从JDK 9开始，finalization已经被废弃。而且据JEP 421：Deprecate Finalization for Removal规划，在JDK 18中将会被删除。

本章主要介绍，如果G1默认的一些配置无法满足你的需求，要如何进一步调优。

垃圾优先垃圾收集器面向多处理器机器，适用于大内存场景。它尝试在无需太多配置的情况下实现垃圾收集暂停时间目标，并同时实现高吞吐量。堆大小高达数十 GB甚至更大，超过50% 的Java堆内存用于存储活动数据G1 在应用程序运行时同时执行部分工作，它会利用处理器资源来缩短收集暂停，这一点最为显著。这主要体现在应用程序运行时会有一个或多个垃圾回收线程处于活动状态。因此，与吞吐量收集器相比，尽管使用 G1 收集器时垃圾回收暂停通常要短得多，但应用程序的吞吐量也往往稍微降低。

并行收集器（此处也称为吞吐量收集器）是类似于串行收集器的分代收集器。串行和并行收集器之间的主要区别在于并行收集器具有多个线程，用于加速垃圾回收过程。通过命令行选项-XX:+UseParallelGC 可启用并行收集器。默认情况下，使用此选项，较小和较大的垃圾回收都会并行运行，以进一步减少垃圾回收开销。

影响垃圾回收性能的两个最重要因素是总可用内存和分配给年轻代的堆内存比例。

Java SE 平台的一个优势是，它使开发人员免去了内存分配和垃圾收集的复杂性。然而，当垃圾收集成为主要的瓶颈时，了解实现的一些方面是很有用的。垃圾收集器对应用程序使用对象的方式做出假设，这些假设反映在可调参数中，这些参数可以在不牺牲抽象能力的情况下进行调整以提高性能。

垃圾收集器（GC）会自动管理应用程序的动态内存分配请求。

在实际生产环境运行过程中，我们时不时会遇到，服务假死、接口无响应等服务器问题。这时我们通过grafana平台，可以看到cpu或者内存不断告警，是接口并发数过多，还是应用系统出现bug？我们没有那么多时间一一排查，这时我们唯一能做的就是赶紧重启让服务恢复正常。但回过头来，我们也会想，为什么突然会有这个问题，如果以后再发现我们要怎么排查呢？