问题描述

服务上线后，接口不定时超时

• 服务不可用时间可以长达6-10秒，但是似乎没有完全不可用，有一部分请求可以成功
• 服务有多台机器，但是同一时间只有一台机器有问题
• 同时redis也会超时，但是redis超时时间是1s，实际使用了远大于1s的时间
• 一些同步阻塞队列设置了100ms的超时时间，实际没有被唤醒
• 总体来说感觉有点类似gc时STW的情况

查看监控

分析过程

问题确认

• 首先从上面的top命令截图中可以确认，http请求线程开始执行的时间点就是问题开始的时间点，http请求线程结束的时间点也是问题恢复的时间点。从时间上来看完全符合

• 查看历史dubbo打印的线程堆栈，搜索拉取线程的代码sun.management.ThreadImpl.getThreadInfo。发现每次堆栈中都有对应的代码堆栈。由此可以基本确认这个就是问题的根源

• 后续又核对了几次问题发生时的情况，最终确认了这个就是源头。并且线程数量越多，该问题就越频繁。我们的应用有大概3000个线程，因此频繁触发此问题

• 问题发生总结：首先由普罗米修斯通过http请求拉取监控数据，获取数据时会触发获取线程信息。然后所有线程都会暂停由一个name为VM Thread的jvm线程执行，执行时间会有几秒不等，http请求结束后卡顿结束

疑问（是否有大佬解答一下）

• 获取线程信息时会导致部分线程停顿还是全部线程停顿？
• 获取线程信息是纯内存操作，即使有3000个线程感觉也不需要6秒时间。为什么会如此耗时。不同线程进入安全点的时差导致的吗？

后记

• dump 线程堆栈时是通过VM Thread线程执行的，所以不管有几个cpu，也只能有一个cpu在运行（上面问题vmstat日志里可以看到问题发生时间段内只有一个运行任务），所以在大规格的机器上运行有许多线程的java应用，这个问题的卡顿时间也越长
• dubbo框架的线程池打满时也会触发dump 线程堆栈（或其他dump 线程堆栈操作），因此可能会导致短时间的一个卡顿转化为一个长时间的卡顿