Java 中的内存泄漏-CSDN博客

本文链接：https://blog.csdn.net/qq_37116560/article/details/130966631

什么是 Java 中的内存泄漏？

当应用程序持有不再需要的对象引用时，就会发生 Java 内存泄漏。这些意外的对象引用阻止内置的 Java 垃圾收集机制释放这些对象消耗的内存，最终导致致命的OutOfMemoryError。

简而言之，内存泄漏是- 不再需要的对象引用，仍然存在于 HEAP 内存中，垃圾收集器无法删除它们。

发生内存泄漏的最常见场景：

没有正确使用静态成员。
未关闭的资源。
将没有 hashCode() 和 equals() 的对象添加到 HashSet 中。
过多的会话对象。
自定义数据结构编写不当。

在这里我们将讨论上面的几个：

1. 静态成员使用不当：

在其声明中具有静态修饰符的字段称为静态字段或类变量。它们与类相关联，而不是与任何对象相关联。当变量被声明为静态时，将创建该变量的单个副本并在类级别的所有对象之间共享。在 Java 中，静态字段的生命周期通常与正在运行的应用程序的整个生命周期相匹配。因此静态成员与 Class 相关，因此垃圾收集器无法清理静态成员占用的内存空间。

这是一个例子：

您可以在此处看到我创建了一个名为 list 的静态 ArrayList 成员，并使用该变量在第 10 行存储字符串。在第 19 行，我调用了垃圾收集器。这里我要演示一下，虽然我在第19行调用了Garbage Collector，但是垃圾收集器并不能为它清理Memory空间。为此，我在第 12 行、第 16 行、第 18 行、第 20 行添加了调试点。

让我们执行程序：

在第 18 行，请注意，在一开始，所有内存当然都是空闲的。然后，迭代过程运行并结束——将所有内容加载到列表中(当然这取决于您运行测试的机器)。我们可以在图表(右侧)中看到尖峰。

在第 20 行，触发完整的垃圾收集周期后，测试继续执行，以允许此周期时间运行并完成。如您所见，列表没有被回收，内存消耗也没有下降。

现在让我们看一下完全相同的例子，只是这一次，ArrayList 没有被静态变量引用。相反，它是一个非静态实例变量，它被创建、使用然后被垃圾收集。

在第 20 行，触发完整的垃圾收集周期后，测试继续执行，以允许此周期时间运行并完成。您可以看到，请注意 GC 现在如何能够回收 JVM 使用的一些内存。(右边)

2.未关闭的流：

忘记关闭流是一种非常常见的情况，当然，大多数开发人员都会遇到这种情况。当在 try-with-resource 子句中引入自动关闭所有类型的流的能力时，这个问题在 Java 7 中得到了部分解决。

让我们看看从 URL 加载大文件时应用程序的内存情况：

正如我们所看到的，堆使用量随着时间的推移逐渐增加——这是未关闭流导致内存泄漏的直接影响。
让我们更深入地研究一下这个场景，因为它不像其他场景那样明确。从技术上讲，未关闭的流将导致两种类型的泄漏——低级资源泄漏和内存泄漏。
低级资源泄漏只是操作系统级资源的泄漏——例如文件描述符、打开的连接等。这些资源也可能泄漏，就像内存一样。

当然，JVM 也使用内存来跟踪这些底层资源，这就是为什么这也会导致内存泄漏。

在这里您可以在开始执行程序时看到使用的元空间。

在这里您可以在程序执行结束时看到使用的元空间。

这里可以看到使用的堆内存

我们总是需要记住手动关闭流，或者使用自动关闭功能。在这种情况下，BufferedReader 将在 try 语句结束时自动关闭，而不需要在显式的 finally 块中关闭它。

在这里，您可以在程序开始执行时看到使用的元空间。

在这里您可以看到程序执行结束后使用的元空间小于我们没有关闭流的先前程序。

在这里您可以看到使用的堆内存，这比我们没有关闭流的前一个程序要少。

3. 将没有 hashCode() 和 equals() 的对象添加到 HashSet 中：
一个可能导致内存泄漏的简单但非常常见的示例是将 HashSet 与缺少其 hashCode() 或 equals() 实现的对象一起使用。
具体来说，当我们开始将重复对象添加到 Set 中时——它只会增长，而不是像它应该的那样忽略重复对象。一旦添加，我们也将无法删除这些对象。

这里我们创建了一个没有 hashCode() 和 equals() 方法的 Country 类。