Java老年代一直在增长，直到Tomcat重新启动答案

【问题标题】：Java old generation keeps growing until Tomcat restartsJava老年代一直在增长，直到Tomcat重新启动
【发布时间】：2015-10-29 15:02:25
【问题描述】：

我在多台服务器上安装了 JDK 8，并且堆大小不断增加，直到达到 90% 并且应用程序失败。在此期间，多个 GC 运行，但老年代不断增长，直到应用程序失败。当前的解决方法是重新启动 Tomcat。我的服务器有 15GB RAM，4 核 CPU。我的 Java 设置是：

-Xms12036M -Xmx12036M -Xmn800M

对这些值有什么建议吗？我以为 GC 会处理它，但老一代却似乎没有。我是 Java 新手，不确定这是否表明内存泄漏或 GC 没有执行此操作？

【问题讨论】：

【解决方案1】：

首先使用 JStacks/JMaps、线程转储和内存分析器工具检查内存泄漏。如果您的系统内存没有任何泄漏，则必须微调垃圾收集器算法。

Java 提供了不同类型的垃圾收集器。

看看各种GC algorithms的优缺点

串行收集器：串行收集器是最简单的一种，您可能不会使用它，因为它主要是为单线程环境设计的。
并行/吞吐量收集器：它最大的优点是使用多个线程扫描并压缩堆。并行收集器的缺点是它会在执行次要或完整 GC 收集时停止应用程序线程。
CMS 收集器：此算法使用多个线程（“并发”）在堆（“标记”）中扫描可回收（“扫描”）的未使用对象。如果您增加老年代（或整个堆）的大小或为收集器分配更多后台线程，这将是有效的。它使用更多的 CPU 以便为应用程序提供更高水平的连续吞吐量。
G1 收集器：JDK 7 更新 4 中引入的垃圾优先收集器 (G1) 旨在更好地支持大于 4GB 的堆。 G1 收集器利用多个后台线程来扫描它划分为区域的堆，范围从 1MB 到 32MB（取决于堆的大小）。使用 –XX:+UseG1GC 标志。

如果您使用 G1 收集器，则必须微调区域大小参数。如果 15 GB 是您的堆大小，那么您的区域大小应该是 (15 GB / 2048 ) MB，大约是 7 MB。不要在 New Gen Size 上进行更多试验。您可以坚持使用默认设置，因为此算法使用默认值提供最佳性能。

看看这篇文章：

【讨论】：

【解决方案2】：

我认为您的参数没有问题。我建议在你的代码中寻找内存泄漏。使用分析器是个好主意，但您也可以寻找泄漏模式。这里有一个很好的合集：Creating a memory leak with Java

【讨论】：

【解决方案3】：

JVM的GC只是对你的主程序没有引用的对象的响应，（包括“引用循环”），

如果Heap中有很多对象不能被GC回收，导致OOM，有两种可能：

您的程序在逻辑上需要这些对象：
您需要添加内存资源，或者需要更改程序的进程以避免使用大量内存资源。
这些对象在逻辑上是不需要的，但仍被您的主程序引用，（例如：不需要对象，但没有删除从列表中）： 这是java中的内存泄漏，这是一个错误，你必须在你的程序中修复它。

尝试使用一些分析工具，或跟踪您的代码以确定它是否是内存泄漏问题。

【讨论】：

【解决方案4】：

-Xmn800M（800MB 年轻代）对于 12GB 堆来说似乎是一个相当低的值。考虑直接取消该参数并仅保留 -Xms12036M -Xmx12036M 参数。

请注意，您的老年代将继续增长，直到运行完整的 GC。您将有许多次要 GC，它们会在前 800MB 上执行 GC，但不会在剩余的 11.2GB 上执行 GC。因此，请尝试compare heap dumps using something the Eclipse Memory Analysis Tool。另外，请尝试grab a few different heap dumps。留意大小单调增长的对象。

【讨论】：