排查线程卡死问题

最新推荐文章于 2021-08-23 16:33:40 发布

weixin_34389926

最新推荐文章于 2021-08-23 16:33:40 发布

阅读量2.6k

点赞数

文章标签： java python 网络

原文链接：https://my.oschina.net/itsaysay/blog/3036629

版权

2019独角兽企业重金招聘Python工程师标准>>>

我们系统的二维码是通过jna调用dll文件生成的，最近碰到二维码使用几次过后就无法重新生成。在dump出线程资源后，发现调用dll的时候会卡死。

dump线程

jstack -l 线程pid > dump.txt

-l 长列表，打印关于锁的附加信息
-m 打印java和jni框架的所有栈信息

-m 打印的信息是这个样子

----------------- 1 -----------------
0x7713f8e1    ntdll!ZwWaitForSingleObject + 0x15
0x769b1194    kernel32!WaitForSingleObjectEx + 0x43
0x769b1148    kernel32!WaitForSingleObject + 0x12
0x710825b9    jvm!_JVM_FindSignal@4 + 0x2979
0x7101dfc1    jvm!JVM_GetThreadStateNames + 0x4f381
0x7101e356    jvm!JVM_GetThreadStateNames + 0x4f716
0x7103f3d1    jvm!JVM_GetThreadStateNames + 0x70791
0x70f9c505    jvm!JNI_GetCreatedJavaVMs + 0x59c5
0x01242165    java + 0x2165
0x0124b03f    java + 0xb03f
0x0124b0c9    java + 0xb0c9
0x769b336a    kernel32!BaseThreadInitThunk + 0x12
0x77159902    ntdll!RtlInitializeExceptionChain + 0x63
0x771598d5    ntdll!RtlInitializeExceptionChain + 0x36

-l 是这样子的

"Executor-3" #152 prio=5 os_prio=0 tid=0x16438000 nid=0xe08 runnable [0x2128f000]
   java.lang.Thread.State: RUNNABLE
 at com.sun.jna.Native.invokeLong(Native Method)
 at com.sun.jna.Function.invoke(Function.java:421)
 at com.sun.jna.Function.invoke(Function.java:354)
 at com.sun.jna.Library$Handler.invoke(Library.java:244)
 at com.sun.proxy.$Proxy120.WXSnsUpload(Unknown Source)
 at com.zhiplusyun.wxapi.xxx.xxx(FriendshipApi.java:146)
 at com.zhiplusyun.wxapi.xxx.xxx(FriendshipApi.java:117)
 at com.zhiplusyun.wxapi.xxx.xxx(FriendshipApi.java:86)
 at com.zhijiayun.zhituicenter.service.asyncTask.xxx.xxx(LoginSuccessAsyncTask.java:196)
 at com.zhijiayun.zhituicenter.service.asyncTask.xxx.xxx(LoginSuccessAsyncTask.java:73)
 at com.zhijiayun.zhituicenter.service.asyncTask.xxx.xxx(CheckQrcodeStatusAsyncTask.java:57)
 at com.zhijiayun.zhituicenter.service.xxx.xxx$$FastClassBySpringCGLIB$$c3165a3b.invoke(<generated>)
 at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
 at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:747)
 at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
 at org.springframework.aop.interceptor.AsyncExecutionInterceptor.lambda$invoke$0(AsyncExecutionInterceptor.java:115)
 at org.springframework.aop.interceptor.AsyncExecutionInterceptor$$Lambda$465/27605255.call(Unknown Source)
 at java.util.concurrent.FutureTask.run(Unknown Source)
 at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
 at java.lang.Thread.run(Unknown Source)

   Locked ownable synchronizers:
 - <0x0b523168> (a java.util.concurrent.ThreadPoolExecutor$Worker)

这一部分也是需要分析的部分，这个线程一直处于 java.lang.Thread.State: RUNNABLE状态,线程卡死在com.sun.jna.Native.invokeLong(Native Method)这里，这里就是调用了dll的WXSnsUpload函数，一个线程一直被占用，后面的线程再进来同样被卡住，直到沾满线程池。

在dump文件中，会看到这几个状态：
Deadlock 死锁
Runnable 执行中
Waiting on condition 等待资源
Waiting on monitor entry 等待获取监视器
Object.wait() 或 TIMED_WAITING 对象等待中
Suspended 暂停
Blocked 阻塞
文章参考：http://java.jr-jr.com/2015/12/09/jstack-state/

继续上面的分析，既然在调用dll的时候线程一直被占用，应该是这个dll里面发生了什么，一直在等待某个资源返回，而dll的函数里又没有写超时机制，那就自己在外面写个调用超时，我用了FutureTask来实现

以为这样就能解决了，然而下午又报二维码无法生成了，没办法，只能再dump线程分析，发现还是在调用dll的时候的问题，只不过换了一个dll的函数，这难道调用dll的不同函数都有卡住的可能，难道我要给没个方法加超时吗，这治标不治本啊。

聪明的我并没有这么去做，有个线程的状态Waiting on condition提醒了我，这个状态就说明线程一直等待某个资源，有可能是请求第三方，但第三方一直没返回。由于我们项目发起http请求，使用了http代理，怀疑是不是http代理出了问题。

那么网上找个http代理来试下，啊呀，果然如此，用了他们的代理就不会用问题，怎么点都行。

自己用ngrok搭的就不行吗，查看日志再调式，请求明明过去了，但ngrok要过一会才有日志，并且发出了警告

[09:45:05 CST 2019/04/14] [WARN] (ngrok/log.(*PrefixLogger).Warn:87) [pub:65f06d8f] [tcp://xxxx.com:8881] Copied 69719 bytes to pxy:60de645e before failing with error read tcp 888.16.204.4:8881->888.888.888.99:8888: read: connection reset by peer

ngrok在copy数据的时候发生了错误，那就应该是ngrok的锅了，但本人对ngrok不是非常了解，源码也是go，网上资料很少

最后换了一个使用frp来做内网穿透，正好之前就搭过frp服务器，马上跑起来测试了一下，效果不错，二维码再怎么点也不会有卡死的情况了。