抓取java堆栈失败的思考-Safepoint等的学习

背景

前期解决问题都是靠抓取进程堆栈
jstack,后者是jmap到内存dump的方式来进行分析.

最近连续有两个比较大的项目出现了抓取dump/stack 失败的情况. 
具体原因可能还不太一样. 周末再翻找之前的资料时猜到了可能得几个原因.
想总结一下. 

因为自己并没有看过JVM的源码, 所以可能会是错误的. 
希望能够再后续的工作中去求证或者是证伪

后面也想描述一下一个简单的解决思路. 其实之前也总结过.

jvm的堆栈信息的获取.

jstack -l $pid  查看运行的堆栈信息.
jmap -heap $pid 查看堆的简要信息.
jmap -histo $pid 查看堆中对象的占用情况.
jmap -dump:format=b,file=/root/somefile $pid  
获取dump文件, 注意需要使用 IBM的mat等工具进行分析. 
这些操作得到的结果逐渐复杂, 并且消耗的时间和资源也越来越多. 

关于抓取的过程

JVM在运行期间, 其实是有很多线程的
如果无法内部查看, 可以使用 top -Hp $pid 的方式是简单查看一下大体的线程信息. 

这里的线程数,其实会包含 java的守护线程, GC线程, 线程池线程,以及编译器等线程. 

使用java工具进行抓取时, 理论上是要求 jvm里面的线程都到达 safepoint才可以的. 
但是某些情况下可能无法到达safepoint ,可能就会出现严重的问题. 导致抓取失败. 

如果可以到达, 那么就可以直接进进行堆栈的快照以及信息展示. 
所以需要注意,不要随便进行 jstack 等堆栈信息的获取,会触发一次 STW, 如果safepoint的到达比较慢
会出现严重的卡顿现象. 

关于safepoint

Java虚拟机HotSpot的实现中，使用一组称为OopMap的数据结构来存放对象引用，从而可以快速且准确的完成GC Root扫描。
但程序执行的过程中，引用关系随时都可能发生变化，而HotSpot虚拟机只会在特殊的指令位置才会生成OopMap来记录引用关系，
这些位置便被称为Safepoint。
换句话说，就是在Safepoint这个点上，虚拟机对于调用栈、寄存器等一些重要的数据区域里什么地方包含了什么引用是十分清楚的，
这个时候是可以很快完成GC Roots的扫描和可达性分析的。
HotSpot会在所有方法的临返回之前，以及所有Uncounted loop的循环回跳之前放置Safepoint。
当需要GC时候，虚拟机会首先设置一个标志，然后等待所有线程进入Safepoint，
但是不同线程进入Safepoint的时间点不一样，先进入Safepoint的线程需要等待其他线程全部进入Safepoint，所以Safepoint是会导致STW的。

来源小米科技: 
https://mp.weixin.qq.com/s/GEwD1B-XqFIudWP_EbGgdQ

抓取堆栈失败的两种情况

1. 第一个是K8S项目, 因为podpidslimit的问题, jvm无法再生成一个新的线程, 导致抓取失败. 
   这个问题比较好解释, 因为系统的线程资源耗尽, 导致无法工作. 
   解决问题的思路也比较简单. 修改podpidslimit 或者是修改线程数的数量, 避免大量占用就可以了 

2. 第二个就是昨天遇到的, 怀疑跟小米科技的问题一样. 
   怀疑产品有一个 : Counted loop
   解释为: JVM认为比较短的循环，所以不会放置Safepoint，比如用int作为index的循环。
   怀疑产品里面有一个 int类型的比较大的循环, 一直在占用CPU. jvm又无法再可数循环结束之前插入safepoint
   导致除了GC线程和这个工作线程之外,大家都在等他俩到达Safepoint. 
   同事处于STW的状态, 导致异常无法提供服务 并且也因为无法到达saftpoint
   导致抓取线程堆栈信息失败. 

关于解决思路

使用gdb 在操作系统层抓取core文件
然后使用jvm 解析core dump文件为 java可读文件
在使用 mat进行分析
在不可能时提供一种可能得解决思路.