昨天中午的时候, 团队的兄弟找我看一个现象: 原先因为堆外内存使用过多会crash掉的java应用, 设置了最大堆外内存量(MaxDirectMemorySize)后jvm不会crash, 但出现了机器的两颗CPU全部被占满, 而且java程序没有响应的情况.
我用jstat -gc/-gcutil/-gccause查了一下当时gc的情况, 发现出现过CMS GC, 最后一次导致GC的原因是CMS final remark, 没有什么异常. 新生代和旧生代占用量都比较少, survior的from与to区域都正常. 这就比较诡异了, 如果因为堆外内存超出了MaxDirectMemorySize设置的值, 那会抛出OOM, 但这个没有抛出.
检查了DisableExplicitGC参数,是否关闭了显式GC, 结果没有关闭. 这就更说不通了.
于是我转向调查CPU使用率为什么这么高. 用top查了一下CPU有几个jvm的线程(top运行后, 用shift + h开启线程观察)占着CPU, 线程的ID分别是: 38024, 38025, 38026, 38027.
然后采用pstack查看这几个线程究竟在干什么. pstack了好几次, 每次这些线程的stack都差不多, 如下:
引用
Thread 220 (Thread 0x40b4c940 (LWP 38024)):
#0 0x00007f1444751b60 in SpinPause@plt () from /opt/taobao/install/jdk-1.6.0_26/jre/lib/amd64/server/libjvm.so
#1 0x00007f14447fbf09 in ParallelTaskTerminator::offer_termination() () from /opt/taobao/install/jdk-1.6.0_26/jre/lib/amd64/server/libjvm.so
#2 0x00007f1444c7fa87 in CMSRefProcTaskProxy::do_work_steal(int, CMSParDrainMarkingStackClosure*, CMSParKeepAliveClosure*, int*) () from /opt/taobao/install/jdk-1.6.0_26/jre/lib/amd64/server/libjvm.so
#3 0x00007f1444c776e5 in CMSRefProcTaskProxy::work(int) () from /opt/taobao/install/jdk-1.6.0_26/jre/lib/amd64/server/libjvm.so
#4 0x00007f1444b40e2a in GangWorker::loop() () from /opt/taobao/install/jdk-1.6.0_26/jre/lib/amd64/server/libjvm.so
#5 0x00007f1444af8e98 in GangWorker::run() () from /opt/taobao/install/jdk-1.6.0_26/jre/lib/amd64/server/libjvm.so
#6 0x00007f1444af8278 in java_start(Thread*) () from /opt/taobao/install/jdk-1.6.0_26/jre/lib/amd64/server/libjvm.so
#7 0x000000375560677d in start_thread () from /lib64/libpthread.so.0
#8 0x0000003754ed49ad in clone () from /lib64/libc.so.6
Thread 219 (Thread 0x40708940 (LWP 38025)):
#0 0x0000003754ebb5a7 in sched_yield () from /lib64/libc.so.6
#1 0x00007f1444a267e9 in ParallelTaskTerminator::yield() () from /opt/taobao/install/jdk-1.6.0_26/jre/lib/amd64/server/libjvm.so
#2 0x00007f14447fbfc9 in ParallelTaskTerminator::offer_termination() () from /opt/taobao/install/jdk-1.6.0_26/jre/lib/amd64/server/libjvm.so
#3 0x00007f1444c7fa87 in CMSRefProcTaskProxy::do_work_steal(int, CMSParDrainMarkingStackClosure*, CMSParKeepAliveClosure*, int*) () from /opt/taobao/install/jdk-1.6.0_26/jre/lib/amd64/server/libjvm.so
#4 0x00007f1444c776e5 in CMSRefProcTaskProxy::work(int) () from /opt/taobao/install/jdk-1.6.0_26/jre/lib/amd64/server/libjvm.so
#5 0x00007f1444b40e2a in GangWorker::loop() () from /opt/taobao/install/jdk-1.6.0_26/jre/lib/amd64/server/libjvm.so
#6 0x00007f1444af8e98 in GangWorker::run() () from /opt/taobao/install/jdk-1.6.0_26/jre/lib/amd64/server/libjvm.so
#7 0x00007f1444af8278 in java_start(Thread*) () from /opt/taobao/install/jdk-1.6.0_26/jre/lib/amd64/server/libjvm.so
#8 0x000000375560677d in start_thread () from /lib64/libpthread.so.0
#9 0x0000003754ed49ad in clone () from /lib64/libc.so.6
Thread 218 (Thread 0x40a3c940 (LWP 38026)):
#0 0x00007f1444751b60 in SpinPause@plt () from /opt/taobao/install/jdk-1.6.0_26/jre/lib/amd64/server/libjvm.so
#1 0x00007f14447fbf09 in ParallelTaskTerminator::offer_termination() () from /opt/taobao/install/jdk-1.6.0_26/jre/lib/amd64/server/libjvm.so
#2 0x00007f1444c7fa87 in CMSRefProcTaskProxy::do_work_steal(int, CMSParDrainMarkingStackClosure*, CMSParKeepAliveClosure*, int*) () from /opt/taobao/install/jdk-1.6.0_26/jre/lib/amd64/server/libjvm.so
#3 0x00007f1444c776e5 in CMSRefProcTaskProxy::work(int)() from /opt/taobao/install
/jdk-1.6.0_26/jre/lib/amd64/server/libjvm.so
#4 0x00007f1444b40e2a in GangWorker::loop() () from /opt/taobao/install/jdk-1.6.0_26/jre/lib/amd64/server/libjvm.so
#5 0x00007f1444af8e98 in GangWorker::run() () from /opt/taobao/install/jdk-1.6.0_26/jre/lib/amd64/server/libjvm.so
#6 0x00007f1444af8278 in java_start(Thread*) () from /opt/taobao/install/jdk-1.6.0_26/jre/lib/amd64/server/libjvm.so
#7 0x000000375560677d in start_thread () from /lib64/libpthread.so.0
#8 0x0000003754ed49ad in clone () from /lib64/libc.so.6
Thread 217 (Thread 0x40277940 (LWP 38027)):
#0 0x00007f1444871b29 in SpinPause () from /opt/taobao/install/jdk-1.6.0_26/jre/lib/amd64/server/libjvm.so
#1 0x00007f14447fbf09 in ParallelTaskTerminator::offer_termination() () from /opt/taobao/install/jdk-1.6.0_26/jre/lib/amd64/server/libjvm.so
#2 0x00007f1444c7fa87 in CMSRefProcTaskProxy::do_work_steal(int, CMSParDrainMarkingStackClosure*, CMSParKeepAliveClosure*, int*) () from /opt/taobao/install/jdk-1.6.0_26/jre/lib/amd64/server/libjvm.so
#3 0x00007f1444c776e5 in CMSRefProcTaskProxy::work(int) () from /opt/taobao/install/jdk-1.6.0_26/jre/lib/amd64/server/libjvm.so
#4 0x00007f1444b40e2a in GangWorker::loop() () from /opt/taobao/install/jdk-1.6.0_26/jre/lib/amd64/server/libjvm.so
#5 0x00007f1444af8e98 in GangWorker::run() () from /opt/taobao/install/jdk-1.6.0_26/jre/lib/amd64/server/libjvm.so
#6 0x00007f1444af8278 in java_start(Thread*) () from /opt/taobao/install/jdk-1.6.0_26/jre/lib/amd64/server/libjvm.so
#7 0x000000375560677d in start_thread () from /lib64/libpthread.so.0
#8 0x0000003754ed49ad in clone () from /lib64/libc.so.6
一眼就可以看出这些都是CMS GC的线程. 他们都停留在CMSRefProcTaskProxy::work下, GC的stack看上去还正常.奇怪的是为什么这么占CPU, 看样子一直在自旋(spin)或yield, 貌似在等待啥状态完成. 自旋锁是占CPU的利器.
要了一份gc log后, 看看gc log是否有啥线索. 发现一个非常诡异的地方:
引用
2012-10-30T11:44:56.808+0800: 2603.044: [CMS-concurrent-mark: 0.314/0.374 secs] [Times: user=0.45 sys=0.02, real=0.37 secs]
2012-10-30T11:44:56.808+0800: 2603.044: [CMS-concurrent-preclean-start]
2012-10-30T11:44:56.811+0800: 2603.047: [CMS-concurrent-preclean: 0.003/0.003 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
2012-10-30T11:44:56.811+0800: 2603.047: [GC[YG occupancy: 13211 K (917504 K)]2603.047: [Rescan (parallel) , 0.0113650 secs]2603.059: [weak refs processing
GC log没有remark, 更没有sweep阶段, 停留在了weak refs processing. 这一阶段正在回收弱引用, 属于remark阶段的一部分, 所以会暂停java应用(stop the world)的. 日志与pstack正好吻合, 正在做处理引用 (CMSRefProcTaskProxy).但处理引用, 为什么会使jvm hang住, 并且不停地自旋等待某状态完成呢?
我用google查了一下, OTN上有两个人碰到了相同的问题:
链接一 链接二
从上面的两个链接上看, 没有人能解释这个现象. 但有一个线索, 可以解决这个问题:
引用
Thank you for the advice. Unfortunatly, we are tied to old UTF behaviour which has been changed since 6u11. But, we have turned off ParallelRefProcEnabled and it looks like it helps. So, we are staing with it.
把ParallelRefProcEnabled参数给关闭就可以解决这个问题. 这是并行处理引用的参数,可以使用多GC线程处理引用. 我用
java -XX:+PrintFlagsFinal | grep ParallelRefProcEnabled
查看了一下, 它的默认值是false, 也就是默认关闭了. 向应用方要了一份JVM参数后发现, 线上这个参数是开着的.
开启这个参数为什么会使CMSRefProcTaskProxy一直在自旋, 从而停止Java应用, 并用占用所有的CPU资源呢? 再次请教google大神, 用”ParallelRefProcEnabled hang”发现了这个
jvm的bug, 上面写着
引用
The CMSRefProcTaskProxy object needs its terminator object to be initialized to the correct number of threads. Otherwise, you get a hang or crash.
reference processing线程个数与ParallelGCThreads参数来一样, 刚好此应用将ParallelGCThreads设为了4, 所以对应了pstack看到4个线程在处理引用的情况. 再次咨询了JVM团队,理解那句话的意思. 以上的terminator object是用来同步和管理gc线程的对象. 它会记录到目前为止已经完成的线程数_complete_threads , 当一个gc线程干完活后,他会把数_complete_threads+1,当terminator object确定已经完成的线程数_complete_threads==预先设置的所有的gc线程数_n_thread,所有的gc线程就会退出,否则其他的gc线程就会等待. 悲剧的是_n_thread在构造时为0, 后面一直没有被重设过. 所以只需要开启ParallelRefProcEnabled就会出问题. 现在能解释通了, 并且从刚才的pstack我们还可以发现停留在ParallelTaskTerminator::offer_termination()方法, 是这表示当前的gc线程没事干, 一直等待GC Terminator通知它结束, 所以它一直处于自旋锁的状态, 所以CPU才会这么高.
简单地关闭掉了ParallelRefProcEnabled之后, 以上这个现象就不会出现了. 这个bug在JDK7中已经解决, 根据应用团队的反馈, 线上此应用的机器有部分是JDK6u26,还有JDK6u30都出现过相同的现象. 官方说明JDK6u32已经fix掉这个bug, patch中显示_n_thread已经被正确地设为ygc的线程数,所以直到6u32的版本才能放心使用这个参数.
分享到:
相关推荐
### JVM参数配置详解 #### 一、理解JVM参数配置的重要性 Java Virtual Machine (JVM) 是运行Java程序的核心环境,其性能优化很大程度上依赖于正确的JVM参数配置。合理配置JVM参数不仅可以显著提升应用程序的运行...
以上只是一部分常见的JVM参数,实际使用中还需要根据应用特性、硬件配置及性能需求进行调整。在进行JVM调优时,通常需要结合监控工具(如VisualVM或JProfiler)观察应用运行状态,以找出性能瓶颈并进行针对性优化。...
常用jvm参数都在这张图中,参考起来方便,是国外大神整理的
### Tomcat 6.0 修改启动内存设置及 Java JVM 参数配置详解 #### 一、背景与目的 在部署和运行 Java Web 应用时,合理地配置应用服务器(如 Apache Tomcat)的内存是非常重要的。这不仅可以提升应用程序的性能,还...
### 关键业务系统JVM参数推荐 #### 一、引言 在关键业务系统中,除了追求高吞吐量和低延迟之外,系统的稳定性和问题排查的便捷性同样至关重要。因此,选择合适的JVM参数变得尤为重要。本文将详细介绍一些常用的JVM...
### 设置Eclipse的JVM参数 #### 一、引言 在进行Java开发时,Eclipse作为一款广泛使用的集成开发环境(IDE),其性能优化对于提高开发效率和应用稳定性至关重要。其中,设置合适的JVM(Java虚拟机)参数是优化...
### IBM JVM 参数选项详解 IBM Java虚拟机(JVM)为开发者提供了丰富的配置选项来优化应用程序性能、诊断问题以及调整各种资源使用情况。本文将详细解释IBM JVM中的关键参数及其功能,帮助您更好地管理和调优Java...
本篇文件内容主要介绍了JVM优化的第三部分,重点围绕Tomcat参数调优、JVM参数调优、JVM字节码优化以及代码优化等几个方面。下面是针对这些知识点的详细解释: 1. Tomcat参数调优 在Tomcat参数调优部分,首先介绍了...
通过合理配置JVM参数,我们可以有效控制内存使用,优化程序性能,并减少垃圾收集带来的负面影响。同时,根据应用特性选择合适的垃圾收集策略,能进一步提高系统的响应速度和稳定性。阅读“java hotspot vm options....
Java虚拟机(JVM)参数调优和相关工具的使用对于优化Java应用程序的性能至关重要。JVM负责管理和分配内存,其中垃圾收集(GC)是其核心功能,它自动管理内存,确保活动对象保留在内存中,同时释放不再使用的对象以...
### JVM参数设置详解 在Java应用开发与维护过程中,JVM(Java虚拟机)的配置至关重要,它直接影响到应用程序的性能表现与稳定性。本文将基于提供的文件内容,深入解析Linux环境下JVM的基本参数设置方法及原理。 ##...
JVM 默认使用的垃圾收集算法是复制和标记-清除-整理,可以根据实际情况选择使用哪种执行方式。有三种执行方式:串行、并行和并发。 串行垃圾收集器(-XX:+UseSerialGC)收集时暂停应用程序的执行,启动一个线程回收...
Linux 服务器调优与 JVM 参数调优 本文主要介绍了 Linux 服务器调优和 JVM 参数调优的相关知识点,以便提高服务器性能和 JVM 应用程序的运行效率。 Linux 服务器调优 Linux 服务器调优是指对 Linux 操作系统的...
通过上述JVM参数的精细调整,可以有效地优化Java应用的内存使用,减少`OutOfMemoryError`的发生,提升系统的稳定性和性能。在实践中,应结合监控工具持续观察和分析JVM的运行状态,以便及时发现问题并做出相应的优化...
5、方法区:也称为永久代,存储类的信息、常量、静态变量等,JDK 8之后被元空间(Metaspace)取代,元空间使用的是本地内存而不是JVM堆。 垃圾回收(GC)是Java程序的重要组成部分,它负责自动清理不再使用的对象,...
上述参数只是起点,还需要通过监控工具(如JVisualVM或JConsole)分析GC日志,观察不同GC策略对应用程序的影响,以及内存使用、吞吐量、停顿时间等指标。此外,还可以考虑调整新生代和老年代的比例,以及是否启用 ...
要获取JVM参数的帮助信息,可以在命令行中使用`java -X`命令。例如,在Windows平台上,可以通过以下步骤获取相关信息: 1. **打开CMD**:首先打开命令提示符(cmd)。 2. **导航至bin目录**:使用`cd`命令切换到J2...
### JVM内存参数调优详解 #### 一、概述 Java虚拟机(JVM)是执行Java字节码的软件环境,为了提高Java程序的性能和稳定性,合理调整JVM的内存参数至关重要。根据Java启动参数的不同分类,我们可以将其分为标准参数...