無(wú)為

Thread t = new Thread(new Runnable() { 
  public void run() { /* do work */ }
}
t.start();
重新使用線程


因?yàn)槎鄠€(gè)原因，類(lèi)似 Swing GUI 的框架為事件任務(wù)創(chuàng)建單一線程，而不是為每項(xiàng)任務(wù)創(chuàng)建新的線程。首先是因?yàn)閯?chuàng)建線程會(huì)有間接成本，所以創(chuàng)建線程來(lái)執(zhí)行



簡(jiǎn)單任務(wù)將是一種資源浪費(fèi)。通過(guò)重新使用事件線程來(lái)處理多個(gè)事件，啟動(dòng)和拆卸成本（隨平臺(tái)而變）會(huì)分?jǐn)傇诙鄠€(gè)事件上。 



Swing 為事件使用單一后臺(tái)線程的另一個(gè)原因是確保事件不會(huì)互相干涉，因?yàn)橹钡角耙皇录Y(jié)束，下一事件才開(kāi)始處理。該方法簡(jiǎn)化了事件處理程序的編寫(xiě)。



使用多個(gè)線程，將要做更多的工作來(lái)確保一次僅一個(gè)線程地執(zhí)行線程相關(guān)的代碼。 



  

大多數(shù)服務(wù)器應(yīng)用程序（如 Web 服務(wù)器、POP 服務(wù)器、數(shù)據(jù)庫(kù)服務(wù)器或文件服務(wù)器）代表遠(yuǎn)程客戶機(jī)處理請(qǐng)求，這些客戶機(jī)通常使用 socket 連接到服務(wù)器。對(duì)于每個(gè)請(qǐng)求，通常要進(jìn)行少量處理（獲得該文件的代碼塊，并將其發(fā)送回 socket），但是可能會(huì)有大量（且不受限制）的客戶機(jī)請(qǐng)求服務(wù)。 
用于構(gòu)建服務(wù)器應(yīng)用程序的簡(jiǎn)單化模型會(huì)為每個(gè)請(qǐng)求創(chuàng)建新的線程。下列代碼段實(shí)現(xiàn)簡(jiǎn)單的 Web 服務(wù)器，它接受端口 80 的 socket 連接，并創(chuàng)建新的線程來(lái)處理請(qǐng)求。不幸的是，該代碼不是實(shí)現(xiàn) Web 服務(wù)器的好方法，因?yàn)樵谥刎?fù)載條件下它將失敗，停止整臺(tái)服務(wù)器。 

class UnreliableWebServer { 
  public static void main(String[] args) {
    ServerSocket socket = new ServerSocket(80);
      while (true) {
      final Socket connection = socket.accept();
      Runnable r = new Runnable() {
        public void run() {
          handleRequest(connection);
        }
      };
      // Don't do this!
      new Thread(r).start();
    }
  }
}

當(dāng)服務(wù)器被請(qǐng)求吞沒(méi)時(shí)，UnreliableWebServer 類(lèi)不能很好地處理這種情況。每次有請(qǐng)求時(shí)，就會(huì)創(chuàng)建新的類(lèi)。根據(jù)操作系統(tǒng)和可用內(nèi)存，可以創(chuàng)建的線程數(shù)是有限的。
不幸的是，您通常不知道限制是多少 -- 只有當(dāng)應(yīng)用程序因?yàn)?OutOfMemoryError 而崩潰時(shí)才發(fā)現(xiàn)。 
如果足夠快地在這臺(tái)服務(wù)器上拋出請(qǐng)求的話，最終其中一個(gè)線程創(chuàng)建將失敗，生成的 Error 會(huì)關(guān)閉整個(gè)應(yīng)用程序。當(dāng)一次僅能有效支持很少線程時(shí)，沒(méi)有必要?jiǎng)?chuàng)建上千個(gè)
線程，無(wú)論如何，這樣使用資源可能會(huì)損害性能。創(chuàng)建線程會(huì)使用相當(dāng)一部分內(nèi)存，其中包括有兩個(gè)堆棧（Java 和 C），以及每線程數(shù)據(jù)結(jié)構(gòu)。如果創(chuàng)建過(guò)多線程，其中
每個(gè)線程都將占用一些 CPU 時(shí)間，結(jié)果將使用許多內(nèi)存來(lái)支持大量線程，每個(gè)線程都運(yùn)行得很慢。這樣就無(wú)法很好地使用計(jì)算資源。 

 使用線程池解決問(wèn)題

為任務(wù)創(chuàng)建新的線程并不一定不好，但是如果創(chuàng)建任務(wù)的頻率高，而平均任務(wù)持續(xù)時(shí)間低，我們可以看到每項(xiàng)任務(wù)創(chuàng)建一個(gè)新的線程將產(chǎn)生性能（如果負(fù)載不可預(yù)知，還


有穩(wěn)定性）問(wèn)題。 


如果不是每項(xiàng)任務(wù)創(chuàng)建一個(gè)新的線程，則服務(wù)器應(yīng)用程序必須采取一些方法來(lái)限制一次可以處理的請(qǐng)求數(shù)。這意味著每次需要啟動(dòng)新的任務(wù)時(shí)，它不能僅調(diào)用下列代碼。 

  new Thread(runnable).start()

