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

我們有個視頻處理程序，基于 SpringBoot，會啟動幾個線程來跑。要退出程序時，會發(fā)送一個信號給程序，每個線程收到信號后會平滑退出，等全部線程都退出后，整個進程再平滑退出。

整個程序平時運行都正常，然后有一天，我們發(fā)送了退出信號給程序后，發(fā)現(xiàn)程序無法自動退出了！腫么回事呢，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

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

有點小幸運的是，從上面這5個線程的名稱，我們可以推斷出那個頑強的線程的名稱，從74到79，中間唯獨缺了76！那就是你啦 Thread-76！

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

此時我想到了福爾摩斯說過的一句話：

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

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

是出現(xiàn)了死鎖嗎？不確定，但我們可以驗證一下這個線程是不是真的還存活著。祭出 jstack，把線程信息 dump 出來，一查，果然見到了 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)
        ***

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

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

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

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

多線程的程序，出問題時進行排查的難度會相對大一些。所以，對于手工啟動、維護的線程，可以的話自定義個線程名稱吧，出問題時也有跡可循。

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

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

public static CloseableHttpClient buildHttpClient() throws KeyStoreException, NoSuchAlgorithmException,
        KeyManagementException {
    HttpClientBuilder builder = HttpClientBuilder.create();
    
    // 信任全部 HTTPS 證書，避免 HTTPS 請求因為證書問題而失敗。留意，風(fēng)險自擔(dān)。
    SSLContext sslContext = new SSLContextBuilder().loadTrustMaterial(null, (arg0, arg1) -> true).build(); // 信任全部證書
    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); // 單個域名的并發(fā)連接數(shù)上限
    builder.setConnectionManager(connectionManager);
    
    // 設(shè)置默認(rèn)的超時時間。具體數(shù)值可按需調(diào)整。
    RequestConfig requestConfig = RequestConfig.custom()
            .setConnectTimeout(CONNECT_TIMEOUT) // 建立連接的超時時間
            .setSocketTimeout(SOCKET_TIMEOUT) // 連接建立后，傳輸數(shù)據(jù)時的超時時間
            .setConnectionRequestTimeout(CONNECTION_REQUEST_TIMEOUT) // 從連接池中獲取連接時的超時時間
            .build();
    builder.setDefaultRequestConfig(requestConfig);
    
    // 除了 GET、HEAD 之外，也自動跟隨 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) POST 遇上302，請看 這里