使用G1收集器时，是否有人在使用JVM（Hotspot）泄漏内存时遇到问题？
我已经将堆大小修复为60GB（-ms和-ms都设置为60G），但java进程的大小（根据ps命令的vsz列）开始时大约为64GB，但是在7小时内增加到84GB。
使用并行收集器，过程大小在20小时内保持稳定，大约65GB左右。
有没有其他人与G1收藏家有类似的问题？我正在运行一个非常简单的基准测试，而且我没有使用任何直接缓冲内存或其他堆外内存（我知道）。
Java版本是1.7.0，更新5
（我已经向甲骨文提出了一个关于此问题的错误，但我认为如果有人有解决方法，我也会在这里查看。）
答案 0 :(得分：1)
有没有其他人与G1收藏家有类似的问题？
很快 - 是的。
这是关于导致内存泄漏的主题：
Creating a memory leak with Java
它包含有关 G1
的信息使用InflaterInputStream传递新的java.util.zip.Inflater（） c-tor（例如PNGImageDecoder）而不是调用end（） 吹气。好吧，如果你传递c-tor w /只是新的，没有机会......和 是的，在流上调用close（）不会关闭inflater（如果是的话） 手动传递为c-tor参数。这不是真正的泄漏，因为它 终结者发布......当它认为有必要时。直到那 那一刻它吃本机内存如此糟糕，它可能导致linux oom_killer 杀死这个过程而不受惩罚。主要问题是最终确定 java非常不可靠，G1在7.0.2之前变得更糟。道德的 故事：尽快发布原生资源，终结者是 太穷了。
泄漏也在这里提到：http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7152954