管理一大組小任務(wù)的標(biāo)準(zhǔn)機(jī)制是組合工作隊(duì)列和線程池。工作隊(duì)列就是要處理的任務(wù)的隊(duì)列，前面描述的 Queue 類(lèi)完全適合。線程池是線程的集合，每個(gè)線程都提取公用
工作隊(duì)列。當(dāng)一個(gè)工作線程完成任務(wù)處理后，它會(huì)返回隊(duì)列，查看是否有其他任務(wù)需要處理。如果有，它會(huì)轉(zhuǎn)移到下一個(gè)任務(wù)，并開(kāi)始處理。 
線程池為線程生命周期間接成本問(wèn)題和資源崩潰問(wèn)題提供了解決方案。通過(guò)對(duì)多個(gè)任務(wù)重新使用線程，創(chuàng)建線程的間接成本將分布到多個(gè)任務(wù)中。作為一種額外好處，因?yàn)?br/>請(qǐng)求到達(dá)時(shí)，線程已經(jīng)存在，從而可以消除由創(chuàng)建線程引起的延遲。因此，可以立即處理請(qǐng)求，使應(yīng)用程序更易響應(yīng)。而且，通過(guò)正確調(diào)整線程池中的線程數(shù)，可以強(qiáng)制超
出特定限制的任何請(qǐng)求等待，直到有線程可以處理它，它們等待時(shí)所消耗的資源要少于使用額外線程所消耗的資源，這樣可以防止資源崩潰。
 Executor 框架

java.util.concurrent 包中包含靈活的線程池實(shí)現(xiàn)，但是更重要的是，它包含用于管理實(shí)現(xiàn) Runnable 的任務(wù)的執(zhí)行的整個(gè)框架。該框架稱(chēng)為 Executor 框架。 
Executor 接口相當(dāng)簡(jiǎn)單。它描述將運(yùn)行 Runnable 的對(duì)象： 

public interface Executor { 
  void execute(Runnable command);
}

任務(wù)運(yùn)行于哪個(gè)線程不是由該接口指定的，這取決于使用的 Executor 的實(shí)現(xiàn)。它可以運(yùn)行于后臺(tái)線程，如 Swing 事件線程，或者運(yùn)行于線程池，或者調(diào)用線程，或者
新的線程，它甚至可以運(yùn)行于其他 JVM！通過(guò)同步的 Executor 接口提交任務(wù)，從任務(wù)執(zhí)行策略中刪除任務(wù)提交。Executor 接口獨(dú)自關(guān)注任務(wù)提交 -- 這是 
Executor 實(shí)現(xiàn)的選擇，確定執(zhí)行策略。這使在部署時(shí)調(diào)整執(zhí)行策略（隊(duì)列限制、池大小、優(yōu)先級(jí)排列等等）更加容易，更改的代碼最少。 
java.util.concurrent 中的大多數(shù) Executor 實(shí)現(xiàn)還實(shí)現(xiàn) ExecutorService 接口，這是對(duì) Executor 的擴(kuò)展，它還管理執(zhí)行服務(wù)的生命周期。這使它們更易
于
管理，并向生命可能比單獨(dú) Executor 的生命更長(zhǎng)的應(yīng)用程序提供服務(wù)。 

public interface ExecutorService extends Executor {
  void shutdown();
  List<Runnable> shutdownNow();
  boolean isShutdown();
  boolean isTerminated();
  boolean awaitTermination(long timeout,
                           TimeUnit unit);
  // other convenience methods for submitting tasks
}

Executor

java.util.concurrent 包包含多個(gè) Executor 實(shí)現(xiàn)，每個(gè)實(shí)現(xiàn)都實(shí)現(xiàn)不同的執(zhí)行策略。什么是執(zhí)行策略？執(zhí)行策略定義何時(shí)在哪個(gè)線程中運(yùn)行任務(wù)，

執(zhí)行任務(wù)可能消耗的資源級(jí)別（線程、內(nèi)存等等），以及如果執(zhí)行程序超載該怎么辦。 

執(zhí)行程序通常通過(guò)工廠方法例示，而不是通過(guò)構(gòu)造函數(shù)。Executors 類(lèi)包含用于構(gòu)造許多不同類(lèi)型的 Executor 實(shí)現(xiàn)的靜態(tài)工廠方法：

• Executors.newCachedThreadPool() 創(chuàng)建不限制大小的線程池，但是當(dāng)以前創(chuàng)建的線程可以使用時(shí)將重新使用那些線程。如果沒(méi)有現(xiàn)有線程可用，
• 將創(chuàng)建新的線程并將其添加到池中。使用不到 60 秒的線程將終止并從緩存中刪除。
  
  
• Executors.newFixedThreadPool(int n) 創(chuàng)建線程池，其重新使用在不受限制的隊(duì)列之外運(yùn)行的固定線程組。在關(guān)閉前，所有線程都會(huì)因?yàn)閳?zhí)行
• 過(guò)程中的失敗而終止，如果需要執(zhí)行后續(xù)任務(wù)，將會(huì)有新的線程來(lái)代替這些線程。
  
  
• Executors.newSingleThreadExecutor() 創(chuàng)建 Executor，其使用在不受限制的隊(duì)列之外運(yùn)行的單一工作線程，與 Swing 事件線程非常相似。
• 保證順序執(zhí)行任務(wù)，在任何給定時(shí)間，不會(huì)有多個(gè)任務(wù)處于活動(dòng)狀態(tài)。

更可靠的 Web 服務(wù)器 -- 使用 Executor

前面 如何不對(duì)任務(wù)進(jìn)行管理 中的代碼顯示了如何不用編寫(xiě)可靠服務(wù)器應(yīng)用程序。幸運(yùn)的是，修復(fù)這個(gè)示例非常簡(jiǎn)單，只需將 Thread.start() 調(diào)用替換

為向 Executor 提交任務(wù)即可：

class ReliableWebServer { 
  Executor pool =
    Executors.newFixedThreadPool(7);
    public static void main(String[] args) {
    ServerSocket socket = new ServerSocket(80);
      while (true) {
      final Socket connection = socket.accept();
      Runnable r = new Runnable() {
        public void run() {
          handleRequest(connection);
        }
      };
      pool.execute(r);
    }
  }
}

