摘要：此時(shí)我想到了福爾摩斯說(shuō)過(guò)的一句話當(dāng)你排除掉各種不可能出現(xiàn)的情況之后，剩下的情況無(wú)論多么難以置信，都是真相。福爾摩斯冷靜下來(lái)想一想，這個(gè)線程，有可能靜悄悄地退出了嗎，沒(méi)留下半點(diǎn)異常日志從理論上來(lái)說(shuō)，不可能。配置建議最后，附上一份配置建議。

我們有個(gè)視頻處理程序，基于 SpringBoot，會(huì)啟動(dòng)幾個(gè)線程來(lái)跑。要退出程序時(shí)，會(huì)發(fā)送一個(gè)信號(hào)給程序，每個(gè)線程收到信號(hào)后會(huì)平滑退出，等全部線程都退出后，整個(gè)進(jìn)程再平滑退出。

整個(gè)程序平時(shí)運(yùn)行都正常，然后有一天，我們發(fā)送了退出信號(hào)給程序后，發(fā)現(xiàn)程序無(wú)法自動(dòng)退出了！腫么回事呢，grep 一下日志看到是這樣的。

# grep "receive exit signal" /PATH/TO/LOG

[2019-02-22 09:49:28,884][INFO ][Thread-75][n.p.j.e.l.l.PolyvQueueVideo:83] - receive exit signal ... exit current thread
[2019-02-22 09:49:56,271][INFO ][Thread-78][n.p.j.e.l.l.PolyvQueueVideo:83] - receive exit signal ... exit current thread
[2019-02-22 09:53:24,943][INFO ][Thread-74][n.p.j.e.l.l.PolyvQueueVideo:83] - receive exit signal ... exit current thread
[2019-02-22 09:55:23,317][INFO ][Thread-79][n.p.j.e.l.l.PolyvQueueVideo:83] - receive exit signal ... exit current thread
[2019-02-22 09:57:00,196][INFO ][Thread-77][n.p.j.e.l.l.PolyvQueueVideo:83] - receive exit signal ... exit current thread

這里的程序總共啟動(dòng)了6個(gè)線程的，但上面看到只有5個(gè)線程退出了，還有一個(gè)哪兒去了？不肯輕易就義么？好頑強(qiáng)的線程。。。

有點(diǎn)小幸運(yùn)的是，從上面這5個(gè)線程的名稱，我們可以推斷出那個(gè)頑強(qiáng)的線程的名稱，從74到79，中間唯獨(dú)缺了76！那就是你啦 Thread-76！

再查 Thread-76 的日志，確實(shí)是我們想找的那個(gè)線程，然后發(fā)現(xiàn)原來(lái)在好幾天前它 好像就停止了運(yùn)行 ，不再有日志輸出。也沒(méi)有任何異常信息！Thread-76 就這樣悄悄的離開(kāi)，不帶走一片云彩。我對(duì)著日志和代碼大眼瞪小眼看了半個(gè)小時(shí)，一籌莫展。

此時(shí)我想到了福爾摩斯說(shuō)過(guò)的一句話：

“當(dāng)你排除掉各種不可能出現(xiàn)的情況之后，剩下的情況無(wú)論多么難以置信，都是真相?！?-- 福爾摩斯

冷靜下來(lái)想一想，Thread-76 這個(gè)線程，有可能靜悄悄地退出了嗎，沒(méi)留下半點(diǎn)異常日志？從理論上來(lái)說(shuō)，不可能。一個(gè)線程，要么順利地執(zhí)行直到結(jié)束，要么中途出錯(cuò)退出了，如果這樣肯定有異常信息，但我們并沒(méi)看到有異常日志。排除掉 “Thread-76 已經(jīng)退出了” 這個(gè)可能性之后，我有個(gè)大膽的想法：這個(gè)線程還一直運(yùn)行著！安安靜靜地運(yùn)行著，持續(xù)著好幾天，沒(méi)有半點(diǎn)日志輸出！

是出現(xiàn)了死鎖嗎？不確定，但我們可以驗(yàn)證一下這個(gè)線程是不是真的還存活著。祭出 jstack，把線程信息 dump 出來(lái)，一查，果然見(jiàn)到了 Thread-76！

"Thread-76" #141 prio=5 os_prio=0 tid=0x00007f812d7d9800 nid=0x12848 runnable [0x00007f8227cfa000]
   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:170)
        at java.net.SocketInputStream.read(SocketInputStream.java:141)
        at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
        at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
        - locked <0x00000005e64cad10> (a java.io.BufferedInputStream)
        at org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:77)
        at org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:105)
        at org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1115)
        at org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1832)
        at org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1590)
        at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:995)
        at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:397)
        at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:170)
        at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
        at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:324)
        at net.polyv.jet.encoding.legacy.util.IPUtil.delRemoteServerCacheFile(IPUtil.java:175)
        ***

