Java.lang.OutOfMemoryError: Java heap space
Java应用程序只允许使用有限的内存。此限制在应用程序启动期间指定。为了使事情更复杂，Java内存被分成两个不同的区域。这些区域称为永久生成区域（permgene和Permgen）：
这些区域的大小是在Java虚拟机（JVM）启动期间设置的，可以通过指定JVM参数 -Xmx 和- XX:MaxPermSize 进行定制。如果未显式设置大小，则将使用特定于平台的默认值。
这个 java.lang.OutOfMemoryError ：当应用程序尝试向堆空间区域添加更多数据，但空间不足时，将触发Java堆空间错误。
请注意，可能有大量可用的物理内存，但是 java.lang.OutOfMemoryError ：每当JVM达到堆大小限制时，就会抛出Java堆空间错误。
是什么引起内存泄露的？
最常见的原因是 java.lang.OutOfMemoryError：Java heap space error –您尝试将XXL应用程序放入S大小的Java堆空间中。只是Java应用程序需要更多的空间来操作。此 OutOfMemoryError 消息的其他原因更为复杂，是由编程错误引起的：
- 使用量/数据量激增 。该应用程序设计为处理一定数量的用户或一定数量的数据。当用户数量或数据量突然达到峰值并超过预期阈值时，在峰值停止运行并触发java.lang.OutOfMemoryError：Java堆空间错误 。
- 内存泄漏 。特定类型的编程错误将导致应用程序不断消耗更多内存。每次使用应用程序的泄漏功能时，它都会将一些对象留在Java堆空间中。随着时间的推移，泄漏的对象会消耗所有可用的Java堆空间，并触发已经熟悉的java.lang.OutOfMemoryError：Java堆空间错误 。
内存泄漏代码示例
第一个例子非常简单–下面的Java代码尝试分配一个2M整数数组。当您编译它并使用12MB的Java堆空间（Java -Xmx12m -OOM）启动时，它将失败java.lang.OutOfMemoryError：Java堆空间消息。有了13MB的Java堆空间，程序运行得很好。
class OOM {
static final int SIZE=2*1024*1024;
public static void main(String[] a) {
int[] i = new int[SIZE];
}
}第二个也是更现实的例子是内存泄漏在Java中，当开发人员创建和使用新的对象（如 new Integer（5） ）时，他们不必自己分配内存—这是由Java虚拟机（JVM）负责的。在应用程序的生命周期中，JVM会定期检查内存中哪些对象仍在使用，哪些对象没有使用。未使用的对象可以丢弃，内存可以回收并再次使用。这个过程称为垃圾回收。JVM中负责收集的相应模块称为垃圾收集器（GC）。
Java的自动内存管理依赖于GC定期查找未使用的对象并将其删除。简单地说，java内存泄露是指应用程序不再使用某些对象，但垃圾回收无法识别它的情况。因此，这些未使用的对象将无限期地保留在Java堆空间中。这起连环碰撞最终会触发java.lang.OutOfMemoryError：Java堆空间错误。
构建一个满足内存泄漏定义的Java程序相当容易：
class KeylessEntry {
static class Key {
Integer id;
Key(Integer id) {
this.id = id;
}
@Override
public int hashCode() {
return id.hashCode();
}
}
public static void main(String[] args) {
Map m = new HashMap();
while (true)
for (int i = 0; i < 10000; i++)
if (!m.containsKey(new Key(i)))
m.put(new Key(i), "Number:" + i);
}
}当您执行上面的代码时，您可能希望它永远运行而不会出现任何问题，假设天真的缓存解决方案只将底层映射扩展到10000个元素，除此之外，所有的键都已经存在于HashMap中。但是，实际上，由于Key类在 hashCode() 旁边没有适当的 equals() 实现，所以元素将继续被添加。
结果，随着时间的推移，随着泄漏代码的不断使用，“缓存”结果最终会消耗大量Java堆空间。当***存填满堆区域中的所有可用内存，而垃圾回收无法清理它时java.lang.OutOfMemoryError：引发Java堆空间 。
解决方案很简单–添加与下面类似的 equals() 方法的实现，您就可以开始了。但在你找到病因之前，你肯定会失去一些珍贵的脑细胞。
@Override
public boolean equals(Object o) {
boolean response = false;
if (o instanceof Key) {
response = (((Key)o).id).equals(this.id);
}
return response;
}内存溢出怎么解决?
在某些情况下，分配给JVM的堆的数量不足以满足在JVM上运行的应用程序的需要。在这种情况下，您应该只分配更多的堆—请参阅本章末尾的部分了解如何实现这一点。
然而，在许多情况下，提供更多的Java堆空间并不能解决问题。例如，如果应用程序包含内存泄漏，则添加更多堆只会推迟java.lang.OutOfMemoryError：Java堆空间错误。此外，增加Java堆空间量也会增加GC暂停的长度，从而影响应用程序的吞吐量或延迟。
如果您希望解决Java堆空间的底层问题，而不是掩盖症状，那么您需要找出代码的哪一部分负责分配最多的内存。换句话说，你需要回答以下问题：
- 哪些对象占据堆的大部分
- 在源代码中分配这些对象
在这一点上，一定要在你的日历中清除几天（或者-在项目符号列表下面自动查看）。下面是一个粗略的流程大纲，可以帮助您回答上述问题：
- 获得安全许可，以便从JVM执行堆转储。“ dump 转储”基本上是堆内容的快照，您可以对其进行分析。因此，这些快照可能包含机密信息，如密码、信用卡号码等，因此出于安全原因，获取此类转储甚至可能不可能。
- 在适当的时候把垃圾处理掉。准备好获取一些转储，因为当在错误的时间执行时，堆转储包含大量的噪声，实际上可能是无用的。另一方面，每个堆转储都会完全“freezes 冻结”JVM，所以不要占用太多，否则最终用户将面临性能问题。
- 找一台能装垃圾的机器。当您的JVM使用例如8GB的堆时，您需要一台大于8GB的机器来分析堆内容。启动转储分析软件（我们推荐Eclipse MAT，但也有同样好的替代品）。
- 检测堆的最大使用者的GC根路径。我们在这里的另一篇文章中讨论了这一活动。这对初学者来说尤其困难，但实践将使你了解结构和导航机制。
- 接下来，您需要弄清楚源代码中潜在危险的大量对象被分配到哪里。如果您对应用程序的源代码有很好的了解，那么您将能够在几次搜索中做到这一点。
或者，我们建议使用plumber，这是唯一一个具有自动根本原因检测功能的Java监控解决方案。在其他性能问题中，它包罗万象java.lang.OutOfMemoryErrors并自动为您提供有关最需要内存的数据结构的信息。
Plumber负责在后台收集必要的数据——这包括关于堆使用情况的相关数据（只有对象布局图，没有实际数据），还有一些甚至在堆转储中都找不到的数据。它还为您执行必要的数据处理—在运行中，只要JVM遇到java.lang.OutOfMemoryError. 这里有一个例子java.lang.OutOfMemoryError管道工事故警报：
无需任何其他工具或分析，您可以看到：
- 哪些对象消耗的内存最多
- 在哪里分配这些对象（它们中的大多数在MetricManagerImpl类中分配，第304行）
- 当前引用这些对象的是什么（到GC根的完整引用链）
有了这些信息，您就可以放大潜在的根本原因，并确保将数据结构缩减到适合您的内存池的级别。
然而，当您从内存分析或阅读plumber报告得出的结论是内存使用是合法的，并且源代码中没有什么可更改的，那么您需要允许JVM有更多的Java堆空间来正常运行。在这种情况下，更改JVM启动配置并添加（或增加值，如果存在）：
-Xmx1024m上述配置将为应用程序提供1024MB的Java堆空间。可以使用g或g表示GB，m或m表示MB，k或k表示KB。例如，以下所有内容都相当于最大Java堆空间为1GB：
java -Xmx1073741824 com.mycompany.MyClass
java -Xmx1048576k com.mycompany.MyClass
java -Xmx1024m com.mycompany.MyClass
java -Xmx1g com.mycompany.MyClass原文链接：http://javakk.com/897.html
如果觉得本文对你有帮助，可以点赞关注支持一下，也可以点进我主页关注我公众号，上面有更多技术干货文章以及相关资料共享，大家一起学习进步！
京公网安备 11010502036488号