無為

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


因為多個原因，類似 Swing GUI 的框架為事件任務(wù)創(chuàng)建單一線程，而不是為每項任務(wù)創(chuàng)建新的線程。首先是因為創(chuàng)建線程會有間接成本，所以創(chuàng)建線程來執(zhí)行



簡單任務(wù)將是一種資源浪費。通過重新使用事件線程來處理多個事件，啟動和拆卸成本（隨平臺而變）會分攤在多個事件上。 



Swing 為事件使用單一后臺線程的另一個原因是確保事件不會互相干涉，因為直到前一事件結(jié)束，下一事件才開始處理。該方法簡化了事件處理程序的編寫。



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



  

大多數(shù)服務(wù)器應(yīng)用程序（如 Web 服務(wù)器、POP 服務(wù)器、數(shù)據(jù)庫服務(wù)器或文件服務(wù)器）代表遠程客戶機處理請求，這些客戶機通常使用 socket 連接到服務(wù)器。對于每個請求，通常要進行少量處理（獲得該文件的代碼塊，并將其發(fā)送回 socket），但是可能會有大量（且不受限制）的客戶機請求服務(wù)。 
用于構(gòu)建服務(wù)器應(yīng)用程序的簡單化模型會為每個請求創(chuàng)建新的線程。下列代碼段實現(xiàn)簡單的 Web 服務(wù)器，它接受端口 80 的 socket 連接，并創(chuàng)建新的線程來處理請求。不幸的是，該代碼不是實現(xiàn) Web 服務(wù)器的好方法，因為在重負載條件下它將失敗，停止整臺服務(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();
    }
  }
}

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

 使用線程池解決問題

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


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


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

  new Thread(runnable).start()

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

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

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

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

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

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

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

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

