理解Java中的内存泄漏

原文链接:https://www.baeldung.com/java-memory-leaks

作者:baeldung

译者:thornhill

1. 简介

Java的核心优势之一是在内置垃圾收集器（简称GC）的帮助下实现自动内存管理。GC隐含地负责分配和释放内存，因而能够解决大多数内存泄漏问题。

尽管GC有效地解决了大部分内存，但它并不能成为保证内存泄漏的万无一失的处理方案。GC很聪明，但并不完美。即便在尽职尽责的开发人员的应用程序中，内存依然可能会泄漏。

依然可能存在应用程序生成大量多余对象的情况，从而耗尽关键内存资源，有时会导致整个应用程序失败。

内存泄漏是Java中的一个真实存在的问题。在本教程中，我们将理解内存泄漏的潜在起因是什么，如何在运行时识别它们，以及如何在我们的应用程序中解决它们。

2. 什么是内存泄漏

内存泄漏是堆中存在不再使用的对象但垃圾收集器无法从内存中删除它们的情况，因而它们会被不必要地一直存在。

内存泄漏很糟糕，由于它会耗尽内存资源并降低系统性能。假如不解决，应用程序最终将耗尽其资源，最终以致命的java.lang.OutOfMemoryError终止。

堆内存中有两种不同类型的对象 – 被引用和未被引用。被引用的对象是在应用程序中仍具备活动引用的对象，而未被引用的对象没有任何的活动引用。

垃圾收集器会定期删除未引用的对象，但它永远不会收集仍在引用的对象。这是可能发生内存泄漏的地方：

内存泄漏的症状

应用程序长时间连续运行时性能严重下降

应用程序中的OutOfMemoryError堆错误

自发且奇怪的应用程序崩溃

应用程序偶尔会耗尽连接对象

让我们仔细看看其中少量场景以及如何解决它们。

3. Java中内存泄漏类型

在任何应用程序中，数不清的起因可能导致内存泄漏。在本节中，我们将探讨最常见的问题。

3.1?static字段引起的内存泄漏

可能导致潜在内存泄漏的第一种情况是大量使用static(静态)变量。

在Java中，静态字段通常拥有与整个应用程序相匹配的生命周期（除非ClassLoader复合垃圾回收的条件）。

让我们创立一个填充静态列表的简单Java程序：

publicclassStaticTest{publicstaticList list =newArrayList<>();publicvoidpopulateList(){for(inti =0; i <10000000; i++) {? ? ? ? ? ? list.add(Math.random());? ? ? ? }? ? ? ? Log.info(“Debug Point 2”);? ? }publicstaticvoidmain(String[] args){? ? ? ? Log.info(“Debug Point 1”);newStaticTest().populateList();? ? ? ? Log.info(“Debug Point 3”);? ? }}

现在假如我们在程序中分析堆内存，我们会发现在调试点1和2之间，和预期中的一样，对内存添加了。

但当我们在调试点3，离开populateList()方法时，堆内存并没有被垃圾回收，正如我们在VisualVM响应中看到的一样：

但是，在上面的程序中，在第2行中，假如我们只删除关键字?static，那么它将对内存使用量带来巨大的变化，这个Visual VM响应显示：?

直到调试点的第一部分几乎与我们在static情况下取得的部分相同 。但这次当我们离开populateList()方法，列表中所有的内存都被垃圾回收掉了，由于我们没有任何对他的引用。

因而，我们需要非常关注static(静态)变量的使用。假如集合或者大对象被公告为static，那么它们将在应用程序的整个生命周期中保留在内存中，从而阻止可能在其余地方使用的重要内存。

如何预防呢？

最大限度地减少静态变量的使用

使用单例时，依赖于推迟加载对象而不是立即加载的方式

3.2 未关闭的资源导致的内存泄漏

每当我们创立连接或者打开一个流时，JVM都会为这些资源分配内存。例如数据库连接，输入流或者者会话对象。

