我们正在研究客户的生产服务器堆，以检测和解决内存泄漏问题。为此，我们定期使用jmap来收集必要的信息。但上周我们无法进行转储，因为它触发了EOF错误并关闭了Tomcat实例。我在互联网上进行了搜索，但没有找到有关此错误的任何具体信息。我们检测到它仅在使用GcFirst时发生垃圾回收算法。这是我们用来执行jmap的命令行:jmap-dump:format=b,file=heap.bin服务器上的Java版本:JDK1.7.0_7x64有没有人遇到过这种错误？可能缺少某些配置或需要java/jmap补丁。更新我们收集到的关于此错误的更多信息:[root]#jmap-dump:format=
我想知道两者之间有什么区别或者是否相同。 最佳答案 这个问题无法回答。首先，没有任何相关规范会说明Java或.net应如何实现垃圾回收。所以在Java或.net中实际上没有“完成GC的方式”。其次，Java和.net的各个供应商之间的GC实现细节各不相同，对于任何供应商，GC可能会随着每个平台、每个主要版本、次要版本甚至每个补丁版本而变化。最重要的是，Java的某些实现允许您使用命令行选项在不同的垃圾收集器之间进行选择。最后，在Java或.net实现中如何实现GC并不重要提供它可以按应用程序的要求工作。对于Java，答案是它可以用于
我正在为我的JVM堆(Java1.7)中无法访问的对象而苦苦挣扎。从图中可以看出(图中所有类都是不可达的)，我们有超过74%的objects没有reference，所以应该是garbaggedcollected。在我们的tomcat7服务器上正常运行3周后，该状态变为仅运行Probe监控应用程序、tomcat管理器和我们的web应用程序，这可能是问题的根源。我们的应用程序基于JSF1.2，在客户端上保存状态，这就是您在下图中看到的-主要是带有ViewSaveState的字符数组。当我从jVisualVM手动运行GC时，它会删除所有无法访问的对象，一切正常，直到堆达到其限制的3周。有些对
昨天我们在一台JBoss应用服务器的服务器日志中有以下GC输出:51628.286:[GC51628.288:[ParNew:1843200K->204800K(1843200K),21.3196040secs]5177730K->3743415K(7987200K),21.3217870secs][Times:user=1.38sys=0.33,real=21.32secs]我这样理解输出:年轻一代的大小为1843200K。生成前大小为1843200K，生成后大小为204800K。收集持续了21.3秒。通常我们的年轻一代集合持续我们的JVM参数:-server-verbose:gc-
我有一个应用程序负责归档旧应用程序，它会一次处理大量应用程序，因此需要一次运行数天。当我的公司开发这个时，他们对它做了一些性能测试，他们似乎从中得到了不错的数字，但我最近一直在为一个客户运行一个存档，它似乎运行得非常慢，而且性能似乎会随着运行时间的延长而下降。似乎没有内存泄漏，因为自从我用jconsole监视它以来，仍然有大量可用内存并且似乎没有缩减。但是我注意到，幸存者空间和堆的终身代可以很快填满，直到出现垃圾收集并将其清除，这似乎发生得相当频繁，我不确定这是否是一个来源明显放缓。该应用程序现在已经运行了7天3小时，根据jconsole，它花费了6小时执行复制垃圾收集(772、611
简短形式:CMS垃圾收集器似乎无法收集越来越多的垃圾；最终，我们的JVM被填满，应用程序变得无响应。通过外部工具(JConsole或jmap-histo:live)强制GC将其清理一次。更新:问题似乎与JConsole的JTop插件有关；如果我们不运行JConsole，或者在没有JTop插件的情况下运行它，该行为就会消失。(技术说明:我们在Linux2.6.9机器上运行SunJDK1.6.0_07，32位。升级JDK版本并不是真正的选择，除非有不可避免的主要原因。此外，我们的系统未连接到可访问Internet的机器，因此JConsole的屏幕截图等不是一个选项。)我们目前正在使用以下标
举个例子，假设我将JVM的最大堆设置为4GB。但是，一旦我的应用程序达到大约3GB，操作系统就会开始将一些内存交换到磁盘。此时有几个对象已经超出范围，JVM可以首先对旧对象进行垃圾回收，而不是请求更多内存。就性能而言，运行垃圾收集比进行内存交换要好。JVM垃圾收集器是否对这种情况很聪明，或者它完全没有意识到这一点？我们能否以某种方式调整JVM来解决这种情况？我知道垃圾收集有可能在我们达到3GB之前运行，因此我们实际上永远不需要交换内存，但这并不能真正回答我的问题。编辑:假设我的机器有超过4GB的内存，但有时其他应用程序占用了部分内存，而我的内存不到4GB。我宁愿不必减少最大堆大小，因为
我对可能控制CMS收集器何时启动的两个参数感到困惑:MaxHeapFreeRatio(默认为70%)CMSInitiatingOccupancyFraction(默认超过90%)这些参数中的每一个究竟意味着什么？收集器什么时候开始(标记阶段)，收集(清理阶段)？ 最佳答案 CMSInitiatingOccupancyFraction决定CMS何时启动(为了使此选项生效，您还必须设置-XX:+UseCMSInitiatingOccupancyOnly)。MaxHeapFreeRatio是调整世代空间大小的一个选项。例如参见...htt
假设有一个类A的对象a，它持有对类B的另一个对象b的引用。这是对b的唯一引用。所以现在，如果对a的所有引用都被删除，那么a就可以进行GC了。这是否意味着b也准备好进行垃圾收集了？因为，虽然b有一个引用(在a内部)，但它是不可访问的，因为a是不可访问的。那么这个场景究竟是如何运作的呢？我的意思是垃圾收集的顺序。 最佳答案 一旦对象无法从根访问，它将被收集。参见thisquestion了解GC根的解释。假设可能无法到达该子图中的任何节点，将收集整个子图(如您所述)。Java(和.NET)使用标记和清除垃圾收集来处理此类问题。基于引用计数
我有一个服务器应用程序，在极少数情况下，它可以分配大块内存。这不是内存泄漏，因为垃圾收集器可以通过执行完整的垃圾收集来收回这些block。普通垃圾回收释放的内存量太小:在这种情况下是不够的。垃圾收集器在它认为合适的时候执行这些完整的GC，即当应用程序的内存占用接近由-Xmx指定的分配最大值时。如果不是因为这些有问题的内存分配突然出现，并且由于jvm无法足够快地执行GC以释放所需的内存。如果我事先手动调用System.gc()，我可以避免这种情况。无论如何，我宁愿不必自己监视我的jvm的内存分配(或将内存管理插入我的应用程序的逻辑)；如果有一种方法可以运行具有内存阈值的虚拟机，那将会很好