前面 如何不對任務(wù)進行管理 中的代碼顯示了如何不用編寫可靠服務(wù)器應(yīng)用程序。幸運的是，修復(fù)這個示例非常簡單，只需將 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 是類 ThreadPoolExecutor 的實例，是高度可定制的。 
通過使用包含 ThreadFactory 變量的工廠方法或構(gòu)造函數(shù)的版本，可以定義池線程的創(chuàng)建。ThreadFactory 是工廠對象，其構(gòu)造執(zhí)行程序要使用的新線程。
使用定制的線程工廠，創(chuàng)建的線程可以包含有用的線程名稱，并且這些線程是守護線程，屬于特定線程組或具有特定優(yōu)先級。 
下面是線程工廠的例子，它創(chuàng)建守護線程，而不是創(chuàng)建用戶線程： 

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

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

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

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ù)與類似 Queue 的接口組合，從任務(wù)執(zhí)行中刪除任務(wù)結(jié)果的處理。CompletionService 接口包含用來提交將要執(zhí)行的任務(wù)的 submit() 方法和用來詢問下一完成任務(wù)的 take()/poll() 方法。 
CompletionService 允許應(yīng)用程序結(jié)構(gòu)化，使用 Producer/Consumer 模式，其中生產(chǎn)者創(chuàng)建任務(wù)并提交，消費者請求完成任務(wù)的結(jié)果并處理這些結(jié)果。CompletionService 接口由 ExecutorCompletionService 類實現(xiàn)，該類使用 Executor 處理任務(wù)并從 CompletionService 導出 submit/poll/take 方法。 
下列代碼使用 Executor 和 CompletionService 來啟動許多"solver"任務(wù)，并使用第一個生成非空結(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 中其他類別的有用的類也是同步工具。這組類相互協(xié)作，控制一個或多個線程的執(zhí)行流。 
Semaphore、CyclicBarrier、CountdownLatch 和 Exchanger 類都是同步工具的例子。每個類都有線程可以調(diào)用的方法，
方法是否被阻塞取決于正在使用的特定同步工具的狀態(tài)和規(guī)則。 

Semaphore

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

CyclicBarrier 類可以幫助同步，它允許一組線程等待整個線程組到達公共屏障點。CyclicBarrier 是使用整型變量構(gòu)造的，其確定組中的線程數(shù)。當一個線程到達屏障時（通過調(diào)用 CyclicBarrier.await()），它會被阻塞，直到所有線程都到達屏障，然后在該點允許所有線程繼續(xù)執(zhí)行。該操作與許多家庭逛商業(yè)街相似 -- 每個家庭成員都自己走，并商定 1:00 在電影院集合。當您到電影院但不是所有人都到了時，您會坐下來等其他人到達。然后所有人一起離開。 
認為屏障是循環(huán)的是因為它可以重新使用；一旦所有線程都已經(jīng)在屏障處集合并釋放，則可以將該屏障重新初始化到它的初始狀態(tài)。 
還可以指定在屏障處等待時的超時；如果在該時間內(nèi)其余線程還沒有到達屏障，則認為屏障被打破，所有正在等待的線程會收到 BrokenBarrierException。 
下列代碼將創(chuàng)建 CyclicBarrier 并啟動一組線程，每個線程將計算問題的一部分，等待所有其他線程結(jié)束之后，再檢查解決方案是否達成一致。如果不一致，那么每個工作線程將開始另一個迭代。該例將使用 CyclicBarrier 變量，它允許注冊 Runnable，在所有線程到達屏障但還沒有釋放任何線程時執(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 類與 CyclicBarrier 相似，因為它的角色是對已經(jīng)在它們中間分攤了問題的一組線程進行協(xié)調(diào)。它也是使用整型變量構(gòu)造的，指明計數(shù)的初始值，但是與 CyclicBarrier 不同的是，CountdownLatch 不能重新使用。 
其中，CyclicBarrier 是到達屏障的所有線程的大門，只有當所有線程都已經(jīng)到達屏障或屏障被打破時，才允許這些線程通過，CountdownLatch 將到達和等待功能分離。任何線程都可以通過調(diào)用 countDown() 減少當前計數(shù)，這種不會阻塞線程，而只是減少計數(shù)。await() 方法的行為與 CyclicBarrier.await() 稍微有所不同，調(diào)用 await() 任何線程都會被阻塞，直到閂鎖計數(shù)減少為零，在該點等待的所有線程才被釋放，對 await() 的后續(xù)調(diào)用將立即返回。 
當問題已經(jīng)分解為許多部分，每個線程都被分配一部分計算時，CountdownLatch 非常有用。在工作線程結(jié)束時，它們將減少計數(shù)，協(xié)調(diào)線程可以在閂鎖處等待當前這一批計算結(jié)束，然后繼續(xù)移至下一批計算。 
相反地，具有計數(shù) 1 的 CountdownLatch 類可以用作"啟動大門"，來立即啟動一組線程；工作線程可以在閂鎖處等待，協(xié)調(diào)線程減少計數(shù)，從而立即釋放所有工作線程。下例使用兩個 CountdownLatche。一個作為啟動大門，一個在所有工作線程結(jié)束時釋放線程： 

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 類方便了兩個共同操作線程之間的雙向交換；這樣，就像具有計數(shù)為 2 的 CyclicBarrier，并且兩個線程在都到達屏障時可以"交換"一些狀態(tài)。（Exchanger 模式有時也稱為聚集。） 

Exchanger 通常用于一個線程填充緩沖（通過讀取 socket），而另一個線程清空緩沖（通過處理從 socket 收到的命令）的情況。當兩個線程在屏障處集合時，它們交換緩沖。下列代碼說明了這項技術(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 語言內(nèi)置了鎖定工具 -- synchronized 關(guān)鍵字。當線程獲得監(jiān)視器時（內(nèi)置鎖定），其他線程如果試圖獲得相同鎖定，那么它們將被阻塞，直到第一個線程釋放該鎖定。同步還確保隨后獲得相同鎖定的線程可以看到之前的線程在具有該鎖定時所修改的變量的值，從而確保如果類正確地同步了共享狀態(tài)的訪問權(quán)，那么線程將不會看到變量的"失效"值，這是緩存或編譯器優(yōu)化的結(jié)果。 

雖然同步?jīng)]有什么問題，但它有一些限制，在一些高級應(yīng)用程序中會造成不便。Lock 接口將內(nèi)置監(jiān)視器鎖定的鎖定行為普遍化，允許多個鎖定實現(xiàn)，同時提供一些內(nèi)置鎖定缺少的功能，如計時的等待、可中斷的等待、鎖定輪詢、每個鎖定有多個條件等待集合以及無阻塞結(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 方法和語句訪問）相同的基本行為和語義的 Lock 的實現(xiàn)，但它具有擴展的能力。 

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

這意味著當許多線程都競爭相同鎖定時，使用 ReentrantLock 的吞吐量通常要比 synchronized 好。換句話說，當許多線程試圖訪問 ReentrantLock 保護的共享資源時，

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

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

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

因為鎖定失誤（忘記釋放鎖定）的風險，所以對于基本鎖定，強烈建議您繼續(xù)使用 synchronized，除非真的需要 ReentrantLock 額外的靈活性和可伸縮性。

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

Condition

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

ReadWriteLock

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

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

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

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