可以看到，這個(gè)線程并沒(méi)有發(fā)生死鎖，但卡在了發(fā)送 HTTP 請(qǐng)求這一步。可能是網(wǎng)絡(luò)有問(wèn)題，或者是服務(wù)端除了問(wèn)題，反正我們沒(méi)收到響應(yīng)，然后線程就一直停在這了。怎么會(huì)這樣呢，難道發(fā)送 HTTP 請(qǐng)求時(shí)沒(méi)有設(shè)置超時(shí)時(shí)間嗎？我一查代碼，還真的沒(méi)設(shè)置。。。這是個(gè)低級(jí)錯(cuò)誤啊。

弄清楚了原因之后，問(wèn)題就迎刃而解了?？偨Y(jié)一下，有幾個(gè)地方可以改進(jìn)：

客戶端發(fā)送 HTTP 請(qǐng)求時(shí)，一定要設(shè)置超時(shí)時(shí)間，避免出現(xiàn)問(wèn)題導(dǎo)致請(qǐng)求卡死。

接收 HTTP 請(qǐng)求的服務(wù)端，各級(jí)服務(wù)器（例如 Nginx、Tomcat）也都要設(shè)置超時(shí)時(shí)間，理由同上。

多線程的程序，出問(wèn)題時(shí)進(jìn)行排查的難度會(huì)相對(duì)大一些。所以，對(duì)于手工啟動(dòng)、維護(hù)的線程，可以的話自定義個(gè)線程名稱吧，出問(wèn)題時(shí)也有跡可循。

最后，附上一份 HttpClient 配置建議。

由于各種原因，HttpClient 經(jīng)歷過(guò)好幾次版本變更，且這幾次變更導(dǎo)致其 API 用法都不一樣，不了解情況的人往往會(huì)覺(jué)得懵逼，我到底該用哪個(gè)版本呢？到底該用哪種方法做配置呢？到底該配置哪幾種超時(shí)時(shí)間呢？下面這個(gè)例子，應(yīng)該基本上涵蓋了大多數(shù)的應(yīng)用場(chǎng)景了，拿走不謝。對(duì)應(yīng)的版本是 HttpClient 4.5.* 。

public static CloseableHttpClient buildHttpClient() throws KeyStoreException, NoSuchAlgorithmException,
        KeyManagementException {
    HttpClientBuilder builder = HttpClientBuilder.create();
    
    // 信任全部 HTTPS 證書(shū)，避免 HTTPS 請(qǐng)求因?yàn)樽C書(shū)問(wèn)題而失敗。留意，風(fēng)險(xiǎn)自擔(dān)。
    SSLContext sslContext = new SSLContextBuilder().loadTrustMaterial(null, (arg0, arg1) -> true).build(); // 信任全部證書(shū)
    builder.setSSLContext(sslContext);
    HostnameVerifier hostnameVerifier = NoopHostnameVerifier.INSTANCE; // 也信任全部域名
    SSLConnectionSocketFactory sslSocketFactory = new SSLConnectionSocketFactory(sslContext, hostnameVerifier);
    Registry socketFactoryRegistry = RegistryBuilder.create()
            .register("http", PlainConnectionSocketFactory.getSocketFactory())
            .register("https", sslSocketFactory).build();
    PoolingHttpClientConnectionManager connectionManager =
            new PoolingHttpClientConnectionManager(socketFactoryRegistry);
    
    // 設(shè)置并發(fā)連接數(shù)上限
    connectionManager.setMaxTotal(CONNECTION_LIMIT_TOTAL); // 總的并發(fā)連接數(shù)上限
    connectionManager.setDefaultMaxPerRoute(CONNECTION_LIMIT_PER_HOST); // 單個(gè)域名的并發(fā)連接數(shù)上限
    builder.setConnectionManager(connectionManager);
    
    // 設(shè)置默認(rèn)的超時(shí)時(shí)間。具體數(shù)值可按需調(diào)整。
    RequestConfig requestConfig = RequestConfig.custom()
            .setConnectTimeout(CONNECT_TIMEOUT) // 建立連接的超時(shí)時(shí)間
            .setSocketTimeout(SOCKET_TIMEOUT) // 連接建立后，傳輸數(shù)據(jù)時(shí)的超時(shí)時(shí)間
            .setConnectionRequestTimeout(CONNECTION_REQUEST_TIMEOUT) // 從連接池中獲取連接時(shí)的超時(shí)時(shí)間
            .build();
    builder.setDefaultRequestConfig(requestConfig);
    
    // 除了 GET、HEAD 之外，也自動(dòng)跟隨 POST、PUT 的 301、302 重定向。按需使用。
    builder.setRedirectStrategy(new LaxRedirectStrategy());
    
    return builder.build();
}

參考：

HttpClient Timeout

How to ignore SSL certificate errors in Apache HttpClient 4.4

如果需要自動(dòng)重試機(jī)制，可以看 這里

當(dāng) POST 遇上302，請(qǐng)看 這里