dns解析超时引发的线程池故障
# 问题描述
公司做的是一个支付系统，会对接很多第三方公司。
突然有一天,有一家第三方（简称金花平台）反应收不到我们的通知消息。
# 排查过程
我们登陆自己的服务器，检查程序日志，是有给金花平台发送通知的。而且大多订单都是通知成功而且金花平台也成功返回了。
仔细检查日志后，发现金花平台说的没有收到通知的订单其实在我们服务器的日志里面是有发送的，只是没有返回
与金花平台沟通后，手动模拟程序给金花平台发送通知后，金花平台反馈之前没有收到通知的订单经过手动模拟发送通知成功了
# 定位问题
与研发沟通后，紧急更新加了一些通知模块更加详细的日志{具体是一些内部交互以及通知第三方时候的每一步日志}
等遇到新的问题订单后，发现加的那些日志也定位不到具体的问题。
和公司负责研发的负责人商量后，决定从头开始检查一遍{包括服务器的资源，服务自身的线程池}
等检查到服务自身线程池的时候发现 负责通知的模块有死锁的线程池，释放不了
下面标红是获取到的线程池其中的一个带锁的，可以看出卡在了dns解析，所以造成了死锁
"Thread-2199" #2595 prio=5 os_prio=0 tid=0x00007f20fc0a5800 nid=0x10b0d in Object.wait() [0x00007f20a940d000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at java.net.InetAddress.checkLookupTable(InetAddress.java:1393)
- locked <0x00000000804a4e78> (a java.util.HashMap)
at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1310)
at java.net.InetAddress.getAllByName0(InetAddress.java:1276)
at java.net.InetAddress.getAllByName(InetAddress.java:1192)
at java.net.InetAddress.getAllByName(InetAddress.java:1126)
at org.apache.http.impl.conn.SystemDefaultDnsResolver.resolve(SystemDefaultDnsResolver.java:45)
at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:112)
at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:373)
at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:381)
at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:237)
at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)
at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108)
at vip.dcpay.util.http.HttpHelper.execute(HttpHelper.java:246)
at vip.dcpay.util.http.HttpHelper.post(HttpHelper.java:113)
at vip.dcpay.order.notify.domain.util.CallbackInterfaceUtil.callbackNotify(CallbackInterfaceUtil.java:84)
at vip.dcpay.order.notify.domain.service.TaskRetryService.notify(TaskRetryService.java:85)
at vip.dcpay.order.notify.domain.service.TaskRetryService$$FastClassBySpringCGLIB$$3b7fcca6.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.retry.interceptor.RetryOperationsInterceptor$1.doWithRetry(RetryOperationsInterceptor.java:91)
at org.springframework.retry.support.RetryTemplate.doExecute(RetryTemplate.java:287)
at org.springframework.retry.support.RetryTemplate.execute(RetryTemplate.java:180)
at org.springframework.retry.interceptor.RetryOperationsInterceptor.invoke(RetryOperationsInterceptor.java:115)
at org.springframework.retry.annotation.AnnotationAwareRetryOperationsInterceptor.invoke(AnnotationAwareRetryOperationsInterceptor.java:153)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:185)
at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:689)
at vip.dcpay.order.notify.domain.service.TaskRetryService$$EnhancerBySpringCGLIB$$f6eef3da.notify(<generated>)
at vip.dcpay.order.notify.domain.service.CallBackReceiveService$1.run(CallBackReceiveService.java:56)
at java.lang.Thread.run(Thread.java:748)
# 具体查看死锁线程池的方法：
ps -ef|grep 项目名称 # 找到对应项目的进程号 jstack 进程号 # 实时获取正在运行的线程池
# 问题处理方案
vim /etc/resolv.conf # 编辑文件，添加如下信息。问题得到解决
options timeout:2 attempts:1 rotate #dns解析超时时间设置为2秒，从第一个namesever开始轮询
nameserver 9.9.9.9
nameserver 1.1.1.1
nameserver 8.8.8.8
参数说明：
timeout：dns解析超时时间，默认是5秒。笔者在生产环境中实际配置的是2秒
attempts：从第几个nameserver开始dns解析轮询