注意，本例與前例之間的區(qū)別僅在于 Executor 的創(chuàng)建以及如何提交執(zhí)行的任務(wù)。 

定制 ThreadPoolExecutor

 
 
Executors 中的 newFixedThreadPool 和 newCachedThreadPool 工廠方法返回的 Executor 是類(lèi) ThreadPoolExecutor 的實(shí)例，是高度可定制的。 
通過(guò)使用包含 ThreadFactory 變量的工廠方法或構(gòu)造函數(shù)的版本，可以定義池線程的創(chuàng)建。ThreadFactory 是工廠對(duì)象，其構(gòu)造執(zhí)行程序要使用的新線程。
使用定制的線程工廠，創(chuàng)建的線程可以包含有用的線程名稱(chēng)，并且這些線程是守護(hù)線程，屬于特定線程組或具有特定優(yōu)先級(jí)。 
下面是線程工廠的例子，它創(chuàng)建守護(hù)線程，而不是創(chuàng)建用戶線程： 

public class DaemonThreadFactory implements ThreadFactory {
    public Thread newThread(Runnable r) {
        Thread thread = new Thread(r);
        thread.setDaemon(true);
        return thread;
    }
}

有時(shí)，Executor 不能執(zhí)行任務(wù)，因?yàn)樗呀?jīng)關(guān)閉或者因?yàn)?Executor 使用受限制隊(duì)列存儲(chǔ)等待任務(wù)，而該隊(duì)列已滿。在這種情況下，需要咨詢(xún)執(zhí)行程序的 
RejectedExecutionHandler 來(lái)確定如何處理任務(wù) -- 拋出異常（默認(rèn)情況），放棄任務(wù)，在調(diào)用者的線程中執(zhí)行任務(wù)，或放棄隊(duì)列中最早的任務(wù)以為
新任務(wù)騰出空間。ThreadPoolExecutor.setRejectedExecutionHandler 可以設(shè)置拒絕的執(zhí)行處理程序。 
還可以擴(kuò)展 ThreadPoolExecutor，并覆蓋方法 beforeExecute 和 afterExecute，以添加裝置，添加記錄，添加計(jì)時(shí)，重新初始化線程本地變量，
或進(jìn)行其他執(zhí)行定制。 
 
 需要特別考慮的問(wèn)題
 
使用 Executor 框架會(huì)從執(zhí)行策略中刪除任務(wù)提交，一般情況下，人們希望這樣，那是因?yàn)樗试S我們靈活地調(diào)整執(zhí)行策略，不必更改許多位置的代碼。然而，當(dāng)提交代
碼暗含假設(shè)特定執(zhí)行策略時(shí)，存在多種情況，在這些情況下，
重要的是選擇的 Executor 實(shí)現(xiàn)一致的執(zhí)行策略。 
這類(lèi)情況中的其中的一種就是一些任務(wù)同時(shí)等待其他任務(wù)完成。在這種情況下，當(dāng)線程池沒(méi)有足夠的線程時(shí)，如果所有當(dāng)前執(zhí)行的任務(wù)都在等待另一項(xiàng)任務(wù)，而該任務(wù)因?yàn)?br/>線程池已滿不能執(zhí)行，那么線程池可能會(huì)死鎖。 
另一種相似的情況是一組線程必須作為共同操作組一起工作。在這種情況下，需要確保線程池能夠容納所有線程。 
如果應(yīng)用程序?qū)μ囟▓?zhí)行程序進(jìn)行了特定假設(shè)，那么應(yīng)該在 Executor 定義和初始化的附近對(duì)這些進(jìn)行說(shuō)明，從而使善意的更改不會(huì)破壞應(yīng)用程序的正確功能。 

 
創(chuàng)建 Executor 時(shí)，人們普遍會(huì)問(wèn)的一個(gè)問(wèn)題是"線程池應(yīng)該有多大？"。當(dāng)然，答案取決于硬件和將執(zhí)行的任務(wù)類(lèi)型（它們是受計(jì)算限制或是受 IO 的限制？）。 
如果線程池太小，資源可能不能被充分利用，在一些任務(wù)還在工作隊(duì)列中等待執(zhí)行時(shí)，可能會(huì)有處理器處于閑置狀態(tài)。 
另一方面，如果線程池太大，則將有許多有效線程，因?yàn)榇罅烤€程或有效任務(wù)使用內(nèi)存，或者因?yàn)槊宽?xiàng)任務(wù)要比使用少量線程有更多上下文切換，性能可能會(huì)受損。 
所以假設(shè)為了使處理器得到充分使用，線程池應(yīng)該有多大？如果知道系統(tǒng)有多少處理器和任務(wù)的計(jì)算時(shí)間和等待時(shí)間的近似比率，Amdahl 法則提供很好的近似公式。 
用 WT 表示每項(xiàng)任務(wù)的平均等待時(shí)間，ST 表示每項(xiàng)任務(wù)的平均服務(wù)時(shí)間（計(jì)算時(shí)間）。則 WT/ST 是每項(xiàng)任務(wù)等待所用時(shí)間的百分比。對(duì)于 N 處理器系統(tǒng)，池中可以
近似有 N*(1+WT/ST) 個(gè)線程。 
好的消息是您不必精確估計(jì) WT/ST。"合適的"池大小的范圍相當(dāng)大；只需要避免"過(guò)大"和"過(guò)小"的極端情況即可。
 
Future 接口
  
