为什么会发生内存泄漏Java如何检测内在泄漏呢？？

1、为什么会发生内存泄漏

Java如何检测内部泄漏？我们需要一些工具来检测和发现内存泄漏，否则很容易造成停机。

编写Java程序最方便的地方是我们不需要管理内存的分配和释放。一切都由jvm处理。当不再使用java对象时，当堆内存不足时，jvm将执行垃圾回收和清理。这些对象占用的堆内存空间。如果始终使用该对象，则jvm无法回收它。创建新对象时，它无法从堆中获取足够的内存来分配给该对象，这将导致内存溢出。在发生内存泄漏的地方，通常将对象保留在容器中，并且容器没有相应的大小限制或清除机制。容易引起内存溢出。

当服务器应用程序占用过多内存时，如何快速定位问题？现在，Eclipse MAT的出现使这个问题变得非常简单。 EclipseMAT是由著名的SAP公司提供的工具。可以从Eclipse网站下载它，并且完全免费。

要查找问题，首先需要在特定时刻获取服务器jvm内存的快照。 jdk随附的jmap可以在特定时刻拍摄内存快照。将其导出为dmp文件后，您可以使用Eclipse MAT对其进行分析，以找出哪个对象使用了过多的内存。

2、内存泄漏：

通常，程序内存泄漏的第一个迹象发生在错误之后，并且您的程序中出现OutOfMemoryError。这种典型情况发生在生产环境中，在生产环境中，您需要尽可能少的内存泄漏，并希望最大程度地减少调试的可能性。也许您的测试环境不同于产品的系统环境，并且泄漏只会暴露在产品中。在这种情况下，您需要一个低负载工具来监视和查找内存泄漏。同时，您还需要将此工具与系统链接，而无需重新启动它或使代码机械化。也许更重要的是，在进行分析时，您需要能够与工具分开，以免干扰系统。

OutOfMemoryError通常是内存泄漏的迹象。该应用程序可能使用了过多的内存。目前，您既不能增加JVM堆的数量，也不能更改程序以减少内存使用量。 。但是，在大多数情况下，OutOfMemoryError表示内存泄漏。一种解决方案是继续监视GC活动，并查看内存使用量是否会随着时间增加。如果是这样，程序中肯定有内存泄漏。

3、发现内存泄漏

1. jstat -gc pid

可以显示gc信息，检查gc的数量和时间。

最后五个项目是年轻gc的数量，年轻gc的时间，完整gc的数量，完整gc的时间以及gc的总时间。

2. jstat -gccapacity pid

它可以显示VM内存中三代（年轻，旧，烫发）对象的使用情况和占用大小，

例如：PGCMN显示最低的Perm内存使用率，PGCMX显示最高的Perm内存使用率，

PGC是新生成的烫发的内存占用，而PC是前一个烫发的内存占用。

其他人也可以效仿，OC是旧时的纯粹住所。

3. jstat -gcutil pid

gc信息统计的统计信息。

4. jstat -gcnew pid

有关年轻一代对象的信息。

5. jstat -gcnewcapacity pid

有关年轻一代对象及其占用情况的信息。

6. jstat -gcold pid

有关旧对象的信息。

7. stat -gcoldcapacity pid

旧对象信息及其占用。

8. jstat -gcpermcapacity pid

烫发对象信息及其占用情况。

9. jstat -class pid

显示信息，例如已加载的类数和占用的空间。

1 0. jstat -compiler pid

显示信息，例如VM的实时编译数量。

1 1. stat -printcompilation pid

当前VM执行信息。

某些术语的中文解释：

S0C：年轻一代中第一个幸存者的容量（字节）

S1C：年轻一代中第二个幸存者的容量（字节）

S0U：当前使用的空间（字节）的年轻一代中的第一个幸存者（幸存者区域）

S1U：年轻一代的第二个幸存者（幸存者区域）当前已使用空间（字节）

EC：伊甸园年轻一代的容量（字节）

欧盟：伊甸园（伊甸园）当前使用的空间（字节）

OC：旧容量（字节）

OU：当前使用的旧空间（字节）

PC：烫发（持久生成）容量（字节）

PU：彼尔姆（持久生成）当前使用的空间（字节）

YGC：从应用程序开始到采样时间的年轻一代中的gc数量

YGCT：从应用程序开始到gc在采样时在年轻一代中所花费的时间

FGC：从应用程序启动到采样的旧版（完整gc）gc的数量

FGCT：从应用程序启动到采样（gc）（gc）之前的时间（秒）

GCT：gc从应用程序开始到采样的总时间

NGCMN：年轻一代（年轻）的初始（最小）大小（字节）

NGCMX：年轻一代（年轻人）的最大容量（字节）

NGC：年轻一代（年轻人）的当前容量（字节）

OGCMN：旧版本中的初始化（最小）大小（字节）

OGCMX：旧一代的最大容量（字节）

OGC：旧的当前新生成的容量（字节）

PGCMN：电烫的初始化（最小）大小（字节）

