0 TL;DR;
- 问题与原因:某些特定条件下
java.net.SocketInputStream.socketRead0
方法会卡死,导致运行线程一直被占用导致泄露 - 采用的方案:使用监控线程异步监控卡死事件,如果发生直接关闭网络连接释放链接以及对应的线程
1. 问题
一个服务 tomcat 线程池线程总是不释放,之前只能靠重启服务缓解
(这个服务的作用是对第三方网站做一个类似于适配器模式的封装,简单的说就是请求打到该服务,该服务请求第三方网站,将数据组织成需要的格式返回,是整个爬虫系统的一个环节)
2. 定位
jstack 导出 stack.info,观察这些卡死的 tomcat 线程在做什么
第一类状态如下,这种状态是 tomcat 空闲线程,状态是 TIMED_WAITING 在等待新任务到来进行处理
text
"http-nio-8080-exec-1810" #16955528 daemon prio=5 os_prio=0 tid=0x00007f2de4707000 nid=0x239136 waiting on condition [0x00007f2700887000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000001c31000e0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:89)
at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:33)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:750)
第二类状态如下,这种状态是 tomcat 在执行某项工作,状态是 RUNNALBE
如果反复观察某些特定的线程状态(例如这里的 http-nio-8080-exec-1811)通过 State 是否会改变以及业务日志是否卡在某个位置之后不动了,基本就可以定位哪些线程出了问题
text
"http-nio-8080-exec-1811" #16955529 daemon prio=5 os_prio=0 tid=0x00007f2de4709000 nid=0x239137 runnable [0x00007f2700784000]
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 org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137)
at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153)
at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:280)
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138)
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:157)
at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
at org.apache.http.impl.execchain.MainClientExec.createTunnelToTarget(MainClientExec.java:485)
at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:410)
at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
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)
... (省略)
最终发现,线程卡在了 java.net.SocketInputStream.socketRead0(Native Method)
,那么其含义是什么呢?
3. 原因与方案
参考如下文章:https://medium.com/tier1app-com/threads-stuck-in-java-net-socketinputstream-socketread0-d0a2183b4a1c
可以想象你给一个人打电话的场景,她接了电话但是有的时候并没有说话,而是你在等待她说话。那么从电话打通到电话挂断,你等待她说话的时间基本都是
socketRead0()
API 在做的事情...
由于这是一个底层的方法,所以很多应用都会用到这个方法。当你的应用一直无法读取到完整的数据时,就会看起来卡在了
socketRead0()
这个方法上
那么这个问题该如何解决呢,面的参考资料提供了一些方案,我还参考了另外一部分可行方案方案(来自:https://stackoverflow.com/questions/28785085/how-to-prevent-hangs-on-socketinputstream-socketread0-in-java),汇总如下
3.1 设置合适的参数
jvm 参数:
Dsun.net.client.defaultConnectTimeout
Dsun.net.client.defaultReadTimeout
代码层面的层参数
setSoTimeout
setStaleConnectionCheckEnabled
(用于清理长时间占用的链接,已经过时废弃,目前直接默认开启的)
备注:有人指出,这是 JVM 在 Linux 上实现阻塞套接字超时存在 bug,poll 或者 select 可能会错误的通知数据可用的消息,这时除非服务器断开连接,否则将无限期的等待下去。而这种情况无法通过简单的参数设置,解决该问题。
3.2 网络或者服务侧的问题
有的时候可能是因为网络设施、负载均衡或者对方服务本身的问题,导致这一现象,这时应该用一些网络抓包工具(例如 Wireshark)发现并解决这些问题
由于我的服务本身是请求第三方网站,该方案并没有什么帮助
3.3 将网络客户端由阻塞替换为非阻塞客户端
可以使用 Grizzly 或者 Netty 客户端,来替换原有的 http 客户端(我是用的是 httpclient),但这通常涉及到整体系统的重构和测试,代码改动量过大
3.4 单独启动线程检测处理超时,如果超时就想办法中断处理流程
这是一个虽然丑陋但是可靠的方案,也是我所采用的方案。逻辑简单,增加监控线程,处理那些卡死的线程。
4. 示例代码
逻辑是每次请求之前调用 addToWatch
方法异步的监控是否在合理的时间范围内 HttpClient 已经关闭了
如果超过了超时时间,就直接关闭 HttpClient,这样原本处于等待状态的 java.net.SocketInputStream.socketRead0
会接收到中断而终止(这个中断消息是我猜的,但是实际来看是有效的)
java
@Slf4j
public class HttpClientWatcher {
private static final ThreadPoolExecutor WATCH_THREAD_POOL = new ThreadPoolExecutor(
20, 50, 1000L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<>(10000),
new ThreadPoolExecutor.DiscardPolicy()
);
@Data
@Builder
static class CloseableHttpClientWrapper {
private CloseableHttpClient httpClient;
@SuppressWarnings("UnusedAssignment")
private volatile boolean closed = false;
}
public static void addToWatch(CloseableHttpClientWrapper wrapper, int timeoutMillis) {
if (wrapper == null || wrapper.getHttpClient() == null || wrapper.isClosed()) {
return;
}
WATCH_THREAD_POOL.execute(() -> watch(wrapper, timeoutMillis));
// 打印线程池状态,用来调整线程池参数
log.info("In addToWatch, activeCount: {}, poolSize: {}, queueSize: {}", WATCH_THREAD_POOL.getActiveCount(),
WATCH_THREAD_POOL.getPoolSize(), WATCH_THREAD_POOL.getQueue().size());
}
public static void watch(CloseableHttpClientWrapper wrapper, int timeoutMillis) {
final long timeoutTimestamp = System.currentTimeMillis() + Math.min(10L * timeoutMillis, 10 * 60 * 1000L);
while (System.currentTimeMillis() < timeoutTimestamp) {
if (wrapper.isClosed()) {
return;
}
ThreadUtil.sleep(50, TimeUnit.MILLISECONDS);
}
// 这里单独判断一次,是因为担心在 sleep 的时候,httpClient 已经被关闭了
if (wrapper.isClosed()) {
return;
}
// 超时尝试关闭
try {
wrapper.getHttpClient().close();
} catch (Exception e) {
log.error("关闭HttpClient失败", e);
}
}
}