Future 接口允許表示已經(jīng)完成的任務(wù)、正在執(zhí)行過(guò)程中的任務(wù)或者尚未開(kāi)始執(zhí)行的任務(wù)。通過(guò) Future 接口，可以嘗試取消尚未完成的任務(wù)，查詢(xún)?nèi)蝿?wù)已經(jīng)完成還是
取消了，以及提取（或等待）任務(wù)的結(jié)果值。 
FutureTask 類(lèi)實(shí)現(xiàn)了 Future，并包含一些構(gòu)造函數(shù)，允許將 Runnable 或 Callable（會(huì)產(chǎn)生結(jié)果的 Runnable）和 Future 接口封裝。因?yàn)?FutureTask 
也實(shí)現(xiàn) Runnable，所以可以只將 FutureTask 提供給 Executor。一些提交方法（如 ExecutorService.submit()）除了提交任務(wù)之外，還將返回 Future
 接口。 
Future.get() 方法檢索任務(wù)計(jì)算的結(jié)果（或如果任務(wù)完成，但有異常，則拋出 ExecutionException）。如果任務(wù)尚未完成，那么 Future.get() 將被阻塞，
直到任務(wù)完成；如果任務(wù)已經(jīng)完成，那么它將立即返回結(jié)果。 
 
使用 Future 構(gòu)建緩存 
  
該示例代碼與 java.util.concurrent 中的多個(gè)類(lèi)關(guān)聯(lián)，突出顯示了 Future 的功能。它實(shí)現(xiàn)緩存，使用 Future 描述緩存值，該值可能已經(jīng)計(jì)算，或者可能在其他線程中"正在構(gòu)造"。 
它利用 ConcurrentHashMap 中的原子 putIfAbsent() 方法，確保僅有一個(gè)線程試圖計(jì)算給定關(guān)鍵字的值。如果其他線程隨后請(qǐng)求同一關(guān)鍵字的值，它僅能等待（通過(guò) Future.get() 的幫助）第一個(gè)線程完成。因此兩個(gè)線程不會(huì)計(jì)算相同的值。 

public class Cache<K, V> {
    ConcurrentMap<K, FutureTask<V>> map = new ConcurrentHashMap();
    Executor executor = Executors.newFixedThreadPool(8);

    public V get(final K key) {
        FutureTask<V> f = map.get(key);
        if (f == null) {
            Callable<V> c = new Callable<V>() {
                public V call() {
                    // return value associated with key
                }
            };
            f = new FutureTask<V>(c);
            FutureTask old = map.putIfAbsent(key, f);
            if (old == null)
                executor.execute(f);
            else
                f = old;
        }
        return f.get();
    }
}

 
 CompletionService
  
CompletionService 將執(zhí)行服務(wù)與類(lèi)似 Queue 的接口組合，從任務(wù)執(zhí)行中刪除任務(wù)結(jié)果的處理。CompletionService 接口包含用來(lái)提交將要執(zhí)行的任務(wù)的 submit() 方法和用來(lái)詢(xún)問(wèn)下一完成任務(wù)的 take()/poll() 方法。 
CompletionService 允許應(yīng)用程序結(jié)構(gòu)化，使用 Producer/Consumer 模式，其中生產(chǎn)者創(chuàng)建任務(wù)并提交，消費(fèi)者請(qǐng)求完成任務(wù)的結(jié)果并處理這些結(jié)果。CompletionService 接口由 ExecutorCompletionService 類(lèi)實(shí)現(xiàn)，該類(lèi)使用 Executor 處理任務(wù)并從 CompletionService 導(dǎo)出 submit/poll/take 方法。 
下列代碼使用 Executor 和 CompletionService 來(lái)啟動(dòng)許多"solver"任務(wù)，并使用第一個(gè)生成非空結(jié)果的任務(wù)的結(jié)果，然后取消其余任務(wù)： 

void solve(Executor e, Collection<Callable<Result>> solvers) 
      throws InterruptedException {
        CompletionService<Result> ecs = new ExecutorCompletionService<Result>(e);
        int n = solvers.size();
        List<Future<Result>> futures = new ArrayList<Future<Result>>(n);
        Result result = null;
        try {
            for (Callable<Result> s : solvers)
                futures.add(ecs.submit(s));
            for (int i = 0; i < n; ++i) {
                try {
                    Result r = ecs.take().get();
                    if (r != null) {
                        result = r;
                        break;
                    }
                } catch(ExecutionException ignore) {}
            }
        }
        finally {
            for (Future<Result> f : futures)
                f.cancel(true);
        }

        if (result != null)
            use(result);
    }

java.util.concurrent 中其他類(lèi)別的有用的類(lèi)也是同步工具。這組類(lèi)相互協(xié)作，控制一個(gè)或多個(gè)線程的執(zhí)行流。 
Semaphore、CyclicBarrier、CountdownLatch 和 Exchanger 類(lèi)都是同步工具的例子。每個(gè)類(lèi)都有線程可以調(diào)用的方法，
方法是否被阻塞取決于正在使用的特定同步工具的狀態(tài)和規(guī)則。 

Semaphore

Semaphore 類(lèi)實(shí)現(xiàn)標(biāo)準(zhǔn) Dijkstra 計(jì)數(shù)信號(hào)。計(jì)數(shù)信號(hào)可以認(rèn)為具有一定數(shù)量的許可權(quán)，該許可權(quán)可以獲得或釋放。如果有剩余的許可權(quán)，acquire() 方法將成功，
否則該方法將被阻塞，直到有可用的許可權(quán)（通過(guò)其他線程釋放許可權(quán)）。線程一次可以獲得多個(gè)許可權(quán)。 
計(jì)數(shù)信號(hào)可以用于限制有權(quán)對(duì)資源進(jìn)行并發(fā)訪問(wèn)的線程數(shù)。該方法對(duì)于實(shí)現(xiàn)資源池或限制 Web 爬蟲(chóng)（Web crawler）中的輸出 socket 連接非常有用。 
注意信號(hào)不跟蹤哪個(gè)線程擁有多少許可權(quán)；這由應(yīng)用程序來(lái)決定，以確保何時(shí)線程釋放許可權(quán)，該信號(hào)表示其他線程擁有許可權(quán)或者正在釋放許可權(quán)，以及其他線程知道
它的許可權(quán)已釋放。 
 互斥
  
