最近一位朋友在公眾號留言問一個關于熔斷的問題：使用hystrix進行httpclient超時熔斷錯誤，我是順序操作的(沒有并發)，發現hystrix會超時斷開，但是會導致hystrix線程池不斷增多，直到后面因線程池裝不下拒絕?

而該問題跟線程中斷、超時與降級等有關，因此本文將詳細介紹導致這個問題背后的原因。

[[192984]]

當我們在線程中執行如用戶請求任務時，比如HTTP處理線程，最擔心的什么?

1. 線程數***增長;
2. 線程執行時間長;
3. 線程不可中斷。

對于線程數***增長，我們可以通過使用線程池來控制線程數量，控制線程不是***增長的。

對于線程執行時間長，我們應設置合理的超時時間來保障線程執行時間可控，當超時時要么返回給用戶錯誤頁面，要么可以返回降級頁面。

對于線程不可中斷，我們應想辦法將線程設計的可中斷，從而在遇到問題可中斷線程并降級處理。

接下來的部分將主要講解線程中斷。

線程中斷是通過Thread.interrupt()方法來做，一般是在A線程來中斷B線程。

首先我們來看下該方法的一些Javadoc描述：

1. 如果線程被Object的wait()、wait(long)、wait(long, int) 或者

Thread的join()、join(long)、join(long, int)、sleep(long)、sleep(long, int)方法阻塞，執行線程中斷，且拋出InterruptedException，但中斷狀態并清空重置，即Thread. isInterrupted()返回false;

2. 如果線程被java.nio.channels.InterruptibleChannel上的一個I/O操作阻塞，執行線程中斷，且該

InterruptibleChannel將被關閉，拋出java.nio.channels.ClosedByInterruptException，線程中斷狀態會設置，即Thread. isInterrupted()返回true;

3. 如果線程被java.nio.channels.Selector阻塞，執行線程中斷，該Selector#select()方法將立即返回，相當于調用了java.nio.channels.Selector#wakeup()，不會拋出異常，但會設置中斷狀態，即Thread. isInterrupted()返回true;

4. 如果不滿足以上條件的，那么執行線程中斷不會拋出異常，僅設置中斷狀態，即Thread. isInterrupted()返回true。也就是說我們代碼要根據該狀態來決定下一步怎么做。

從如上描述可以看出，如果方法異常描述上有拋出

InterruptedException、ClosedByInterruptException異常的，說明該方法可以中斷，如“public final native void wait(longtimeout) throws InterruptedException”，但是中斷狀態會被會被重置要看其Javadoc描述。其他情況基本都是設置中斷狀態而不會中斷掉操作。

BIO(Blocking I/O)操作不可中斷

如java.net.Socket讀寫網絡I/O時是阻塞的，除了設置超時時間外，還應該考慮讓它可中斷或者盡早中斷。可以參考《你的Java代碼可中斷嗎》。還有如JDBC驅動mysql-connector-java、HttpClient等大部分都是使用BIO，它們也是不可中斷的。

NIO(New I/O)操作可中斷

NIO涉及到兩部分：

java.nio.channels.Selector和java.nio.channels.InterruptibleChannel，它們是可中斷的。如java.nio.channels#SocketChannel實現了InterruptibleChannel，如下方法都是可中斷的，并會拋出ClosedByInterruptException異常：

• connect(SocketAddress remote)
• read(ByteBuffer[] dsts, int offset, int length)
• read(ByteBuffer[] dsts)
• write(ByteBuffer src)

線程、BIO與中斷

我們使用BIO實現的HttpClient來做個實驗，如下代碼所示：

public class BlockingIOTest { 
  public static void main(String[] args) throws Exception { 
    Thread threadA = new Thread(()-> { 
      try { 
       //該阻塞5s 
      String url = "http://localhost:9090/ajax"; 
      //HttpClient是BIO，不可中斷 
      HttpResponse response = HttpClientUtils.getHttpClient().execute(new HttpGet(url)); 
      System.out.println("http status code : " + response.getStatusLine().getStatusCode()); 
      //雖然在threadB執行了threadA線程中斷 
      //但是僅僅是設置了中斷狀態為true 
      //并沒有中斷線程A的執行，該線程還是正常的執行完成了 
      System.out.println("threadA is interrupted: " + Thread.currentThread().isInterrupted()); 
     } catch (Exception e) { 
       e.printStackTrace(); 
     } 
    }); 
    Thread threadB = new Thread(()-> { 
      try { 
       Thread.sleep(2000L); 
      //休眠2s后，中斷線程A 
      threadA.interrupt(); 
     } catch (Exception e) { 
     } 
    }); 
    threadA.start(); 
    threadB.start(); 
    Thread.sleep(15000L); 
  } 
} 

如上代碼的輸出結果為：

http status code : 200 
threadA is interrupted: true 

如上代碼的執行流程是這樣的：

1. 線程A通過BIO實現HttpClient遠程調用http://localhost:9090/ajax獲取數據，而該服務需要5s才能響應;
2. 線程B在線程A執行2s后進行了中斷處理，但是線程A調用的HttpClient是阻塞且不可中斷的操作，僅僅是設置了線程A的中斷狀態為true，因此其一直等待網絡I/O完成;
3. 當線程A從遠程獲取到結果后繼續執行，Thread.currentThread().isInterrupted()將輸出true，表示線程A被設置了中斷狀態。

從而需要注意設置了中斷狀態與中斷執行不是一回事。因此對于使用BIO，一定要設置好連接和讀寫的超時時間，另外可以參考《你的Java代碼可中斷嗎》進行可中斷設計。

線程池、Future與中斷

我們往線程池提交一個HttpClient任務，并通過Future來等待執行結果，如下代碼所示：

