Tag: garbage collection

如何降低GC期间的弱ref处理时间？

目前我遇到的问题是我的应用程序偶尔会显示很长的GC时间，但所有这些只是由弱参考处理引起的。 所以线程停止的时间总是接近弱的ref处理时间。 所有其他GC循环均为0.0001秒至0.200秒。 从gc.log（重新格式化）： 10388.186: [GC[YG occupancy: 206547 K (306688 K)]10388.186: [Rescan (parallel) , 0.1095860 secs]10388.295: [weak refs processing, 2.0799570 secs] [1 CMS-remark: 2973838K(3853568K)] 3180386K(4160256K), 2.1899230 secs] [Times: user=2.51 sys=0.00, real=2.18 secs] Total time for which application threads were stopped: 2.1906890 seconds 目前我已经有了这些设置。 尝试更简单的设置，但没有变化。 -Xms4g -Xmx4g -XX:NewSize=128m -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:MaxGCPauseMillis=50 -XX:CMSInitiatingOccupancyFraction=50 -XX:ParallelGCThreads=16 -XX:+DisableExplicitGC 如果我打开NewSize，我最终会得到很长的正常GC循环。 该机器有8个内核，并没有为应用程序烧掉那么多的CPU。 […]

Java G1 GC Processing Reference对象运行缓慢

我在Java上运行了反击。 它工作24小时，每秒约100次。 在白天，GC处理时间从20-60毫秒缓慢上升到10000-60000毫秒，然后下降到20-60毫秒。 这种模式不时重复。 从GC日志中我发现GC主要用于处理Reference对象（Ref Proc）。 那么这么长的GC时间的原因是什么？ Server: Amazon EC2 m1.small OS: Ubuntu 10.04.3 LTS Java: Oracle 1.7.0_07 GC日志示例： 2012-09-13T16:51:20.091+0400: 167239.936: [GC pause (young), 62.58395400 secs] … [Other: 62489.7 ms] [Choose CSet: 0.0 ms] [Ref Proc: 62433.9 ms] [Ref Enq: 0.0 ms] [Free CSet: 0.7 ms] [Eden: 200M(200M)->0B(199M) Survivors: 4096K->5120K Heap: 578M(1024M)->380M(1024M)] 时间 – “Ref […]

Java运行时环境检测到致命错误：pc = 0x00002b2f7e9b2744处的SIGSEGV（0xb），pid = 28778，tid = 1138739520

执行程序时出现以下错误。 这并不总是发生。 该代码包含一些具有大量数据的复杂计算。 有人可以帮助识别错误 # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00002b2f7e9b2744, pid=28778, tid=1138739520 # # JRE version: 7.0-b147 # Java VM: Java HotSpot(TM) 64-Bit Server VM (21.0-b17 mixed mode linux-amd64 compressed oops) # Problematic frame: # V [libjvm.so+0x64e744] PhaseIdealLoop::clone_loop(IdealLoopTree*, Node_List&, int, Node*)+0xe34 # […]

“伊甸园空间”的名字来源于垃圾收集

在垃圾收集术语中，为什么称为“伊甸园空间”？ 就像那样。 我仍然熟悉这个术语，我无法理解为什么它有这样的名字。

如何重现Java OutOfMemoryError – 超出了GC开销限制

我的方法是创建十万个本地集合并用随机字符串填充它们，如下所示： SecureRandom random = new SecureRandom(); for(int i = 0 ; i < 100000 ; i++){ HashMap map = new HashMap(); for(int j = 0 ; j < 30 ; j++){ map.put(new BigInteger(130, random).toString(32), new BigInteger(130, random).toString(32)); } } 我也提供了-XX：+ UseGCOverheadLimit jvm参数，但无法获取错误。 是否有任何简单可靠的方法/黑客来获取此错误？

隐形引用在最近的JVM中仍然是一个问题吗？

我正在阅读Java平台性能 （遗憾的是，因为我最初提出这个问题，链接似乎已经从互联网上消失了），而A.3.3节让我很担心。 我一直在假设退出范围的变量不再被视为GC根，但本文似乎与此相矛盾。 最近的JVM，特别是Sun的1.6.0_07版本，仍然有这个限制吗？ 如果是这样，那么我有很多代码要分析…… 我问这个问题是因为这篇论文是从1999年开始的 – 有时情况发生了变化，特别是在GC世界。 由于论文不再可用，我想解释一下这个问题。 本文暗示，在方法退出之前，在方法中定义的变量将被视为GC根，而不是直到代码块结束。 因此，必须将变量设置为null，以允许引用的Object被垃圾回收。 这意味着在main（）方法中的条件块中定义的局部变量（或包含无限循环的类似方法）将导致一次性内存泄漏，除非在它退出范围之前将变量置为空。 所选答案的代码很好地说明了这个问题。 在文档中引用的JVM版本中，当foo对象在try块结束时超出范围时，不能对其进行垃圾回收。 相反，JVM将保持打开引用直到main（）方法结束，即使任何东西都不可能使用该引用。 这似乎是一个想法的起源，即使变量即将退出范围，将变量引用置零将有助于垃圾收集器输出。

