我们系统的二维码是通过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服务器,马上跑起来测试了一下,效果不错,二维码再怎么点也不会有卡死的情况了。
frp项目地址
https://github.com/fatedier/frp/blob/master/README_zh.md