public class ThreadPoolTest { 
  private static ExecutorService executorService = Executors.newFixedThreadPool(5); 
  public static void main(String[] args) throws Exception { 
   Future<Integer> futureA = executorService.submit((Callable) () -> { 
    //該url會阻塞5s 
   String url = "http://localhost:9090/ajax"; 
   //HttpClient是BIO，不可中斷 
   HttpResponse response = HttpClientUtils.getHttpClient().execute(new HttpGet(url)); 
   Integer result = response.getStatusLine().getStatusCode(); 
   System.out.println("thread a result : " + result); 
   return response.getStatusLine().getStatusCode(); 
   }); 
   Future<Integer> futureB = executorService.submit((Callable) () -> { 
     //該url會阻塞5s 
    String url = "http://localhost:9090/ajax"; 
    //HttpClient是BIO，不可中斷 
    HttpResponse response = HttpClientUtils.getHttpClient().execute(new HttpGet(url)); 
    Integer result = response.getStatusLine().getStatusCode(); 
    System.out.println("thread b result : " + result); 
    return result; 
    }); 
    try { 
   Integer resultA = futureA.get(100, TimeUnit.MILLISECONDS); 
   } catch (TimeoutException e) { 
    System.out.println("future a timeout"); 
  } 
  try { 
    Integer resultB = futureB.get(100, TimeUnit.MILLISECONDS); 
  } catch (TimeoutException e) { 
    System.out.println("future b timeout"); 
   } 
  executorService.awaitTermination(10000L, TimeUnit.MILLISECONDS); 
  } 
} 

如上代碼的輸出結果為：

future a timeout 
future b timeout 
thread a result : 200 
thread b result : 200 

如上代碼的執行流程是這樣的：

1. 主線程往線程池提交了兩個HttpClient阻塞調用任務，該任務響應時間為5s;
2. 主線程阻塞在兩個帶超時的Future等待上，Future在等待線程池任務執行結束，Future的超時時間設置為100ms，所以很快就超時并返回了，主線程繼續執行，在《億級流量》中我們用到了很多這種方法進行并發獲取數據和降級或熔斷處理;
3. 線程池中的兩個任務其實并沒有被中斷，還是占用著線程池中的線程，在后臺繼續執行，直到完成。

從如上可以看出，使用Future時只是在主線程解除了阻塞，并沒有連帶把線程池任務取消掉，還是占用著線程并阻塞執行。

之前有位同學在公眾號后臺留言咨詢：

使用hystrix進行httpclient超時熔斷錯誤，我是順序操作的(沒有并發)，發現hystrix會超時斷開，但是會導致hystrix線程池不斷增多，直到后面因線程池裝不下拒絕?

看完如上示例，應該能解決該讀者的疑惑。雖然熔斷了，但是線程中的操作并沒有真正的中斷，而是還占著線程資源。

接下來我們可以簡單看下Future其中的一個實現FutureTask：

超時等待方法get(long timeout, TimeUnit unit)偽代碼：

while(true) { 
  if (Thread.interrupted()) {//如果當前線程中斷了，處理現場，并拋出中斷異常 
    //some code 
   throw new InterruptedException(); 
  } 
  //判斷剩余休眠時間 
  nanos = deadline - System.nanoTime(); 
  if (nanos <= 0L) {//如果沒有休眠時間了，則處理線程，并終止執行 
    //some code  
    return state; 
  } 
  //休眠一段時間，內部實現為UNSAFE.park(false, nanos) 
  LockSupport.parkNanos(this, nanos); 
} 

取消方法cancel(boolean mayInterruptIfRunning)偽代碼：

if (mayInterruptIfRunning) {//中斷當前線程 
  Thread t = runner; 
  if (t != null) 
    t.interrupt(); 
} 
//執行UNSAFE.unpark(thread)喚醒休眠的當前線程 
LockSupport.unpark(t); 

即當我們調用Future#cancel時，是通過喚醒Future所在線程實現，當然實際是比這個要復雜的。

回填結果方法set(V v)偽代碼：

//修改Future狀態為完成 
//保持v的值，從而Future#get能獲取到 
//通過LockSupport.unpark(t)喚醒休眠的線程 

當線程池中的線程執行完成后，是通過Future#set把值設置回Future，從而喚醒休眠的線程，即阻塞在Future#get的等待，然后獲取到該結果。

鎖與中斷

synchronized和ReentrantLock#lock()在獲取鎖的過程中是不可中斷的，假設出現了死鎖將一直僵持在那，無法終止阻塞。但我們可以使用可中斷的

ReentrantLock#lockInterruptibly()方法或者ReentrantLock#tryLock(long timeout, TimeUnit unit)實現可中斷。

總結

在設計高可用系統時，盡量使用線程池，而不是通過每個請求創建一個線程來實現，通過線程池的拒絕策略來優雅的拒絕無法處理的請求。

檢查整個請求鏈路設置合理的超時時間，跟調用方協商合理的SLA、降級限流方案。更長的超時時間意味著出現問題時請求堆積的越多，越可能產生雪崩。

明確知道自己的服務是否可中斷，如果不可中斷，應該使用線程池和Future實現偽可中斷，通過Future配置合理的超時時間，當超時時執行相應的降級策略。也要清楚的知道通過Future只是偽中斷，線程池中的任務還是在后臺執行，當Future超時后進行重試時，會對調用的服務產生更多的請求，從而造成一種DDos，一定要注意相應的處理策略。

池大小、超時時間和中斷沒有***的配置策略，要根據自己的場景來動態調整，在系統遇到高并發或者異常時，我們要保護什么，放棄什么，要有權衡。

【本文是51CTO專欄作者“張開濤”的原創文章，作者微信公眾號：開濤的博客( kaitao-1234567)】

戳這里，看該作者更多好文