很多開發者談到Java多線程開發，僅僅停留在new Thread(...).start()或直接使用Executor框架這個層面，對于線程的管理和控制卻不夠深入，通過讀《Java并發編程實踐》了解到了很多不為我知但又非常重要的細節，今日整理如下。
不應用線程池的缺點
有些開發者圖省事，遇到需要多線程處理的地方，直接new Thread(...).start()，對于一般場景是沒問題的，但如果是在并發請求很高的情況下，就會有些隱患：
- 新建線程的開銷。線程雖然比進程要輕量許多，但對于JVM來說，新建一個線程的代價還是挺大的，決不同于新建一個對象
- 資源消耗量。沒有一個池來限制線程的數量，會導致線程的數量直接取決于應用的并發量，這樣有潛在的線程數據巨大的可能，那么資源消耗量將是巨大的
- 穩定性。當線程數量超過系統資源所能承受的程度，穩定性就會成問題
制定執行策略
在每個需要多線程處理的地方，不管并發量有多大，需要考慮線程的執行策略
- 任務以什么順序執行
- 可以有多少個任何并發執行
- 可以有多少個任務進入等待執行隊列
- 系統過載的時候，應該放棄哪些任務？如何通知到應用程序？
- 一個任務的執行前后應該做什么處理
線程池的類型
不管是通過Executors創建線程池，還是通過Spring來管理，都得清楚知道有哪幾種線程池：
- FixedThreadPool：定長線程池，提交任務時創建線程，直到池的最大容量，如果有線程非預期結束，會補充新線程
- CachedThreadPool：可變線程池，它猶如一個彈簧，如果沒有任務需求時，它回收空閑線程，如果需求增加，則按需增加線程，不對池的大小做限制
- SingleThreadExecutor：單線程。處理不過來的任務會進入FIFO隊列等待執行
- SecheduledThreadPool：周期性線程池。支持執行周期性線程任務
其實，這些不同類型的線程池都是通過構建一個ThreadPoolExecutor來完成的，所不同的是corePoolSize,maximumPoolSize,keepAliveTime,unit,workQueue,threadFactory這么幾個參數。具體可以參見JDK DOC。
線程池飽和策略
由以上線程池類型可知，除了CachedThreadPool其他線程池都有飽和的可能，當飽和以后就需要相應的策略處理請求線程的任務，ThreadPoolExecutor采取的方式通過隊列來存儲這些任務，當然會根據池類型不同選擇不同的隊列，比如FixedThreadPool和SingleThreadExecutor默認采用的是無限長度的LinkedBlockingQueue。但從系統可控性講，最好的做法是使用定長的ArrayBlockingQueue或有限的LinkedBlockingQueue，并且當達到上限時通過ThreadPoolExecutor.setRejectedExecutionHandler方法設置一個拒絕任務的策略，JDK提供了AbortPolicy、CallerRunsPolicy、DiscardPolicy、DiscardOldestPolicy幾種策略，具體差異可見JDK DOC
線程無依賴性
多線程任務設計上盡量使得各任務是獨立無依賴的，所謂依賴性可兩個方面：
- 線程之間的依賴性。如果線程有依賴可能會造成死鎖或饑餓
- 調用者與線程的依賴性。調用者得監視線程的完成情況，影響可并發量
當然，在有些業務里確實需要一定的依賴性，比如調用者需要得到線程完成后結果，傳統的Thread是不便完成的，因為run方法無返回值，只能通過一些共享的變量來傳遞結果，但在Executor框架里可以通過Future和Callable實現需要有返回值的任務，當然線程的異步性導致需要有相應機制來保證調用者能等待任務完成，關于Future和Callable的用法見下面的實例就一目了然了：
- public class FutureRenderer {
- private final ExecutorService executor = ...;
- void renderPage(CharSequence source) {
- final List<ImageInfo> imageInfos = scanForImageInfo(source);
- Callable<List<ImageData>> task =
- new Callable<List<ImageData>>() {
- public List<ImageData> call() {
- List<ImageData> result
- = new ArrayList<ImageData>();
- for (ImageInfo imageInfo : imageInfos)
- result.add(imageInfo.downloadImage());
- return result;
- }
- };
- Future<List<ImageData>> future = executor.submit(task);
- renderText(source);
- try {
- List<ImageData> imageData = future.get();
- for (ImageData data : imageData)
- renderImage(data);
- } catch (InterruptedException e) {
- // Re-assert the thread's interrupted status
- Thread.currentThread().interrupt();
- // We don't need the result, so cancel the task too
- future.cancel(true);
- } catch (ExecutionException e) {
- throw launderThrowable(e.getCause());
- }
- }
- }
以上代碼關鍵在于List<ImageData> imageData = future.get();如果Callable類型的任務沒有執行完時，調用者會阻塞等待。不過這樣的方式還是得謹慎使用，很容易造成不良設計。另外對于這種需要等待的場景，就需要設置一個最大容忍時間timeout，設置方法可以在future.get()加上timeout參數，或是再調用ExecutorService.invokeAll 加上timeout參數
線程的取消與關閉
一般的情況下是讓線程運行完成后自行關閉，但有些時候也會中途取消或關閉線程，比如以下情況：
- 調用者強制取消。比如一個長時間運行的任務，用戶點擊"cancel"按鈕強行取消
- 限時任務
- 發生不可處理的任務
- 整個應用程序或服務的關閉
因此需要有相應的取消或關閉的方法和策略來控制線程，一般有以下方法：
1）通過變量標識來控制
這種方式比較老土，但使用得非常廣泛，主要缺點是對有阻塞的操作控制不好，代碼示例如下所示：
- public class PrimeGenerator implements Runnable {
- @GuardedBy("this")
- private final List<BigInteger> primes
- = new ArrayList<BigInteger>();
- private volatile boolean cancelled;
- public void run() {
- BigInteger p = BigInteger.ONE;
- while (!cancelled ) {
- p = p.nextProbablePrime();
- synchronized (this) {
- primes.add(p);
- }
- }
- }
- public void cancel() { cancelled = true; }
- public synchronized List<BigInteger> get() {
- return new ArrayList<BigInteger>(primes);
- }
- }
如果有任務需要在JVM關閉之前做一些清理工作，而不是被JVM強硬關閉掉，可以使用JVM的鉤子技術，其實JVM鉤子也只是個很普通的技術，也就是用個map把一些需要JVM關閉前啟動的任務保存下來，在JVM關閉過程中的某個環節來并發啟動這些任務線程。具體使用示例如下：