我们系统的二维码是通过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 阻塞
继续上面的分析，既然在调用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项目地址