不记得关闭这些资源会导致持续占有内存，从而使他们无法GC。假如异常阻止程序执行到达解决关闭这些资源的代码，则甚至可能发生这种情况。

在任一种情况下，资源留下的开放连接都会消耗内存，假如我们不解决他们，他们可能会降低性能，甚至可能导致OutOfMemoryError。

如何预防呢？

始终使用finally块来关闭资源

关闭资源的代码（甚至在?finally块中）本身不应该有任何异常

使用Java 7+时，我们可以使用try -with-resources块

3.3 不正确的equals()和hashCode()实现

在定义新类时，一个非常常见的疏忽是不为equals（）和hashCode（）方法编写适当的重写方法。

HashSet?和?HashMap?在许多操作中使用这些方法，假如它们没有被正确覆盖，那么它们可能成为潜在的内存泄漏问题的来源。

让我们以一个简单的Person?类为例， 并将其用作HashMap中的键 ：

publicclassPerson{publicString name;publicPerson(String name){this.name = name;? ? }}

现在我们将重复的Person对象插入到使用此键的Map中。

请记住，Map不能包含重复的键：

@TestpublicvoidgivenMap_whenEqualsAndHashCodeNotOverridden_thenMemoryLeak(){? ? Map map =newHashMap<>();for(inti=0; i<100; i++) {? ? ? ? map.put(newPerson(“jon”),1);? ? }? ? Assert.assertFalse(map.size() ==1);}

这里我们使用Person作为关键。因为Map不允许重复键，因而我们作为键插入的众多重复Person对象不应添加内存。

但是因为我们没有定义正确的equals（）方法，重复的对象会堆积并添加内存，这就是我们在内存中看到多个对象的起因。VisualVM中的堆内存如下所示：

但是，**假如我们正确地重写了equals（）?和hashCode（）方法，那么在这个Map中只会存在一个Person对象。

让我们看一下正确的实现了equals()和hashCode()的Person类：

publicclassPerson{publicString name;publicPerson(String name){this.name = name;? ? }@Overridepublicbooleanequals(Object o){if(o ==this)returntrue;if(!(oinstanceofPerson)) {returnfalse;? ? ? ? }? ? ? ? Person person = (Person) o;returnperson.name.equals(name);? ? }@OverridepublicinthashCode(){intresult =17;? ? ? ? result =31* result + name.hashCode();returnresult;? ? }}

在这种情况下，下面的断言将会是true：

@TestpublicvoidgivenMap_whenEqualsAndHashCodeNotOverridden_thenMemoryLeak(){? ? Map map =newHashMap<>();for(inti=0; i<2; i++) {? ? ? ? map.put(newPerson(“jon”),1);? ? }? ? Assert.assertTrue(map.size() ==1);}

在适当的重写equals()和hashCode()之后，堆内存在同一程序中如下所示：

另一个例子是当使用像hibernate这样的ORM框架，他们使用equals()和hashCode()方法去分析对象而后将他们保存在缓存中。

程序员学习交流学习群：878249276，群里有分享的视频，面试指导，架构资料，还有思维导图、群里有视频，都是干货的，你可以下载来看。主要分享分布式架构、高可扩展、高性能、高并发、性能优化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分布式项目实战学习架构师视频。正当利用自己每一分每一秒的时间来学习提升自己，不要再用”没有时间“来掩饰自己思想上的懒惰！趁年轻，使劲拼，给未来的自己一个交代！

如何预防呢？

根据经验，定义新的实体时，总要重写equals()和hashCode()方法。

只是重写他们是不够的，这些方法必需以最佳的方式被重写。

有关更多信息，请访问我们的?Generate?equals()?and?hashCode()?with Eclipse?和Guide to?hashCode()?in Java。

3.4引用了外部类的内部类

这种情况发生在非静态内部类（匿名类）的情况下。对于初始化，这些内部类总是需要外部类的实例。

默认情况下，每个非静态内部类都包含对其包含类的隐式引用。假如我们在应用程序中使用这个内部类’对象，那么即便在我们的包含类’对象超出范围之后，它也不会被垃圾收集。