PGCMX：烫发产生的最大容量（字节）

PGC：当前新生成的彼尔姆生成容量（字节）

S0：年轻一代中第一个幸存者使用的当前容量的百分比

S1：第二代幸存者（幸存者区域）在年轻一代中使用的当前容量的百分比

E：伊甸园在年轻一代中使用的当前容量百分比

O：上一代使用的当前容量的百分比

P：烫发所占当前容量的百分比

S0CMX：年轻一代中第一个幸存者的最大容量（字节）

S1CMX：年轻一代中第二个幸存者的最大容量（字节）

ECMX：年轻一代伊甸园的最大容量（字节）

DSS：当前所需的幸存者（生存区域）（伊甸园区域已满）的容量（字节）

TT：等待时间的限制

MTT：最大持有时间限制

如果找到内存泄漏问题，通常使用以下命令：

Jstat -gcutil15469 2500 70

[root @ ssss日志]＃jstat -gcutil 15469 1000 300

S0 S1 E O P YGC YGCT FGC FGCT GCT

0. 00 1. 46 2 6. 54 4. 61 3 0. 14 35 0. 872 0 0. 000 0. 872

0. 00 1. 46 4 6. 54 4. 61 3 0. 14 35 0. 872 0 0. 000 0. 872

0. 00 1. 46 4 7. 04 4. 61 3 0. 14 35 0. 872 0 0. 000 0. 872

0. 00 1. 46 6 5. 19 4. 61 3 0. 14 35 0. 872 0 0. 000 0. 872

0. 00 1. 46 6 7. 54 4. 61 3 0. 14 35 0. 872 0 0. 000 0. 872

0. 00 1. 46 8 7. 54 4. 61 3 0. 14 35 0. 872 0 0. 000 0. 872

0. 00 1. 46 8 8. 03 4. 61 3 0. 14 35 0. 872 0 0. 000 0. 872

1. 48 0. 00 5. 56 4. 62 3 0. 14 36 0. 874 0 0. 000 0. 874

1000表示多久显示一次？

100表示​​一次显示。

S0 —堆上Survivor space 0区域中已用空间的百分比

S1 —堆上Survivor space 1区域中已用空间的百分比

E —堆上Eden空间区域中已用空间的百分比

O-堆上“旧空间”区域中已用空间的百分比

P —已使用空间的彼尔姆空间百分比

YGC-从应用程序开始到采样时间的年轻GC发生次数

YGCT-Young GC从应用程序开始到采样时间的时间（以秒为单位）

FGC-从应用程序启动到采样的完整GC发生次数

FGCT-采样时从应用程序开始到Full GC的时间（以秒为单位）。

GCT-从应用程序开始到采样时间用于垃圾收集的总时间（以秒为单位）

如果FGC数量很多，则必须检查是否存在内存泄漏问题。图中FGC的数量相对较大，执行时间较长，这将导致系统的响应时间更长。如果jvm的内存为如果设置较大，则执行FGC的时间可能会更长。

为了更好地证明FGC对服务器性能的影响，我们可以使用java visualVM进行检查：

从上图中，我们可以看到FGC已执行。下午3:10之前没有FGC，此后出现了很多FGC。

上图显示了JVM堆内存的用法。下午3:10之前的内存恢复仍然是合理的，但是此后无法恢复大量内存，从而导致越来越少的内存，从而导致大量的gc。

接下来，我们正在研究大量完整GC对服务器性能的影响。下面是当我使用loadrunner对项目进行压力测试时相应时间的屏幕截图：

从图中可以看出，完全GC后系统的相应时间显着增加，点击率和吞吐量也显着降低。因此，Java内存泄漏对系统性能的影响不容忽视。

3、查找内存泄漏

当然，可以通过以上几种方法来发现Java的内存泄漏问题，但是作为一名合格的高级工程师，我绝对不愿意将这一结论提交给开发人员。当然，这个结论也将移交给开发人员。很难找到问题所在。为了更好地提供我们在公司中的职位，我们必须为开发工程师提供更深入的测试结论。让我们了解MemoryAnalyzer.exe。 Java内存泄漏检测工具工具。

首先，我们必须转储jvm的堆内存。只有获得此文件后，我们才能分析jvm的堆内存中存储的内容以及我们在做什么？

对于MemoryAnalyzer用户，在这里我不会一一解释，并且我的博客中也有解释。这是我的测试成功的图形：

深蓝色部分是内存泄漏的一部分。 Java的堆内存仅为48 1. 5M，仅内存泄漏的一部分就占据了33 6. 2M。所以这次内存泄漏很明显，接下来让我们看一下该方法引起的内存泄漏：

从上图中，我们可以发现红色圆圈方法占据了堆内存的6 7. 75％。如果测试结果可以移交给开发人员，那么开发人员的位置是否合适？因此，作为高级测试工程师，我们需要学习太多。

虽然不能确定一定是内存泄漏，但是令人信服的是要准确地说明开发问题的原因。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/shoujiruanjian/article-359717-1.html