原文链接: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大型分布式项目实战学习架构师视频。合理利用自己每一分每一秒的时间来学习提升自己，不要再用"没有时间“来掩饰自己思想上的懒惰！趁年轻，使劲拼，给未来的自己一个交代！