考虑一个类，它包含对大量庞大对象的引用，并具备非静态内部类。现在，当我们创立一个内部类的对象时，内存模型如下所示：

但是，假如我们只是将内部类公告为static，那么相同的内存模型如下所示：

发生这种情况是由于内部类对象隐式地保存对外部类对象的引用，从而使其成为垃圾收集的无效候选者。在匿名类的情况下也是如此。

如何预防呢？

假如内部类不需要访问包含的类成员，请考虑将其转换为静态类

3.5finalize()方法造成的内存泄漏

使用finalizers是潜在的内存泄漏问题的另一个来源。每当重写类的?finalize（）方法时，该类的对象不会立即被垃圾收集。相反，GC将它们排队等待最终确定，这将在稍后的时间点发生。

另外，假如用finalize（）方法编写的代码不是最佳的，并且终结器队列无法跟上Java垃圾收集器，那么迟早，我们的应用程序注定要遇到?OutOfMemoryError。

为了证实这一点，让我们考虑一下我们已经覆盖了?finalize（）方法的类，并且该方法需要少量时间来执行。当这个类的大量对象被垃圾收集时，那么在VisualVM中，它看起来像：

但是，假如我们只删除重写的finalize（）方法，那么同一程序会给出以下响应：

如何预防呢？

我们应该总是避免finalizers

有关finalize（）的更多详细信息，请阅读我们的?Guide to the finalize Method in Java?第3节（避免终结器） 。

常量字符串造成的内存泄漏

Java?String池Java 7时经历了在从永生代（PermGen）转移到堆空间（HeapSpace）的重大变化。但是对于在版本6及更低版本上运行的应用程序，在使用大型字符串时我们应该更加专心。

假如我们读取一个庞大的大量String对象，并在该对象上调用intern（），那么它将转到字符串池，它位于PermGen（永生代）中，并且只需我们的应用程序运行就会保留在那里。这会占用内存并在我们的应用程序中造成重大内存泄漏。

JVM 1.6中这种情况的PermGen在VisualVM中看起来像这样：

与此相反，在一个方法中，假如我们只是从文件中读取一个字符串而不是intern()，那么PermGen看起来像：

如何预防呢？

处理此问题的最简单方法是更新到最新的Java版本，由于String池从Java版本7开始转移到HeapSpace

假如解决大型字符串，请添加PermGen空间的大小以避免任何潜在的OutOfMemoryErrors：

-XX:MaxPermSize=512m

3.7 使用ThreadLocal造成的内存泄漏

ThreadLocal?（在Introduction to?ThreadLocal?in Java?中详细详情），是一种能将状态隔离到特定线程，从而保证我们实现线程安全的结构。

使用此结构时，每个线程只需处于存活状态就可将保留对其ThreadLocal变量副本的隐式引用，并且将保留其自己的副本，而不是跨多个线程共享资源。

虽然有其优点，ThreadLocal?变量的使用仍存在争议，由于假如使用不当，它们会因引入内存泄漏而臭名昭着。 Joshua Bloch?once commented on thread local usage：

“Sloppy use of thread pools in combination with sloppy use of thread locals can cause unintended object retention, as has been noted in many places. But placing the blame on thread locals is unwarranted.”

“随便的在线程池中使用ThreadLocal会保留很多意外的对象。但把责任归咎于ThreadLocal是没有根据的 “

ThreadLocal中的内存泄漏

一旦保持线程不再存在，ThreadLocals应该被垃圾收集。但是当ThreadLocals与现代应用程序服务器一起使用时，问题就出现了。

现代应用程序服务器使用线程池来解决请求而不是创立新请求（例如在Apache Tomcat的情况下为Executor）。此外，他们还使用单独的类加载器。

因为应用程序服务器中的线程池在线程重用的概念上工作，因而它们永远不会被垃圾收集 – 相反，它们会被重用来解决另一个请求。

