【邮件】投递线程异常阻塞挂起排查

【邮件】投递线程异常阻塞挂起排查

最近对邮件发送系统进行优化升级，主要升级投递SMTP协议的超时时间设置，升级后发送邮件的模块偶尔会阻塞住，导致整个线程阻塞（一段时间后，整个投递线程都会出现类似阻塞现象）。疑惑的是没有捕获到任何异常日志，程序一直卡在 sendMail 上。
通过内部工具发现相关线程一直处于RUNNABLE状态，但CPU占用一直为0.
利用工具到服务器导出java stack 线程堆栈信息，定位到某一投递线程（灰度环境就3个delivery线程）
“Mail-DeliveryPool-pool-2-thread-3” #65 prio=5 os_prio=0 tid=0x00007f4a615b1800 nid=0x9987 runnable [0x00007f4a360e2000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at com.sun.mail.util.TraceInputStream.read(TraceInputStream.java:97)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
- locked <0x0000000082298718> (a java.io.BufferedInputStream)
at com.sun.mail.util.LineInputStream.readLine(LineInputStream.java:75)
at com.sun.mail.smtp.SMTPTransport.readServerResponse(SMTPTransport.java:1440)
at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:1260)
at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:370)
at javax.mail.Service.connect(Service.java:275)
at javax.mail.Service.connect(Service.java:156)
at javax.mail.Service.connect(Service.java:105)
at com.mail.post.service.sendService.MailSender.getTransport(MailSender.java:273)
at com.mail.post.service.sendService.MailDeliveryThread.run(MailDeliveryThread.java:70)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)

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

原因分析：由堆栈信息可以看出大量的线程阻塞到socket读的地方，推断可能是由于网络延迟或邮件ISV邮件服务连接后没有响应造成 java.net.SocketInputStream.socketRead0一直阻塞等待读取。
疑点1：源码中有对smtp链接相关超时进行设置，理论上不应出现该情况？相关源码如下：

SMTP协议对超时参数设置如下：

1. mail.smtp.connectiontimeout ： Socket connection timeout value
   in milliseconds. This timeout is implemented by java.net.Socket.
   Default is infinite timeout. int 类型

2. mail.smtp.timeout ： Socket read timeout value in milliseconds. This timeout is implemented by java.net.Socket. Default is infinite timeout. int 类型

3. mail.smtp.writetimeout： Socket write timeout value in milliseconds. This timeout is implemented by using a java.util.concurrent.ScheduledExecutorService per connection that schedules a thread to close the socket if the timeout expires. Thus, the overhead of using this timeout is one thread per connection. Default is infinite timeout. int 类型

疑点2：源码中投递服务未对mail.smtp.writetimeout 进行设置，结合系统运行历史情况来看，mail.smtp.writetimeout 未设置不是主要原因。（但为验证这个CASE，设置writetimeout 写超时时间，调整相关值，灰度验证两个小时后，依然阻塞。证实猜测）

疑点3：结合系统升级前后对比，可能升级后超时配置没有生效，对比升级前后版本代码：
升级前：

升级后：

对比代码：获取超时时间的方式上，升级前用string ,升级后用int
通过上面smtp对超时三个参数定义为int类型，获取方式上似乎没有问题
通过源码查看，Session 获取配置项基本上是通过

String s = props.getProperty(key);

猜测：property配置中如果配置项是int类型，会获取不到？
写单侧验证，session 相关配置已设置

根本原因：java.util.Properties 的通过getProperty获取配置值做了特殊处理，会进行String转换，非String的值会置空
java.util.Properties 配置值类型是Object，但通过getProperty方法获取，却仅仅支持String类型，java mail 实现细节上也没有规避这个情况。