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

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

整個程序平時運行都正常，然后有一天，我們發送了退出信號給程序后，發現程序無法自動退出了！腫么回事呢，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 的日志，確實是我們想找的那個線程，然后發現原來在好幾天前它 好像就停止了運行 ，不再有日志輸出。也沒有任何異常信息！Thread-76 就這樣悄悄的離開，不帶走一片云彩。我對著日志和代碼大眼瞪小眼看了半個小時，一籌莫展。

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

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

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

是出現了死鎖嗎？不確定，但我們可以驗證一下這個線程是不是真的還存活著。祭出 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)
        ***

可以看到，這個線程并沒有發生死鎖，但卡在了發送 HTTP 請求這一步。可能是網絡有問題，或者是服務端除了問題，反正我們沒收到響應，然后線程就一直停在這了。怎么會這樣呢，難道發送 HTTP 請求時沒有設置超時時間嗎？我一查代碼，還真的沒設置。。。這是個低級錯誤啊。

弄清楚了原因之后，問題就迎刃而解了。總結一下，有幾個地方可以改進：

客戶端發送 HTTP 請求時，一定要設置超時時間，避免出現問題導致請求卡死。

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

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

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

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

public static CloseableHttpClient buildHttpClient() throws KeyStoreException, NoSuchAlgorithmException,
        KeyManagementException {
    HttpClientBuilder builder = HttpClientBuilder.create();
    
    // 信任全部 HTTPS 證書，避免 HTTPS 請求因為證書問題而失敗。留意，風險自擔。
    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);
    
    // 設置并發連接數上限
    connectionManager.setMaxTotal(CONNECTION_LIMIT_TOTAL); // 總的并發連接數上限
    connectionManager.setDefaultMaxPerRoute(CONNECTION_LIMIT_PER_HOST); // 單個域名的并發連接數上限
    builder.setConnectionManager(connectionManager);
    
    // 設置默認的超時時間。具體數值可按需調整。
    RequestConfig requestConfig = RequestConfig.custom()
            .setConnectTimeout(CONNECT_TIMEOUT) // 建立連接的超時時間
            .setSocketTimeout(SOCKET_TIMEOUT) // 連接建立后，傳輸數據時的超時時間
            .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

如果需要自動重試機制，可以看 這里

當 POST 遇上302，請看 這里