欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

快速理解Java垃圾回收和jvm中的stw

程序员文章站 2024-04-01 18:55:22
java中stop-the-world机制简称stw,是在执行垃圾收集算法时,java应用程序的其他所有线程都被挂起(除了垃圾收集帮助器之外)。java中一种全局暂停现象,...

java中stop-the-world机制简称stw,是在执行垃圾收集算法时,java应用程序的其他所有线程都被挂起(除了垃圾收集帮助器之外)。java中一种全局暂停现象,全局停顿,所有java代码停止,native代码可以执行,但不能与jvm交互;这些现象多半是由于gc引起。

gc时的stop the world(stw)是大家最大的敌人。但可能很多人还不清楚,除了gc,jvm下还会发生停顿现象。

jvm里有一条特殊的线程--vm threads,专门用来执行一些特殊的vm operation,比如分派gc,thread dump等,这些任务,都需要整个heap,以及所有线程的状态是静止的,一致的才能进行。所以jvm引入了安全点(safe point)的概念,想办法在需要进行vm operation时,通知所有的线程进入一个静止的安全点。

除了gc,其他触发安全点的vm operation包括:

1. jit相关,比如code deoptimization, flushing code cache ;

2. class redefinition (e.g. javaagent,aop代码植入的产生的instrumentation) ;

3. biased lock revocation 取消偏向锁 ;

4. various debug operation (e.g. thread dump or deadlock check);

监控安全点看看jvm到底发生了什么?

最简单的做法,在jvm启动参数的gc参数里,多加一句:

-xx:+printgcapplicationstoppedtime

它就会把全部的jvm停顿时间(不只是gc),打印在gc日志里。

2016-08-22t00:19:49.559+0800: 219.140: total time for which application threads were stopped: 0.0053630 seconds

这是个很有用的必配参数,可以打出几乎一切的停顿……

但是,在jdk1.7.40以前的版本,它居然没有打印时间戳,所以只能知道jvm停了多久,但不知道什么时候停的。此时一个土办法就是加多一句“ -xx:+printgcapplicationconcurrenttime”,打印jvm在两次停顿之间的正常运行时间(同样没有时间戳),但好歹能配合有时间戳的gc日志,反推出stop发生的时间了。

2016-08-22t00:19:50.183+0800: 219.764: application time: 5.6240430 seconds

如何打印出事哪种原因导致的停顿呢?

再多加两个参数:-xx:+printsafepointstatistics -xx: printsafepointstatisticscount=1

此时,在stdout中会打出类似的内容

vmop [threads: total initially_running wait_to_block]1913.425: gencollectforallocation [ 55 2 0 ] [time: spin block sync cleanup vmop] page_trap_count[ 0 0 0 0 6 ] 0

此日志分两段,第一段是时间戳,vm operation的类型,以及线程概况

total: 安全点里的总线程数

initially_running: 安全点时开始时正在运行状态的线程数

wait_to_block: 在vm operation开始前需要等待其暂停的线程数

第二行是到达安全点时的各个阶段以及执行操作所花的时间,其中最重要的是vmop

spin: 等待线程响应

safepoint号召的时间

block: 暂停所有线程所用的时间

sync: 等于 spin+block,这是从开始到进入安全点所耗的时间,可用于判断进入安全点耗时

cleanup: 清理所用时间

vmop: 真正执行vm operation的时间

可见,那些很多但又很短的安全点,全都是revokebias,详见 偏向锁实现原理, 高并发的应用一般会干脆在启动参数里加一句"-xx:-usebiasedlocking"取消掉它。另外还看到有些类型是no vm operation, 文档上说是保证每秒都有一次进入安全点(如果这秒已经gc过就不用了),给一些需要在安全点里进行,又非紧急的操作使用,比如一些采样型的profiler工具,可用-dguaranteedsafepointinterval来调整,不过实际看它并不是每秒都会发生,时间不定。

在实战中,我们利用安全点日志,发现过有程序定时调用thread dump等等情况。不过因为安全点日志默认输出到stdout,因为性能及stdout日志的整洁性等原因,我们平时默认没有开启它。只有在需要时才打开。

再再增加下面三个参数,可以知道更多vm里发生的事情。可惜jvm不会因为设了这三个参数,就把安全点日志转移到vm.log里面来,而是白白打印了两次。

-xx:+unlockdiagnosticvmoptions -xx:+logvmoutput -xx:logfile=/dev/shm/vm.log

总结

本文关于快速理解java垃圾回收和jvm中的stw的介绍就到这里,希望对大家有所帮助,感兴趣的朋友可以参阅:浅谈java回收对象的标记和对象的二次标记过程 、java虚拟机装载和初始化一个class类代码解析 、java中map遍历方式的选择问题详解等,有什么问题可以随时留言,小编会及时回复大家的。