缓存（）/ persist（）的apache-spark内存消耗

当我尝试缓存（）或持久化（MEMORY_ONLY_SER（））我的RDD时，我的spark簇会挂起。 它工作得很好，并在大约7分钟内计算结果。 如果我不使用cache（）。 我有6个c3.xlarge EC2实例（4个内核，每个7.5 GB RAM），共有24个内核和37.7 GB。 我在master上使用以下命令运行我的应用程序： SPARK_MEM = 5g MEMORY_FRACTION =“0.6”SPARK_HOME =“/ root / spark”java -cp ./uber-offline.jar:/root/spark/assembly/target/scala-2.10/spark-assembly_2.10-0.9.0-孵化-hadoop1.0.4.jar pl.instream.dsp.offline.OfflineAnalysis 数据集大约有50GB的数据分成24个文件。 我将其压缩并存储在S3存储桶中的24个文件中（每个文件大小为7MB到300MB）。 我绝对找不到我的集群这种行为的原因，但似乎火花消耗了所有可用内存并进入了GC收集循环。 当我查看gc verbose时，我可以找到如下的循环： [GC 5208198K(5208832K), 0,2403780 secs] [Full GC 5208831K->5208212K(5208832K), 9,8765730 secs] [Full GC 5208829K->5208238K(5208832K), 9,7567820 secs] [Full GC 5208829K->5208295K(5208832K), 9,7629460 secs] [GC 5208301K(5208832K), 0,2403480 secs] [Full GC 5208831K->5208344K(5208832K), 9,7497710 secs] [Full […]

Java堆被无法访问的对象所淹没

我们已经开始在Java EE应用程序中遇到一些严重问题。 具体来说，应用程序在启动后几分钟内运行高达99％的旧代堆。 没有抛出OOM，但JVM实际上没有响应。 jstat显示老一代的大小根本没有减少，没有垃圾收集，kill -3说： Heap PSYoungGen total 682688K, used 506415K [0xc1840000, 0xf3840000, 0xf3840000) eden space 546176K, 92% used [0xc1840000,0xe06cd020,0xe2da0000) from space 136512K, 0% used [0xe2da0000,0xe2da0000,0xeb2f0000) to space 136512K, 0% used [0xeb2f0000,0xeb2f0000,0xf3840000) PSOldGen total 1536000K, used 1535999K [0x63c40000, 0xc1840000, 0xc1840000) object space 1536000K, 99% used [0x63c40000,0xc183fff8,0xc1840000) VM选项包括： -Xmx2300m -Xms2300m -XX:NewSize=800m -XX:MaxNewSize=800m -XX:SurvivorRatio=4 -XX:PermSize=256m -XX:MaxPermSize=256m […]

当20％的堆仍然是免费的时，为什么我会得到OutOfMemory？

我已将最大堆设置为8 GB。 当我的程序开始使用大约6.4 GB（在VisualVM中报告）时，垃圾收集器开始占用大部分CPU，并且在进行~100 MB分配时程序与OutOfMemory崩溃。 我在Windows上使用Oracle Java 1.7.0_21。 我的问题是，是否有GC选项可以帮助解决这个问题。 除了-Xmx8g，我没有传递任何东西。 我的猜测是堆已经碎片化了，但GC应该不紧凑吗？

垃圾收集器（.net / java）是实时系统的问题吗？

在构建需要非常一致且快速响应的系统时，垃圾收集器是否存在潜在问题？ 我记得多年前的恐怖故事，其中典型的例子总是一个动作游戏，你的角色会在跳跃中停留几秒钟，当垃圾收集器进行清理时。 我们还需要几年时间，但我想知道这是否还是个问题。 我读到了.Net 4中的新垃圾收集器，但它看起来仍然像一个大黑盒子，你只需要相信一切都会好的。 如果你有一个总是必须快速响应的系统，有一个垃圾收集器太大问题，选择更硬核更好，控制它自己像c ++这样的语言？ 我讨厌它，如果事实certificate是一个问题，除了等待新版本的运行时或做一些非常奇怪的事情试图影响收集器之外，基本上几乎没有什么可以做的。 编辑 感谢所有的宝贵资源。 但是，似乎大多数文章/自定义gc /解决方案都与Java环境有关。 .Net是否还具有自定义GC的调整function或选项？