# 一、引言在软件开发领域中，**稳定性**和**性能**始终是开发者的首要关注点。特别是在Java世界中，内存管理**无疑是一个重要的话题，尤其当涉及到内存溢出的问题时。这种情况不仅可能导致**应用的崩溃，还可能导致系统的整体**性能大幅下滑**。对于Java开发者来说，仅仅理解**JVM的内存结构**是不够的。更为重要的是，我们需要有实战经验和应对策略来避免这些问题。这些往往也是面试官喜欢切入的地方。本文的目的正是为了深入挖掘JVM常出现的问题，解析其背后的原因，并提供实际的解决方案和技巧，话不多说，我们开始吧\~ *** `性能监控经常成为预防生产事故的得力助手，在打出一套检验你故障排查能力连招之前，往往会先试探性的探查你对性能监控的熟练掌握程度。接下来，我们看看应该怎么回答这类问题。` # 二、性能监控 > :man:面试官：你们公司怎么做性能监控？生产出现问题怎么办 > :boy:候选者：看下Tomcat日志，把日志拿出来.... > :man:面试官：？停停停....我们公司可能不太适合你分布式，微服务大环境大行其道，只用肉眼24小时盯着机器的时代过去了。为了保证服务的持续可用性和高性能，现代公司已经转向了自动化的、全面的监控方案。它是内需，也是一个**产品**，用于鉴别大型公司和小型公司的指标之一。选择一套合适的监控工具和策略不仅可以及时发现和解决问题，还能为未来的系统优化提供**有价值的数据**。排除一些在"自研"方向越走越远的公司。常见的性能监控解决方案如下： 1. 数据收集: 使用 Spring Cloud Sleuth 为微服务中的每一个请求生成追踪数据，确保我们能够清晰地看到请求在整个系统中的流动路径。 2. 数据存储与可视化: Zipkin 在这里起到了关键作用，它不仅接收和存储由Sleuth生成的追踪数据，还提供了一个直观的界面来可视化这些数据，帮助我们快速定位性能瓶颈或错误。 3. 指标监控: 我们使用 Prometheus 来收集各种系统和应用指标，包括但不限于CPU、内存、磁盘、网络，以及业务相关的指标。 4. 数据展示: Grafana 与 Prometheus 无缝集成，为我们提供了一个强大的、定制化的仪表板，显示关键指标的实时数据。当某些指标超出正常范围时，Grafana也可以触发警报。 5. 警报: 通过 Prometheus的 Alertmanager，我们可以定义自己的警报规则，并决定如何通知相关团队——是通过邮件、微信机器人还是其他方式。限于篇幅，我在这里就不过多展示，将在后续文章中为你介绍。现在会造火箭了吗？咳咳...会说了吗？ > :boy: 候选者：我们采用了一套开源的微服务监控方案，涉及追踪数据收集、数据存储与可视化、系统与应用指标监控、数据展示，以及警报管理。具体地，我们使用Spring Cloud Sleuth为每个微服务请求生成追踪数据；再用Zipkin来接收、存储并可视化这些数据。对于系统和应用指标，我们采用Prometheus进行收集，并通过Grafana进行展示和仪表板创建。当指标达到某些阈值时，我们的Prometheus Alertmanager会发送警报，通知相关团队采取行动。 > :man: 面试官：很好，这样的方案确保了性能问题能够被及时发现和定位，对于生产环境的稳定性至关重要。🤝 *** # 三、MAT使用指南 > :man:面试官：生产上出现OOM你怎么解决的？ > :boy:候选者：远程DEBUG一下，看下哪里报错呗 > :man:面试官：（上个用远程DEBUG的公司坟头都长草了吧）？回去等通知 **工欲善其事，必先利其器**。生产的绝大部分问题，都没办法像本地一样方便，例如内存快照，DEBUG断点，随意压测等等去复现问题。往往需要通过你同事辅助保留现场，遇到一些没办法通过日志和监控问题的时候把一些信息DUMP出来，通过工具进行分析。 ## Memory Analyzer下载把大象关进冰箱要几步？少侠，我这里也需要三步，不来试试吗？ 1. 访问路径： 2. 下载1.12.0版本，可以通过`Previous Releases`找到历史版本，如下图所示： ![在这里插入图片描述](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b8456533f7404c00bf5633a6bf623500~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=618\&h=578\&s=115613\&e=png\&b=fffefe) 根据不同操作系统进行下载 ![在这里插入图片描述](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b6316c5ba28f496184c052bb78fc639e~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=578\&h=216\&s=47473\&e=png\&b=fffefe) 3. 打开MAT，会看到Welcome界面，假如你是初学者，不要急着关闭，建议你把Tutorials玩一遍 ![在这里插入图片描述](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0dd0f86d78114f008fa53b2a8dc28356~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=1004\&h=718\&s=72110\&e=png\&b=fcfcfc) 例如，你可以点开按照它的步骤玩一会，相信你很快就熟悉这个工具了。 ![在这里插入图片描述](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/913fe7c8ff194af782c9f9ca07646695~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=1004\&h=571\&s=50968\&e=png\&b=f5f5f5) `满满的Eclipse风，不知道00后程序员习不习惯，哈哈` ## 其它网上资料五花八门，如果你想要熟悉这个工具，你可以按照上面的Tutorials玩一遍。或者通过官方文档进行学习：[eclipse官方Tutorial](https://help.eclipse.org/latest/index.jsp?topic=/org.eclipse.mat.ui.help/gettingstarted/basictutorial.html) 、 *** `在更进一步使用MAT之前,先带你熟悉下内存参数` # 四、JVM内存参数详解我们通常会看到这样的参数：`-Xmx1024m`，`-XX:SurvivorRatio` 等等；可能查阅相关文档后知道它的用法，过一段时间又忘记了，总是反反复复。曾经我也有这样的困惑，直到我掌握了画图工具。参数的作用直接在我的脑海中呈现。话不多说，我们看图说话。 ## 年轻代和老年代 ### 按比例 ![在这里插入图片描述](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f2e93ab32d2f4303b58b1aed022a464b~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=1171\&h=450\&s=16117\&e=png\&b=fff8f7) ①Eden（伊甸园）区和Survivor中的From区的比例； ②Old（老年）区和new（新生代）的比例； ### 按大小 ![在这里插入图片描述](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2b2b352945e1446cad14f6c6b2338322~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=1414\&h=701\&s=21574\&e=png\&b=fff4f2) ③最大新生代容量大小，单位为m；例如：-XX:MaxNewSize=1024M；它是一个可伸缩的配置。 ④去除保留部分的新生代容量大小，同上。 ⑤最大新生代容量大小，不可伸缩。即最小和最大等同。单位为m；例如：-Xmn2048m； ⑥新生代+老年代+保留最大容量大小。单位为m；例如：-Xmx4096m； ⑦去除保留部分的容量大小，同上。 ## 元空间 ![在这里插入图片描述](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d27e65ab04b9487aa2cda20fde6457c6~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=860\&h=261\&s=13016\&e=png\&b=fdfdfd) ## JIT编译缓存 ![在这里插入图片描述](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d340c48f8f5445cc84a2d60d4e122f2a~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=661\&h=400\&s=18131\&e=png\&b=fdf4f3) `-XX:ReservedCodeCacheSize` 用于设置为编译后的代码保留的内存大小。Code Cache是JVM中用于存放即时编译器生成的本地机器代码的区域。当设置小于240m时候，`non-nmethods`,`profiled-nmethods`,`non-profiled-nmethods`被存放在一起。我们IDEA默认设置的值就是240m。我们来看下这三个到底是什么。关于`non-nmethods`, `profiled-nmethods`, 和 `non-profiled-nmethods`，它们都是Code Cache的区段。JVM（尤其是HotSpot VM）在Java 8和Java 9中进行了一些更改，为Code Cache引入了不同的分段以改进性能和可维护性。 ### non-nmethods 用于存放不是由即时编译器生成的代码，例如解释器代码和存根。 ### profiled-nmethods 存放已经进行了简单分析（基于采样）的方法的编译代码。这部分代码是第一次编译的，它包含了插桩代码（profilers）来收集更多关于方法行为的信息。 ### non-profiled-nmethods 存放未进行分析的方法的编译代码。这些方法通常是第二次（或更多次）编译的，使用了更多的优化技术，但没有插桩代码。它们基于`profiled-nmethods`中收集的信息进行编译。为了提高性能，即时编译器可能会多次编译某些热点方法，每次采用更多的优化。这就是为什么有区分“已分析”和“未分析”的编译代码的需要。你可以使用JVM诊断工具（如`jcmd`）查看Code Cache的使用情况，例如： jcmd Compiler.codecache 其中``是Java进程的ID。 # 五、内存溢出与其常见原因 > 内存溢出（out of menory）：程序需求的内存，超出了系统所能分配的范围。 > 内存泄漏（memory leak）：不再用到的内存，没有及时释放。内存溢出是指程序在申请内存时，没有足够的内存供其使用，出现此类错误一般是因为内存中已无空间可供分配。这在JVM中是一个常见的问题。在本章中，我们将详细探讨JVM中可能导致内存溢出的常见原因。 ## 堆内存不足 * **对象过多**：如果应用程序创建了大量的长生命周期的对象，堆中可用的内存可能会迅速耗尽。 * **内存泄漏**：某些对象无法被GC回收，但它们不再被使用。这些对象占据了堆空间，导致其他新对象无法在堆上分配。 ## 栈溢出 * **递归过深**：如果一个方法递归调用自己，并且没有有效的终止条件，那么这个方法的调用栈会不断增长，直到耗尽所有的栈内存。 * **局部变量过多**：大量的局部变量和大型数据结构可能会导致栈空间迅速耗尽。 ## 方法区内存不足 * **加载的类过多**：如果应用程序或其库加载了大量的类，方法区内存可能会被耗尽。 * **大量的常量**：大量的常量，尤其是字符串常量，可能会消耗方法区的内存。内存溢出的问题可以通过多种工具和技巧进行诊断和解决。在后续章节中，我们将详细讨论这些方法。 *** # 六、诊断内存溢出当你面临一个可能的内存溢出问题时，第一步是确定它确实是内存溢出。接下来，我们将讨论一系列工具和步骤来帮助你诊断和解决这些问题。 ## JVM日志启动JVM时，可以使用以下参数来收集有关内存使用情况的信息： * `-XX:+PrintGCDetails`：此选项将为每次GC打印详细日志。 * `-XX:+PrintGCTimeStamps`：此选项将为GC日志添加时间戳。从GC日志中，你可以看到每次垃圾回收的时间、回收了多少内存以及堆的总大小。频繁的全GC通常是内存压力的一个信号。 ## 堆转储分析当你怀疑有堆内存溢出时，可以生成堆转储来分析： * 使用`jmap`工具：`jmap -dump:live,format=b,file= ` 堆转储可以使用如Eclipse MAT或VisualVM等工具进行分析，以确定哪些对象占用了最多的内存。 ## 堆转储工具类似的工具有**Java VisualVM**和**Eclipse MAT**，用于监视、分析和调试Java应用程序。它可以显示内存使用、线程活动和方法调用。 ## 硬件和操作系统工具在某些情况下，问题可能不仅仅在JVM级别。使用像`top`、`vmstat`或其他OS级别的工具可以帮助确定整个系统的内存使用情况。一旦诊断出问题，下一步是采取措施修复它。在接下来的章节中，我们将详细讨论如何解决内存溢出问题。 *** # 七、解决内存溢出问题在确诊了内存溢出后，我们需要立刻行动以解决它。本章将带你走进解决问题的具体步骤。 ## 调整JVM参数 > 并不是每个人都会分析如何设置JVM 堆内存大小，为了避免内存太小导致的溢出，基本上都设得挺大的，毕竟内存大总比内存溢出好，因此就造成了不少的内存浪费。对于许多应用来说，简单地**微调**JVM的内存参数可能就是解决问题的关键。一些常见的参数包括： * `-Xms` 和 `-Xmx`：它们分别设置了JVM堆的初始大小和最大大小。 * `-XX:MaxMetaspaceSize`：对于Java 8及以上版本，这个参数限制了元数据空间的大小，这是旧的持久代的替代品。请注意，盲目地增加内存不是一个长久之计，你应该根据应用的实际需要进行适当的调整。**如何选择合适大小的内存？我会在后面的文章为你分析。** ## 代码优化代码优化对每个程序员都息息相关，我们来看下有哪些注意事项： * **移除不必要的对象引用**：确保你的代码中不再使用的对象被正确地设置为null，这样垃圾回收器可以回收它们。 * **使用弱引用或软引用**：Java提供了`WeakReference`和`SoftReference`类，当你想要持有一个对象的引用，但不想阻止它被垃圾收集时，它们是很有用的。 * **池化资源**：对于重的对象，如数据库连接或线程，使用池可以有效地复用它们，而不是每次都重新创建。归结为一句话：**避免重复创建，避免让无用的对象存活太长**。 ## 使用缓存策略缓存可是性能优化的一大利器，但是它是一把双刃剑。虽然它可以显著提高应用的性能，但如果不正确地管理，它也可能是内存溢出的原因。考虑使用像LruCache这样的策略，它会根据使用情况自动删除老的缓存项。 ## 外部存储内存是计算机中相对不那么便宜一块位置。如果你的应用需要处理大量数据，可以考虑将一部分数据移到外部存储，如数据库、硬盘或分布式缓存系统。 ## 第三方库审查我们引用的大部分包，都可以在升级后得到解决。确保你使用的所有第三方库都是最新的，没有已知的内存泄漏问题。旧的或未维护的库可能会成为应用中内存问题的隐藏来源。解决内存溢出问题可能需要时间和耐心，但通过系统的方法和正确的工具，你可以有效地定位并解决它们。接下来的章节，我们将分享一些实际的案例和经验。 *** # 八、基于MAT分析的实战应用案例 > HPROF文件可能包含敏感或私有信息，因此直接在公共平台上共享可能不是一个好主意。这也是为什么大多数公司会选择在内部工具或私有云环境中进行HPROF文件的分析。网上大部分分享出来的案例大多都是层层加码，没办法拿到完整的HPROF文件。实际场景常常是最佳的学习平台。接下来，我将为您分享一个案例，展示如何在实际环境中诊断并解决JVM内存溢出问题。一个完整的生产级事故，一般都会经历下面这几个阶段： ## 快速恢复业务当线上出现故障时，首先需要迅速消除其对业务的影响，随后再收集数据、定位问题，并给出解决方案。为确保线上业务不受干扰，而不仅仅是简单地重启服务器，我们需要尽可能地保留出现问题的场景，为后续的问题分析提供基础。那么，如何既能迅速消除对业务的影响，又能保留故障的现场信息呢？ **首选策略是隔离出问题的服务器。** 当服务器出现问题时，良好的分布式负载方案可以自动将出问题的机器从集群中移除，以确保系统的高可用性。如果故障的服务器没有被自动移除，需要运维人员手动隔离，并保留故障信息供后续分析。内存泄露问题，大多数情况下是代码错误导致的。这类问题可能会引发连锁反应，导致多台服务器接连崩溃。为了避免这种连锁反应，我们需要迅速定位并处理内存泄露问题，同时尽可能减少其对其他服务的影响。简单的解决办法是根据转发策略（例如使用Nginx或F5），将流量引导到一个单独的集群，与其他业务流量隔离，确保整体业务稳定。 ## 问题定位首先，通过日志确定是哪种类型的内存溢出，例如Java heap space（堆空间）或perm space（持久代）。团队发现频繁的全堆垃圾收集是导致应用崩溃的主因。每次GC都会使应用响应时间大幅度增加，直至系统崩溃。进一步的分析显示，存在一个被频繁使用但从未释放的大型缓存对象，导致GC花费大量时间。 ## 解决方案团队决定优化缓存的实现。首先，他们移除了所有不必要的对象引用，确保这些对象在不再使用后能够被垃圾回收。接下来，他们采用了新的缓存策略，使用`WeakReference`来引用可能很快被垃圾回收的对象。此外，他们还确保所有使用的第三方库都是最新版本，并没有已知的内存泄漏问题。 ## 收集内存溢出Dump文件有两种方法可以收集Dump文件： * 设置JVM启动参数`-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/jvmdump`。这样，每次发生内存溢出时，JVM会自动进行堆转储，其dump文件将保存在指定路径下。 * 使用`jmap`命令进行收集：`jmap -dump:live,format=b,file=/opt/jvm/dump.hprof pid`。 ## 分析Dump文件我也不制造问题了，直接把教程中的HPROF拿来分析，我们使用MAT打开Dump文件后，您将看到如下的界面： ![在这里插入图片描述](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/744cb40197fd454a8864159484d9b357~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=1432\&h=969\&s=108642\&e=png\&b=fbfbfb) 通过上述方法，我们可以更高效地定位并解决JVM内存溢出问题，确保业务的稳定运行。 *** # 九、其它工具在处理JVM内存溢出问题时，使用正确的工具至关重要。下面我会介绍一些常用的工具和技巧，这些工具和技巧可以帮助您更快地定位和解决问题。 ## JVM内置工具 ### 1. jstat `jstat` 是一个命令行工具，可以提供JVM的类加载、垃圾收集、JIT编译等的统计信息。例如，要查看一个正在运行的Java进程的垃圾收集统计信息，可以使用： jstat -gc ### 2. jmap `jmap` 是一个Java内存映射工具，可以为Java进程生成堆转储。堆转储可以使用其他工具进行分析，以找出内存泄漏或其他问题。例如，生成一个堆转储： jmap -dump:format=b,file= ### 3. VisualVM 我在上面已经提到，但是为了把它归类完整，还是着重介绍一下它。 [VisualVM](https://visualvm.github.io/) 是一个强大的工具，集成了多个JDK命令行工具。它提供了一个可视化的界面，可以查看和分析Java应用程序的性能数据。你可以在这个工具中解决80%以上的问题。 ## 技巧和建议 * 在启动Java应用程序时，使用`-verbose:gc` 和 `-Xloggc:` 参数，可以输出GC日志。这些日志在分析垃圾收集活动时非常有用。 * 定期审查代码，避免常见的内存泄漏情况，例如：长时间持有对象引用，或不适当地使用静态集合。 * 使用自动测试和负载测试来模拟高流量的情境，确保系统在高压力下仍能正常运行。 *** # 解决策略与优化建议解决JVM内存溢出问题不仅仅是定位和修复问题，更重要的是对系统进行长期的优化和调整，以预防此类问题再次发生。下面是一些常见的解决策略和优化建议： ## 1. 调整JVM参数 **调参工程师**名不虚传，调参可以解决90%以上的性能慢的问题。以下是一些常见的套路： * **堆内存分配**：适当增加JVM的`-Xms`和`-Xmx`值可以延长OOM的发生，但不是根本解决方法。这只有在确保没有内存泄漏的情况下才有效。 * **调整年轻代与老年代大小**：使用`-XX:NewRatio`来调整年轻代和老年代的比例，以适应应用的实际需求。 * **调整线程栈大小**：如果出现因为线程过多导致的OOM，可以通过`-Xss`调整每个线程的栈大小。 ## 2. 代码优化建议 * **使用弱引用**：对于不必长时间持有的对象，可以考虑使用弱引用，使其能够在适当的时机被垃圾收集器回收。 * **缓存策略**：确保所有缓存（如商品缓存）都有清晰的过期策略和大小限制。 * **减少对象的全局持有**：例如，避免使用静态集合类持有大量对象。 ## 3. 垃圾收集策略调整 * **选择合适的GC算法**：例如，对于需要低延迟的应用，可以考虑使用G1或ZGC。 * **调整GC参数**：使用`-XX:GCTimeRatio`和`-XX:AdaptiveSizePolicyWeight`等参数，对GC进行微调。 *** # 十、总结内存管理在JVM性能优化中占有举足轻重的地位。不合理的内存使用不仅会导致应用的不稳定，还会严重影响用户体验。因此，对内存溢出问题的及时发现和解决尤为关键。本文通过详细的案例分析，让我们了解到了如何定位和解决JVM内存溢出的问题。通过对JVM参数的调整、代码的优化和合理的垃圾收集策略，我们可以确保应用的稳定运行并最大化性能。在今后的开发中，希望大家能够将这些经验和策略运用得当，持续优化和提高应用的性能。 *** # 十一、参考文献 1. [生产环境JVM内存溢出案例分析](https://cloud.tencent.com/developer/article/1443574) 2. [10分钟搞懂各种内存溢出案例！！](https://mp.weixin.qq.com/s/Mh-PeXP7sVV2_mUfJ0Pd_A) 3. [一次内存溢出排查优化实战](https://mp.weixin.qq.com/s/nyrnmBJFJNaFJju39szMKA) 4. [FullGC 40次/天到10天1次，这波JVM优化很炸裂！！](https://mp.weixin.qq.com/s/OP_lvgb2foY6v7_hSbiWPA) 5. [谈JVM线程和内存参数合理性设置](https://mp.weixin.qq.com/s/1vWX5PLQ--lF3wy8z1lagw) 6. [JVM 内存大对象监控和优化实践](https://mp.weixin.qq.com/s/qfsY7fk_-rMdXPGYb766PA?poc_token=HIbjEGWjtT-cIxC57HMs5xesTVt1q9ZEcYppFwHN)