計(jì)數(shù)信號(hào)的一種特殊情況是互斥，或者互斥信號(hào)。互斥就是具有單一許可權(quán)的計(jì)數(shù)信號(hào)，意味著在給定時(shí)間僅一個(gè)線程可以具有許可權(quán)（也稱(chēng)為二進(jìn)制信號(hào)）。互斥可以
用于管理對(duì)共享資源的獨(dú)占訪問(wèn)。 
雖然互斥許多地方與鎖定一樣，但互斥還有一個(gè)鎖定通常沒(méi)有的其他功能，就是互斥可以由具有許可權(quán)的線程之外的其他線程來(lái)釋放。這在死鎖恢復(fù)時(shí)會(huì)非常有用。

CyclicBarrier 類(lèi)可以幫助同步，它允許一組線程等待整個(gè)線程組到達(dá)公共屏障點(diǎn)。CyclicBarrier 是使用整型變量構(gòu)造的，其確定組中的線程數(shù)。當(dāng)一個(gè)線程到達(dá)屏障時(shí)（通過(guò)調(diào)用 CyclicBarrier.await()），它會(huì)被阻塞，直到所有線程都到達(dá)屏障，然后在該點(diǎn)允許所有線程繼續(xù)執(zhí)行。該操作與許多家庭逛商業(yè)街相似 -- 每個(gè)家庭成員都自己走，并商定 1:00 在電影院集合。當(dāng)您到電影院但不是所有人都到了時(shí)，您會(huì)坐下來(lái)等其他人到達(dá)。然后所有人一起離開(kāi)。 
認(rèn)為屏障是循環(huán)的是因?yàn)樗梢灾匦率褂茫灰坏┧芯€程都已經(jīng)在屏障處集合并釋放，則可以將該屏障重新初始化到它的初始狀態(tài)。 
還可以指定在屏障處等待時(shí)的超時(shí)；如果在該時(shí)間內(nèi)其余線程還沒(méi)有到達(dá)屏障，則認(rèn)為屏障被打破，所有正在等待的線程會(huì)收到 BrokenBarrierException。 
下列代碼將創(chuàng)建 CyclicBarrier 并啟動(dòng)一組線程，每個(gè)線程將計(jì)算問(wèn)題的一部分，等待所有其他線程結(jié)束之后，再檢查解決方案是否達(dá)成一致。如果不一致，那么每個(gè)工作線程將開(kāi)始另一個(gè)迭代。該例將使用 CyclicBarrier 變量，它允許注冊(cè) Runnable，在所有線程到達(dá)屏障但還沒(méi)有釋放任何線程時(shí)執(zhí)行 Runnable。 

class Solver { // Code sketch

  void solve(final Problem p, int nThreads) {
  final CyclicBarrier barrier = 
    new CyclicBarrier(nThreads,
      new Runnable() {
        public void run() { p.checkConvergence(); }}
    );
    for (int i = 0; i < nThreads; ++i) {
      final int id = i;
      Runnable worker = new Runnable() {
        final Segment segment = p.createSegment(id);
        public void run() {
          try {
            while (!p.converged()) {
              segment.update();
              barrier.await();
            }
          }
          catch(Exception e) { return; }
        }
      };
      new Thread(worker).start();
   }
}

CountdownLatch 類(lèi)與 CyclicBarrier 相似，因?yàn)樗慕巧菍?duì)已經(jīng)在它們中間分?jǐn)偭藛?wèn)題的一組線程進(jìn)行協(xié)調(diào)。它也是使用整型變量構(gòu)造的，指明計(jì)數(shù)的初始值，但是與 CyclicBarrier 不同的是，CountdownLatch 不能重新使用。 
其中，CyclicBarrier 是到達(dá)屏障的所有線程的大門(mén)，只有當(dāng)所有線程都已經(jīng)到達(dá)屏障或屏障被打破時(shí)，才允許這些線程通過(guò)，CountdownLatch 將到達(dá)和等待功能分離。任何線程都可以通過(guò)調(diào)用 countDown() 減少當(dāng)前計(jì)數(shù)，這種不會(huì)阻塞線程，而只是減少計(jì)數(shù)。await() 方法的行為與 CyclicBarrier.await() 稍微有所不同，調(diào)用 await() 任何線程都會(huì)被阻塞，直到閂鎖計(jì)數(shù)減少為零，在該點(diǎn)等待的所有線程才被釋放，對(duì) await() 的后續(xù)調(diào)用將立即返回。 
當(dāng)問(wèn)題已經(jīng)分解為許多部分，每個(gè)線程都被分配一部分計(jì)算時(shí)，CountdownLatch 非常有用。在工作線程結(jié)束時(shí)，它們將減少計(jì)數(shù)，協(xié)調(diào)線程可以在閂鎖處等待當(dāng)前這一批計(jì)算結(jié)束，然后繼續(xù)移至下一批計(jì)算。 
相反地，具有計(jì)數(shù) 1 的 CountdownLatch 類(lèi)可以用作"啟動(dòng)大門(mén)"，來(lái)立即啟動(dòng)一組線程；工作線程可以在閂鎖處等待，協(xié)調(diào)線程減少計(jì)數(shù)，從而立即釋放所有工作線程。下例使用兩個(gè) CountdownLatche。一個(gè)作為啟動(dòng)大門(mén)，一個(gè)在所有工作線程結(jié)束時(shí)釋放線程： 

