java.net.SocketInputStream.socketRead0 卡死导致 tomcat 线程池打满的问题

发布于:2024-05-10 ⋅ 阅读:(25) ⋅ 点赞:(0)

0 TL;DR;

  • 问题与原因:某些特定条件下 java.net.SocketInputStream.socketRead0 方法会卡死,导致运行线程一直被占用导致泄露
  • 采用的方案:使用监控线程异步监控卡死事件,如果发生直接关闭网络连接释放链接以及对应的线程

1. 问题

一个服务 tomcat 线程池线程总是不释放,之前只能靠重启服务缓解
(这个服务的作用是对第三方网站做一个类似于适配器模式的封装,简单的说就是请求打到该服务,该服务请求第三方网站,将数据组织成需要的格式返回,是整个爬虫系统的一个环节)
在这里插入图片描述

2. 定位

jstack 导出 stack.info,观察这些卡死的 tomcat 线程在做什么

第一类状态如下,这种状态是 tomcat 空闲线程,状态是 TIMED_WAITING 在等待新任务到来进行处理

"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 是否会改变以及业务日志是否卡在某个位置之后不动了,基本就可以定位哪些线程出了问题

"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 会接收到中断而终止(这个中断消息是我猜的,但是实际来看是有效的)


@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);
        }
    }

}

网站公告

今日签到

点亮在社区的每一天
去签到