现在，假如任何类创立?ThreadLocal?变量但未显式删除它，则即便在Web应用程序中止后，该对象的副本仍将保留在工作线程中，从而防止对象被垃圾回收。

如何预防呢？

在不再使用ThreadLocals时清除ThreadLocals是一个很好的做法-?ThreadLocals提供了?remove（）)方法，该方法删除了此变量的当前线程值

不要使用 ThreadLocal.set（null） 来清理该值?- 它实际上不会清理该值，而是查找与当前线程关联的Map并将键值对设置为当前线程并分别为null

最好将?ThreadLocal?视为需要在finally块中关闭的资源，以 确保它始终关闭，即便在异常的情况下：

try{? ? threadLocal.set(System.nanoTime());//… further processing}finally{? ? threadLocal.remove();}

4. 解决内存泄漏的其余策略

尽管在解决内存泄漏时没有一个通用的处理方案，但有少量方法可以最大限度地减少这些泄漏。

4.1 使用Profiling工具

Java分析器是通过应用程序监视和诊断内存泄漏的工具。他们分析我们的应用程序内部发生了什么 – 例如，如何分配内存。

使用分析器，我们可以比较不同的方法，并找到我们可以最佳地使用我们的资源的领域。

我们在本教程的第3部分中使用了Java VisualVM。请查看我们的?Java Profilers指南，?理解不同类型的分析器，如Mission Control，JProfiler，YourKit，Java VisualVM和Netbeans Profiler。

4.2 详细垃圾回收

通过启用详细垃圾收集，我们将跟踪GC的详细跟踪。要启用此功能，我们需要将以下内容增加到JVM配置中：

通过增加此参数，我们可以看到GC内部发生的详细信息：

4.3 使用引用对象避免内存泄漏

我们还可以使用java中的引用对象来构建java.lang.ref包来解决内存泄漏。使用java.lang.ref包，我们使用对象的特殊引用，而不是直接引用对象，这些对象可以很容易地进行垃圾回收。

引用队列旨在让我们理解垃圾收集器执行的操作。有关更多信息，请阅读Baeldung的?Soft References in Java?，特别是第4节。

Eclipse的内存泄漏警告

对于JDK 1.5及更高版本的项目，Eclipse会在遇到显著的内存泄漏情况时显示警告和错误。因而，在Eclipse中开发时，我们可以定期访问“问题”选项卡，并对内存泄漏警告（假如有）更加警惕：

4.5 基准分析

我们可以通过执行基准来测量和分析Java代码的性能。这样，我们可以比较替代方法的性能来完成相同的任务。这可以帮助我们选择更好的方法，并可以帮助我们节约内存。

有关基准测试的更多信息，请访问我们的?Microbenchmarking with Java?教程。

4.6 代码审核

最后，我们总是采用经典怀旧方式进行简单的代码审核。

在某些情况下，即便是这种微不足道的方法也可以帮助消除少量常见的内存泄漏问题。

5 结论

浅显地说，我们可以将内存泄漏视为一种通过阻止重要内存资源来降低应用程序性能的疾病。和所有其余疾病一样，假如不治愈，它可能导致致命的应用程序崩溃随着时间的推移。

内存泄漏很难处理，找到它们需要通过Java语言进行复杂的掌握和命令。在解决内存泄漏时，没有一个通用的处理方案，由于泄漏可能通过各种各样的事件发生。

但是，假如我们采用最佳实践并定期执行严格的代码演练和分析，那么我们可以最大程度地降低应用程序中内存泄漏的风险。

程序员学习交流学习群：878249276，群里有分享的视频，面试指导，架构资料，还有思维导图、群里有视频，都是干货的，你可以下载来看。主要分享分布式架构、高可扩展、高性能、高并发、性能优化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分布式项目实战学习架构师视频。正当利用自己每一分每一秒的时间来学习提升自己，不要再用”没有时间“来掩饰自己思想上的懒惰！趁年轻，使劲拼，给未来的自己一个交代！