具有16GB虚拟内存并不断增长的Java程序:这有问题吗? [英] Java program with 16GB virtual memory and growing: is it a problem?

问题描述

在Mac OSX 5.8上，我有一个Java程序可以在100％CPU上运行很长时间-几天或更长时间(这是一个分析并发程序的模型检查器，因此或多或少会出现这种情况).但是，如OSX的活动监视器"中所示，其虚拟内存大小在一天左右的时间后变得巨大:现在，它已达到16GB，并且还在不断增长.物理内存使用率大致稳定在1.1GB左右.

On Mac OSX 5.8 I have a Java program that runs at 100% CPU for a very long time -- several days or more (it's a model checker analyzing a concurrent program, so that's more or less expected). However, its virtual memory size, as shown in OSX's Activity Monitor, becomes enormous after a day or so: right now it's 16GB and growing. Physical memory usage is roughly stable at 1.1GB or so.

我想知道:16GB(并且正在增长)是否是可能会减慢我的程序速度的问题的征兆?

I would like to know: is the 16GB (and growing) a sign of problems that could be slowing my program?

I start the program with "java -Xmx1024m -ea"

java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07-334-9M3326)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02-334, mixed mode)

---

感谢大家的建议.我将尝试一些答案中给出的概要分析建议，然后再返回(由于运行时间较长，可能要花一些时间).

---

Thanks to everyone for their suggestions. I will try the profiling suggestions given in some of the answers and come back (it may take a while because of the multi-day run times).

为回答以下几点，模型检查器几乎不执行任何I/O(仅打印语句，具体取决于调试设置).在我使用的模式下，它没有GUI.我不是模型检查器的主要作者(尽管我已经研究了模型检查器的某些内部组件)，但是我不相信它会使用JNI.[< ---这是错误的，下面有详细说明]它不执行任何内存映射.另外，我也不要求Oracle/Sun的JVM创建很多线程(请参阅下面的说明).

In answer to some of the points below, the model checker does almost no I/O (only print statements, depending on the debug settings). In the mode I'm using it has no GUI. I am not the primary author of the model checker (though I have worked on some of its internals), but I do not believe that it makes any use of JNI.[<--- edit: this is wrong, details below] It does not do any memory mapping. Also, I am not asking Oracle/Sun's JVM to create lots of threads (see below for an explanation).

额外的虚拟内存并未导致模型检查器死亡，但是根据打印输出的频率，随着虚拟内存使用量的增加，它逐渐越来越慢地运行.(不过，这也许是由于越来越多的垃圾收集所致.)我计划在星期一在Windows计算机上进行尝试，看看是否会发生相同的问题.

The extra virtual memory has not caused the model checker to die, but based on the frequency of the printing output it gradually runs more and more slowly as the virtual memory usage increases. (Perhaps that is just because of more and more garbage collection, though.) I plan to try it on a Windows machine on Monday to see if the same problem happens.

一些额外的解释:我正在运行的模型检查器(JPF)本身是一个几乎完整的JVM(完全用Java编写)，可以在Oracle/Sun的JVM下运行.当然，作为虚拟机，JPF高度专业化以支持模型检查.

A little extra explanation: The model checker I'm running (JPF) is itself a nearly complete JVM (written entirely in Java) that runs under Oracle/Sun's JVM. Of course, as a virtual machine, JPF is highly specialized to support model checking.

这有点违反直觉，但这意味着即使我正在模型检查的程序被设计为多线程的，就Sun的JVM而言，也只有一个线程:一个正在运行的JPF.JPF模拟了我的程序在其模型检查过程中需要的线程.

It's a bit counterintuitive, but this means that even though the program I'm model checking is designed to be multithreaded, as far as Sun's JVM is concerned there is only a single thread: the one running JPF. JPF emulates the threads my program needs as part of its model checking process.

我相信Stephen C指出了问题所在；罗兰·伊利格(Roland Illig)给了我验证的工具.我对使用JNI错了.JPF本身不使用JNI，但它允许插件，并且JNI已被配置的插件之一使用.幸运的是，我可以使用等效的纯Java插件.初步使用其中之一显示在最近几个小时内虚拟内存没有增长.感谢大家的帮助.

I believe that Stephen C has pinpointed the problem; Roland Illig gave me the tools to verify it. I was wrong about the use of JNI. JPF itself doesn't use JNI, but it allows plugins and JNI was used by one of the configured plugins. Fortunately there are equivalent plugins I can use that are pure Java. Preliminary use of one of them shows no growth in virtual memory over the last few hours. Thanks to everyone for their help.

推荐答案

我怀疑这也是泄漏.但这不能是普通"内存的泄漏，因为-Xmx1024m选项限制了普通堆的容量.同样，这不会是"permgen"堆的泄漏，因为permgen的默认最大大小很小.

I suspect that it is a leak too. But it can't be a leak of 'normal' memory because the -Xmx1024m option is capping the normal heap. Likewise, it won't be a leak of 'permgen' heap, because the default maximum size of permgen is small.

所以我怀疑它是以下之一:

So I suspect it is one of the following:

• 您正在泄漏线程；即正在创建线程，但没有终止.它们可能未处于活动状态，但是每个线程都有一个堆栈段(默认为256k至1Mb，具体取决于平台)，该段未在常规堆中分配.

• You are leaking threads; i.e. threads are being created but are not terminating. They might not be active, but each thread has a stack segment (256k to 1Mb by default ... depending on the platform) that is not allocated in the regular heap.

您正在泄漏直接映射的文件.这些映射到由OS在常规堆之外分配的内存段.(@bestsss建议您寻找泄漏的ZIP文件句柄，我认为这是其中的一个子案例.)

You are leaking direct-mapped files. These are mapped to memory segments allocated by the OS outside of the regular heap. (@bestsss suggests that you look for leaked ZIP file handles, which I think would be a sub-case of this.)

您正在使用一些泄漏内存分配的内存或类似内容的JNI/JNA代码.

You are using some JNI / JNA code that is leaking malloc'ed memory, or similar.

无论哪种方式，内存分析器都有可能隔离问题，或者至少消除某些可能性.

Either way, a memory profiler is likely to isolate the problem, or at least eliminate some of the possibilities.

JVM内存泄漏也是有可能的，但是开始怀疑JVM是不明智的，除非您明确地消除了自己正在使用的代码和库/应用程序中的可能原因.

A JVM memory leak is also a possibility, but it is unwise to start suspecting the JVM until you have definitively eliminated possible causes in your own code and libraries / applications that you are using.

这篇关于具有16GB虚拟内存并不断增长的Java程序:这有问题吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！