Java 6内存使用过多 [英] Java 6 Excessive Memory Usage

问题描述

Java 6消耗的内存是否比大型应用程序所需的内存更多?

Does Java 6 consume more memory than you expect for largish applications?

我有一个已经开发了多年的应用程序，到目前为止，在我的特定测试配置中，该应用程序大约占用了30-40 MB.现在使用Java 6u10和11时，活动时需要花费数百美元.它反弹很多，大约在50M到200M之间，当它闲置时，它会执行 GC并立即降低内存.此外，它还会生成数百万个页面错误.通过Windows任务管理器可以观察到所有这些情况.

I have an application I have been developing for years, which has, until now taken about 30-40 MB in my particular test configuration; now with Java 6u10 and 11 it is taking several hundred while active. It bounces around a lot, anywhere between 50M and 200M, and when it idles, it does GC and drop the memory right down. In addition it generates millions of page faults. All of this is observed via Windows Task Manager.

因此，我将其运行在我的探查器(jProfiler)下并使用jVisualVM，它们都指示通常的中等堆和perm-gen用法相结合，大约30M，即使在我的负载测试周期中处于完全活动状态时也是如此.

So, I ran it up under my profiler (jProfiler) and using jVisualVM, and both of them indicate the usual moderate heap and perm-gen usages of around 30M combined, even when fully active doing my load-test cycle.

所以我很神秘！而且，它不仅从Windows虚拟内存池中请求更多内存，而且还显示为200M内存使用量".

So I am mystified! And it not just requesting more memory from the Windows Virtual Memory pool - this is showing up as 200M "Mem Usage".

澄清:我想对此很清楚-使用Java VisualVM在18个小时的时间内观察到，类堆和perm gen堆一直非常稳定.分配的易失性堆(eden和Tenured)保持不变，为16MB(在最初的几分钟内达到)，并且此内存的使用以从8MB均匀增长到16MB的完美模式波动，这时GC启动将其降回8MB.在这18个小时内，自从我进行压力测试以来，系统一直处于恒定的最大负载下.从许多运行中可以看出，此行为完全和一致是可重现的.唯一的异常是，当这种情况继续进行时，通过任务管理器观察到的Windows内存变化范围从64MB到900 + MB不等.

CLARIFICATION: I want to be perfectly clear on this - observed over an 18 hour period with Java VisualVM the class heap and perm gen heap have been perfectly stable. The allocated volatile heap (eden and tenured) sits unmoved at 16MB (which it reaches in the first few minutes), and the use of this memory fluctuates in a perfect pattern of growing evenly from 8MB to 16MB, at which point GC kicks in an drops it back to 8MB. Over this 18 hour period, the system was under constant maximum load since I was running a stress test. This behavior is perfectly and consistently reproducible, seen over numerous runs. The only anomaly is that while this is going on the memory taken from Windows, observed via Task Manager, fluctuates all over the place from 64MB up to 900+MB.

更新2008-12-18:我已经使用-Xms16M -Xmx16M运行该程序，而没有任何明显的不利影响-性能很好，总运行时间大致相同.但是短期内内存使用仍然达到约180M的峰值.

UPDATE 2008-12-18: I have run the program with -Xms16M -Xmx16M without any apparent adverse affect - performance is fine, total run time is about the same. But memory use in a short run still peaked at about 180M.

2009年1月21日更新:看来答案可能是线程数-请在下面查看我的答案.

Update 2009-01-21: It seems the answer may be in the number of threads - see my answer below.

我的意思是数以百万计的页面错误-在30M +左右.

And I mean millions of page faults literally - in the region of 30M+.

我有一台4G机器，所以200M在这方面并不重要.

I have a 4G machine, so the 200M is not significant in that regard.

推荐答案

在过去的几周里，我不得不调查并更正线程池对象(Java 6之前的多线程执行池)的问题，其中正在启动比所需更多的线程.在有问题的作业中，最多可能有200个不必要的线程.而且线程不断消失，有新线程替换它们.

Over the last few weeks I had cause to investigate and correct a problem with a thread pooling object (a pre-Java 6 multi-threaded execution pool), where is was launching far more threads than required. In the jobs in question there could be up to 200 unnecessary threads. And the threads were continually dying and new ones replacing them.

已经纠正了该问题，我想再次运行测试，现在看来内存消耗是稳定的(尽管比旧版JVM高20 MB左右).

Having corrected that problem, I thought to run a test again, and now it seems the memory consumption is stable (though 20 or so MB higher than with older JVMs).

所以我的结论是内存中的峰值与正在运行的线程数(数百个)有关.不幸的是，我没有时间去尝试.

So my conclusion is that the spikes in memory were related to the number of threads running (several hundred). Unfortunately I don't have time to experiment.

如果有人想尝试并用他们的结论来回答这个问题，我将接受该回答；否则，我将接受这一请求(等待2天之后).

If someone would like to experiment and answer this with their conclusions, I will accept that answer; otherwise I will accept this one (after the 2 day waiting period).

此外，页面错误率也下降了10倍.

Also, the page fault rate is way down (by a factor of 10).

此外，对线程池的修复纠正了一些争用问题.

Also, the fixes to the thread pool corrected some contention issues.

这篇关于Java 6内存使用过多的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！