class Driver { // ...
   void main() throws InterruptedException {
     CountDownLatch startSignal = new CountDownLatch(1);
     CountDownLatch doneSignal = new CountDownLatch(N);

     for (int i = 0; i < N; ++i) // create and start threads
       new Thread(new Worker(startSignal, doneSignal)).start();

     doSomethingElse();            // don't let them run yet
     startSignal.countDown();      // let all threads proceed
     doSomethingElse();
     doneSignal.await();           // wait for all to finish
   }
 }

 class Worker implements Runnable {
   private final CountDownLatch startSignal;
   private final CountDownLatch doneSignal;
   Worker(CountDownLatch startSignal, CountDownLatch doneSignal) {
      this.startSignal = startSignal;
      this.doneSignal = doneSignal;
   }
   public void run() {
      try {
        startSignal.await();
        doWork();
        doneSignal.countDown();
      } catch (InterruptedException ex) {} // return;
   }
 }

Exchanger 類(lèi)方便了兩個(gè)共同操作線程之間的雙向交換；這樣，就像具有計(jì)數(shù)為 2 的 CyclicBarrier，并且兩個(gè)線程在都到達(dá)屏障時(shí)可以"交換"一些狀態(tài)。（Exchanger 模式有時(shí)也稱(chēng)為聚集。） 

Exchanger 通常用于一個(gè)線程填充緩沖（通過(guò)讀取 socket），而另一個(gè)線程清空緩沖（通過(guò)處理從 socket 收到的命令）的情況。當(dāng)兩個(gè)線程在屏障處集合時(shí)，它們交換緩沖。下列代碼說(shuō)明了這項(xiàng)技術(shù)： 

class FillAndEmpty {
   Exchanger<DataBuffer> exchanger = new Exchanger<DataBuffer>();
   DataBuffer initialEmptyBuffer = new DataBuffer();
   DataBuffer initialFullBuffer = new DataBuffer();

   class FillingLoop implements Runnable {
     public void run() {
       DataBuffer currentBuffer = initialEmptyBuffer;
       try {
         while (currentBuffer != null) {
           addToBuffer(currentBuffer);
           if (currentBuffer.full())
             currentBuffer = exchanger.exchange(currentBuffer);
         }
       } catch (InterruptedException ex) { ... handle ... }
     }
   }

   class EmptyingLoop implements Runnable {
     public void run() {
       DataBuffer currentBuffer = initialFullBuffer;
       try {
         while (currentBuffer != null) {
           takeFromBuffer(currentBuffer);
           if (currentBuffer.empty())
             currentBuffer = exchanger.exchange(currentBuffer);
         }
       } catch (InterruptedException ex) { ... handle ...}
     }
   }

   void start() {
     new Thread(new FillingLoop()).start();
     new Thread(new EmptyingLoop()).start();
   }
 }
鎖定和原子之Lock

Java 語(yǔ)言?xún)?nèi)置了鎖定工具 -- synchronized 關(guān)鍵字。當(dāng)線程獲得監(jiān)視器時(shí)（內(nèi)置鎖定），其他線程如果試圖獲得相同鎖定，那么它們將被阻塞，直到第一個(gè)線程釋放該鎖定。同步還確保隨后獲得相同鎖定的線程可以看到之前的線程在具有該鎖定時(shí)所修改的變量的值，從而確保如果類(lèi)正確地同步了共享狀態(tài)的訪問(wèn)權(quán)，那么線程將不會(huì)看到變量的"失效"值，這是緩存或編譯器優(yōu)化的結(jié)果。 

雖然同步?jīng)]有什么問(wèn)題，但它有一些限制，在一些高級(jí)應(yīng)用程序中會(huì)造成不便。Lock 接口將內(nèi)置監(jiān)視器鎖定的鎖定行為普遍化，允許多個(gè)鎖定實(shí)現(xiàn)，同時(shí)提供一些內(nèi)置鎖定缺少的功能，如計(jì)時(shí)的等待、可中斷的等待、鎖定輪詢(xún)、每個(gè)鎖定有多個(gè)條件等待集合以及無(wú)阻塞結(jié)構(gòu)的鎖定。 

interface Lock {
    void lock(); 
    void lockInterruptibly() throws IE;
    boolean tryLock();
    boolean tryLock(long time, 
                    TimeUnit unit) throws IE;           
    void unlock();
    Condition newCondition() throws
                    UnsupportedOperationException; 
  }
ReentrantLock

ReentrantLock 是具有與隱式監(jiān)視器鎖定（使用 synchronized 方法和語(yǔ)句訪問(wèn)）相同的基本行為和語(yǔ)義的 Lock 的實(shí)現(xiàn)，但它具有擴(kuò)展的能力。 

作為額外收獲，在競(jìng)爭(zhēng)條件下，ReentrantLock 的實(shí)現(xiàn)要比現(xiàn)在的 synchronized 實(shí)現(xiàn)更具有可伸縮性。（有可能在 JVM 的將來(lái)版本中改進(jìn) synchronized 的競(jìng)爭(zhēng)性能。）

這意味著當(dāng)許多線程都競(jìng)爭(zhēng)相同鎖定時(shí)，使用 ReentrantLock 的吞吐量通常要比 synchronized 好。換句話說(shuō)，當(dāng)許多線程試圖訪問(wèn) ReentrantLock 保護(hù)的共享資源時(shí)，

