我从事性能关键的服务器端Java应用程序。系统启动后，我预计不会创建长生命周期对象-只有短生命周期对象(最多10秒)。因此，我想调整JVM，以便在系统启动后老年代保持不变。我想我已经成功了，但我不明白为什么(见下文)。这是我们的设置:-Xmx3000m-Xms3000m-详细:gc-XX:+PrintGCTimeStamps-XX:+PrintGCDetails-XX:+UseConcMarkSweepGC-XX:SurvivorRatio=5-XX:TargetSurvivorRatio=90-XX:MaxTenuringThreshold=31-XX:+PrintTenuringD
.NET有一个名为GC.KeepAlive(Object)的函数.它的唯一目的是确保引用对象的生命周期持续到代码流到达调用为止。这通常是不必要的，除非与native代码进行互操作。我有一个情况，我有一个通过JNI访问的C++对象图，其中某些根对象需要保持Activity状态以保持子对象Activity。根对象和子对象在JVM领域都有镜像。但是，如果在C++端收集并释放根对象(通过SWIG生成的终结器)，则子对象将变得无效，因为它们的C++支持对象将被释放。这可以通过确保作为对象图根的局部变量的生命周期超过子对象的最后一次使用来解决。所以我需要一个不对对象做任何事情的惯用函数，但不会被优
我正在运行一个使用CMS作为终身收集器的Java服务器。在负载测试下运行，我大约每1秒看到一次年轻Collection，大约每5米看到一次永久(并发)。这很好。当我以大约1/2容量的实际流量运行时，我大约每4秒收集一次年轻集合，大约每7米收集一次终身收集(!并行，停止世界!)。为什么JVM决定进行完全停止世界收集而不是使用CMS收集器？从gc.log中，您可以看到“FullGC”正在运行，并且需要3秒才能完成。这里没有并发模式故障。没有明确请求集合。1350.596:[GC1350.596:[ParNewDesiredsurvivorsize119275520bytes,newthre
是否可以从gc角度将java对象标记为不可回收以节省gc-sweep时间？类似于http://wwwasd.web.cern.ch/wwwasd/lhc++/Objectivity/V5.2/Java/guide/jgdStorage.fm.html的内容特别是non-garbage-collectible容器那里(non-garbage-collectable？)。问题是我有很多普通的临时对象，但我有更大(几千兆)的对象存储用于缓存目的。JavaGC无缘无故应该遍历所有这些缓存千兆字节以试图找到任何要收集的东西，因为它们包含有自己的超时的缓存数据。这样我就可以以自定义方式将我的数据划
我的应用程序是地理应用程序。由于要求响应时间短，我的每个实例都将所有点加载到内存并将它们存储在结构(四叉树)中。我们每分钟加载所有点(与数据库同步)并将它们放入几个四叉树中。我们现在有0.5GB积分。我正在努力准备下一个级别的5GB积分。虚拟机:-XX:NewSize=6g-Xms20g-Xmx20g-XX:+UseConcMarkSweepGC-verboseGC-XX:+PrintGCTimeStamps-XX:+PrintGCDateStamps-XX:+PrintGCDetails由于GC，实例的启动花费了很多时间，另外应用程序一直受到GC的影响。我想引用大堆的GC。我能想到几
我们有以下问题:在我们的某些Linux机器上，使用trove库和G1GC的Java应用程序将很快崩溃并显示以下类型的消息:AfatalerrorhasbeendetectedbytheJavaRuntimeEnvironment:SIGSEGV(0xb)atpc=0x00002aaaaaef81d1,pid=31063,tid=1141000512JREversion:6.0_29-b11JavaVM:JavaHotSpot(TM)64-BitServerVM(20.4-b02mixedmodelinux-amd64)Problematicframe:Jgnu.trove.impl.h
有没有办法将垃圾收集信息(例如-XX:+PrintGCDetails或-verbose:gc的输出)转发到Java中的记录器应用程序(在我的例子中是sl4j+logback)？ 最佳答案 这些消息是由JVMnative进程生成的，而不是来自Java代码，因此您可以使用-Xloggc将输出重定向到文件(无旋转)Howtoredirectverbosegarbagecollectionoutputtoafile?直接通过管道传输标准输出(多个旋转选项)Logrotationofstdout?Rollinggarbagecollector
运行几个小时后，我的http服务器开始频繁进行majorgc，但没有释放任何堆。多次majorgc之后，promotionfailed和concurrentmodefailure发生，然后heap被释放。我的gc日志如下:{HeapbeforeGCinvocations=7172(full720):parnewgenerationtotal737280K,used667492K[0x000000076b800000,0x000000079d800000,0x000000079d800000)edenspace655360K,100%used[0x000000076b800000,0x0
Unity合作的Mono版本为Mono的早期版本，此时还没有使用SGenGC，后来Mono将默认GC方式改为SGenGC，Unity并没有继续购买，因此Unity使用的GC方式仍然是老的贝姆GC。贝姆GC官方网页：https://www.hboehm.info/gc/index.html1.阶段贝姆GC是一种基于标记清除法的GC方式。其整体过程可粗略分为四个阶段：准备阶段：所有对象的MarkBit重置。标记阶段：从Root出发进行扫描，将可达对象进行标记。清理阶段：扫描托管堆，将所有未标记的对象返回给对应的FreeList。Finalization阶段：所有注册了终结器的无效对象加入终结器队列
为什么他们不需要它们，如果有人决定实现使用它们的虚拟机，他们可能会面临什么问题？ 最佳答案 由于循环引用，引用计数容易发生内存泄漏。假设您有一个简单的“节点”对象，它引用了另一个节点，并假设您将其引用设置为自身。该对象的引用计数将始终为1，即使全局变量或堆栈变量中没有指向它的句柄，因此它永远不会被垃圾收集并泄漏内存。这是一个简单的例子，但任何循环引用都会有同样的问题。当然，可以检测到循环引用，但据推测这样做的开销会增加足够的复杂性，以至于其他GC方法更具吸引力。 关于java-为什么大多
