Question

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

-Xms12036M -Xmx12036M -Xmn800M

对这些价值观有什么建议吗？我认为GC会照顾它，但老一代但似乎不是。我是Java的新手，不确定这是否表明内存泄漏或GC是否没有这样做？

Answer 1

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

Answer 2

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

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

了解优势与优势各种GC algorithms

的弱点

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

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

看一下这篇文章：

Answer 3

GC of the JVM is just response for objects which are not referenced by your main program,(included "reference cycle") ,

If there are many objects in the Heap can not be collected by GC, which caused OOM,two possibility :

those objects are logically needed by your program :
you need to add memory resource,or need to change the process of your program to avoid using huge amounts of memory resource.
those objects are logically not needed,but still referenced by your main program , (ex:object were not needed ,but didn't removed from the list): it's memory leak in java ,it's a bug ,you must fix it in your program .

try to use some profiling tool ,or trace your code to figure out is it a memory leak issue .

Answer 4

对于12GB的堆，-Xmn800M（800MB年轻代）看起来相当低。考虑直接杀死该参数并仅保留-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。留意单调增长的物体。