JVM 將花費(fèi)較少的時(shí)間來(lái)調(diào)度線程，而用更多個(gè)時(shí)間執(zhí)行線程。 

雖然 ReentrantLock 類(lèi)有許多優(yōu)點(diǎn)，但是與同步相比，它有一個(gè)主要缺點(diǎn) -- 它可能忘記釋放鎖定。建議當(dāng)獲得和釋放 ReentrantLock 時(shí)使用下列結(jié)構(gòu)： 

Lock lock = new ReentrantLock();
...
lock.lock(); 
try { 
  // perform operations protected by lock
}
catch(Exception ex) {
 // restore invariants
}
finally { 
  lock.unlock(); 
}

因?yàn)殒i定失誤（忘記釋放鎖定）的風(fēng)險(xiǎn)，所以對(duì)于基本鎖定，強(qiáng)烈建議您繼續(xù)使用 synchronized，除非真的需要 ReentrantLock 額外的靈活性和可伸縮性。

ReentrantLock 是用于高級(jí)應(yīng)用程序的高級(jí)工具 -- 有時(shí)需要，但有時(shí)用原來(lái)的方法就很好。 

Condition

就像 Lock 接口是同步的具體化，Condition 接口是 Object 中 wait() 和 notify() 方法的具體化。Lock 中的一個(gè)方法是 newCondition()，
它要求鎖定向該鎖定返回新的 Condition 對(duì)象限制。await()、signal() 和 signalAll() 方法類(lèi)似于 wait()、notify() 和 notifyAll()，
但增加了靈活性，每個(gè) Lock 都可以創(chuàng)建多個(gè)條件變量。這簡(jiǎn)化了一些并發(fā)算法的實(shí)現(xiàn)。 

ReadWriteLock

ReentrantLock 實(shí)現(xiàn)的鎖定規(guī)則非常簡(jiǎn)單 -- 每當(dāng)一個(gè)線程具有鎖定時(shí)，其他線程必須等待，直到該鎖定可用。有時(shí)，當(dāng)對(duì)數(shù)據(jù)結(jié)構(gòu)的讀取通常多于修改時(shí)，
可以使用更復(fù)雜的稱(chēng)為讀寫(xiě)鎖定的鎖定結(jié)構(gòu)，它允許有多個(gè)并發(fā)讀者，同時(shí)還允許一個(gè)寫(xiě)入者獨(dú)占鎖定。該方法在一般情況下（只讀）提供了更大的并發(fā)性，同時(shí)
在必要時(shí)仍提供獨(dú)占訪問(wèn)的安全性。ReadWriteLock 接口和 ReentrantReadWriteLock 類(lèi)提供這種功能 -- 多讀者、單寫(xiě)入者鎖定規(guī)則，可以用這種功能
來(lái)保護(hù)共享的易變資源。 
 原子變量
  
即使大多數(shù)用戶將很少直接使用它們，原子變量類(lèi)（AtomicInteger、AtomicLong、AtomicReference 等等）也有充分理由是最顯著的新并發(fā)類(lèi)。這些類(lèi)公開(kāi)對(duì)
 JVM 的低級(jí)別改進(jìn)，允許進(jìn)行具有高度可伸縮性的原子讀-修改-寫(xiě)操作。大多數(shù)現(xiàn)代 CPU 都有原子讀-修改-寫(xiě)的原語(yǔ)，比如比較并交換（CAS）或加載鏈接/條件存儲(chǔ)
（LL/SC）。原子變量類(lèi)使用硬件提供的最快的并發(fā)結(jié)構(gòu)來(lái)實(shí)現(xiàn)。 
許多并發(fā)算法都是根據(jù)對(duì)計(jì)數(shù)器或數(shù)據(jù)結(jié)構(gòu)的比較并交換操作來(lái)定義的。通過(guò)暴露高性能的、高度可伸縮的 CAS 操作（以原子變量的形式），用 Java 語(yǔ)言實(shí)現(xiàn)高性能、
無(wú)等待、無(wú)鎖定的并發(fā)算法已經(jīng)變得可行。 
幾乎 java.util.concurrent 中的所有類(lèi)都是在 ReentrantLock 之上構(gòu)建的，ReentrantLock 則是在原子變量類(lèi)的基礎(chǔ)上構(gòu)建的。所以，雖然僅少數(shù)并發(fā)專(zhuān)家
使用原子變量類(lèi)，但 java.util.concurrent 類(lèi)的很多可伸縮性改進(jìn)都是由它們提供的。 
原子變量主要用于為原子地更新"熱"字段提供有效的、細(xì)粒度的方式，"熱"字段是指由多個(gè)線程頻繁訪問(wèn)和更新的字段。另外，原子變量還是計(jì)數(shù)器或生成序號(hào)的自然
機(jī)制。 
性能與可伸縮性
 
雖然 java.util.concurrent 努力的首要目標(biāo)是使編寫(xiě)正確、線程安全的類(lèi)更加容易，但它還有一個(gè)次要目標(biāo)，就是提供可伸縮性。可伸縮性與性能完全不同，實(shí)際上，
可伸縮性有時(shí)要以性能為代價(jià)來(lái)獲得。 
性能是"可以快速執(zhí)行此任務(wù)的程度"的評(píng)測(cè)。可伸縮性描述應(yīng)用程序的吞吐量如何表現(xiàn)為它的工作量和可用計(jì)算資源增加。可伸縮的程序可以按比例使用更多的處理器、
內(nèi)存或 I/O 帶寬來(lái)處理更多個(gè)工作量。當(dāng)我們?cè)诓l(fā)環(huán)境中談?wù)摽缮炜s性時(shí)，我們是在問(wèn)當(dāng)許多線程同時(shí)訪問(wèn)給定類(lèi)時(shí)，這個(gè)類(lèi)的執(zhí)行情況。 
java.util.concurrent 中的低級(jí)別類(lèi) ReentrantLock 和原子變量類(lèi)的可伸縮性要比內(nèi)置監(jiān)視器（同步）鎖定高得多。因此，使用 ReentrantLock 或原子變量
類(lèi)來(lái)協(xié)調(diào)共享訪問(wèn)的類(lèi)也可能更具有可伸縮性。 
 Hashtable 與 ConcurrentHashMap
  
