JVM垃圾回收分析Java内存看这篇就够了！

Java内存分析的目标都是以使垃圾回收（GC）对应用程序响应时间或CPU使用率的影响最小化的方式来优化垃圾回收。确保应用程序的稳定性同样重要。内存不足和泄漏通常会导致不稳定。为了确定内存导致的不稳定或过多的垃圾回收，我们首先需要使用适当的工具监视我们的Java应用程序。如果垃圾回收对响应时间有负面影响，我们的目标必须是优化配置。每次配置更改的目标都必须是减少这种影响。最后，如果仅配置更改还不够，我们必须分析分配模式和内存使用本身。因此，让我们开始吧。

本文分享给需要面试刷题的朋友，整理了面试资料这份资料主要包含了Java基础，数据结构，jvm，多线程等等，由于篇幅有限，以下只展示小部分面试题，
需要完整版的朋友可以点一点领取：戳这里即可领取下面资料，获取码：CSDN

内存监控工具

从Java 5开始，标准的JDK监视工具就是JConsole。Oracle JDK还包括jStat和Java VisualVM（或jvisualvm），jStat支持从控制台监视内存使用情况和垃圾收集器活动，Java VisualVM（或jvisualvm）提供基本的内存分析和分析器。Oracle JRockit JDK包括JRockit任务控制和JVM的verbose：gc标志。每个JVM供应商都包括自己的监视工具，并且有许多提供附加功能的商业工具可用。

监视内存使用和GC活动

内存不足通常是Java应用程序不稳定和无法响应的原因。因此，我们需要监视垃圾回收对响应时间和内存使用的影响，以确保稳定性和性能。但是，仅监视这两个元素并不能告诉我们应用程序响应时间是否受垃圾收集影响，因此监视内存利用率和垃圾收集时间是不够的。
只有GC挂起会直接影响响应时间，并且GC也可以与应用程序并行运行。因此，我们需要将垃圾收集导致的暂停与应用程序的响应时间相关联。基于此，我们需要监视以下内容：
利用不同的内存池（Eden，Survivor和Old）。内存不足是增加GC活动的第一原因。

如果尽管进行了垃圾回收，但总体内存利用率仍在不断提高，则存在内存泄漏，这不可避免地会导致内存不足错误。在这种情况下，必须进行内存堆分析。

年轻一代收藏的数量提供了有关流失率（对象分配率）的信息。数字越高，分配的对象越多。大量的年轻藏品可能是响应时间问题和老一代人成长的原因（因为年轻一代无法再处理大量的对象）。

如果在GC之后老一代的利用率波动很大而又没有上升，则对象会不必要地从年轻一代复制到老一代。造成这种情况的原因可能有三个：年轻一代太小，客户流失率高或事务性内存使用过多。

高GC活动通常会对CPU使用率产生负面影响。但是，只有暂停（又称为世界停止事件）会直接影响响应时间。与大众观点相反，停赛不限于主要的地方选区。因此，重要的是要监视与应用程序响应时间相关的挂起。

JVM内存仪表板（图2.11）显示，使用年限（或较早）的一代正在持续增长，但在使用较旧版本的GC（右下图）之后才恢复到原来的水平。这意味着不存在内存泄漏，并且增长的原因是过早使用对象。年轻一代太小，无法应付正在运行的事务的分配。新一代GC（Oracle / Sun Copy GC）的数量也表明了这一点。这些所谓的次要GC通常会被忽略，并且认为没有影响。

JVM将在次要垃圾回收期间暂停；这是世界停止的事件。次要GC通常非常快，这就是为什么将它们称为次要GC，但是在这种情况下，它们对响应时间有很大的影响。根本原因与已经提到的相同：年轻一代太小而无法应付。重要的是要注意，增加年轻一代的规模可能还不够。较大的年轻一代可以容纳更多的有生命的物体，这反过来又会导致更长的GC周期。最佳的优化始终是减少分配数和总体内存需求。

图2.11：显示了如何可视化JVM内存活动
当然，我们不能避免GC循环，我们也不想这样做。但是，我们可以优化配置，以最大程度地减少GC悬浮液对响应时间的影响。

如何监视和解释GC对响应时间的影响

GC悬浮表示垃圾收集器对响应时间的唯一直接影响。监视此问题的唯一方法是通过JVM工具界面（JVM TI），该界面可用于在挂起的开始和结束时注册回调。在世界停止事件期间，所有活动事务都将被挂起。通过标识暂停的开始和结束，我们可以将