作為可伸縮性的例子，ConcurrentHashMap 實(shí)現(xiàn)設(shè)計(jì)的可伸縮性要比其線程安全的上一代 Hashtable 的可伸縮性強(qiáng)得多。Hashtable 一次只允許一個(gè)線程訪問(wèn) 
Map；ConcurrentHashMap 允許多個(gè)讀者并發(fā)執(zhí)行，讀者與寫(xiě)入者并發(fā)執(zhí)行，以及一些寫(xiě)入者并發(fā)執(zhí)行。因此，如果許多線程頻繁訪問(wèn)共享映射，使用 
ConcurrentHashMap 的總的吞吐量要比使用 Hashtable 的好。 
下表大致說(shuō)明了 Hashtable 和 ConcurrentHashMap 之間的可伸縮性差別。在每次運(yùn)行時(shí)，N 個(gè)線程并發(fā)執(zhí)行緊密循環(huán)，它們從 Hashtable 或 
ConcurrentHashMap 中檢索隨即關(guān)鍵字，60% 的失敗檢索將執(zhí)行 put() 操作，2% 的成功檢索執(zhí)行 remove() 操作。測(cè)試在運(yùn)行 Linux 的雙處理器 
Xeon 系統(tǒng)中執(zhí)行。數(shù)據(jù)顯示 10,000,000 個(gè)迭代的運(yùn)行時(shí)間，對(duì)于 ConcurrentHashMap，標(biāo)準(zhǔn)化為一個(gè)線程的情況。可以看到直到許多線程，
ConcurrentHashMap 的性能仍保持可伸縮性，而 Hashtable 的性能在出現(xiàn)鎖定競(jìng)爭(zhēng)時(shí)幾乎立即下降。 
與通常的服務(wù)器應(yīng)用程序相比，這個(gè)測(cè)試中的線程數(shù)看起來(lái)很少。然而，因?yàn)槊總€(gè)線程未進(jìn)行其他操作，僅是重復(fù)地選擇使用該表，所以這樣可以模擬在執(zhí)行
一些實(shí)際工作的情況下使用該表的大量線程的競(jìng)爭(zhēng)。 

Lock 與 synchronized 與原子
 
下列基準(zhǔn)說(shuō)明了使用 java.util.concurrent 可能改進(jìn)可伸縮性的例子。該基準(zhǔn)將模擬旋轉(zhuǎn)骰子，使用線性同余隨機(jī)數(shù)生成器。有三個(gè)可用的隨機(jī)數(shù)生成器的實(shí)現(xiàn)：一個(gè)使用同步來(lái)管理生成器的狀態(tài)（單一變量），一個(gè)使用 ReentrantLock，另一個(gè)則使用 AtomicLong。下圖顯示了在 8-way Ultrasparc3 系統(tǒng)上，逐漸增加線程數(shù)量時(shí)這三個(gè)版本的相對(duì)吞吐量。（該圖對(duì)原子變量方法的可伸縮性描述比較保守。） 
圖 1. 使用同步、Lock 和 AtomicLong 的相對(duì)吞吐量 

 公平與不公平
 
java.util.concurrent 中許多類(lèi)中的另外一個(gè)定制元素是"公平"的問(wèn)題。公平鎖定或公平信號(hào)是指在其中根據(jù)先進(jìn)先出（FIFO）的原則給與線程鎖定或信號(hào)。ReentrantLock、Semaphore 和 ReentrantReadWriteLock 的構(gòu)造函數(shù)都可以使用變量確定鎖定是否公平，或者是否允許闖入（線程獲得鎖定，即使它們等待的時(shí)間不是最長(zhǎng)）。 
雖然闖入鎖定的想法可能有些可笑，但實(shí)際上不公平、闖入的鎖定非常普遍，且通常很受歡迎。使用同步訪問(wèn)的內(nèi)置鎖定不是公平鎖定（且沒(méi)有辦法使它們公平）。相反，它們提供較弱的生病保證，要求所有線程最終都將獲得鎖定。 
大多數(shù)應(yīng)用程序選擇（且應(yīng)該選擇）闖入鎖定而不是公平鎖定的原因是性能。在大多數(shù)情況下，完全的公平不是程序正確性的要求，真正公平的成本相當(dāng)高。下表向前面的面板中的表中添加了第四個(gè)數(shù)據(jù)集，并由一個(gè)公平鎖定管理對(duì) PRNG 狀態(tài)的訪問(wèn)。注意闖入鎖定與公平鎖定之間吞吐量的巨大差別。 
圖 2. 使用同步、Lock、公平鎖定和 AtomicLong 的相對(duì)吞吐量 

 
 結(jié)束語(yǔ)
 
java.util.concurrent 包中包含大量有用的構(gòu)建快，可以用它們來(lái)改進(jìn)并發(fā)類(lèi)的性能、可伸縮性、線程安全和可維護(hù)性。
通過(guò)這些構(gòu)建快，應(yīng)該可以不再需要在您的代碼中大量使用同步、wait/notify 和 Thread.start()，而用更高級(jí)別、標(biāo)準(zhǔn)化的、
高性能并發(fā)實(shí)用程序來(lái)替換它們。