無為

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


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



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



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



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



  

大多數服務器應用程序（如 Web 服務器、POP 服務器、數據庫服務器或文件服務器）代表遠程客戶機處理請求，這些客戶機通常使用 socket 連接到服務器。對于每個請求，通常要進行少量處理（獲得該文件的代碼塊，并將其發送回 socket），但是可能會有大量（且不受限制）的客戶機請求服務。 
用于構建服務器應用程序的簡單化模型會為每個請求創建新的線程。下列代碼段實現簡單的 Web 服務器，它接受端口 80 的 socket 連接，并創建新的線程來處理請求。不幸的是，該代碼不是實現 Web 服務器的好方法，因為在重負載條件下它將失敗，停止整臺服務器。 

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();
    }
  }
}

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

 使用線程池解決問題

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


有穩定性）問題。 


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

  new Thread(runnable).start()

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

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

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

任務運行于哪個線程不是由該接口指定的，這取決于使用的 Executor 的實現。它可以運行于后臺線程，如 Swing 事件線程，或者運行于線程池，或者調用線程，或者
新的線程，它甚至可以運行于其他 JVM！通過同步的 Executor 接口提交任務，從任務執行策略中刪除任務提交。Executor 接口獨自關注任務提交 -- 這是 
Executor 實現的選擇，確定執行策略。這使在部署時調整執行策略（隊列限制、池大小、優先級排列等等）更加容易，更改的代碼最少。 
java.util.concurrent 中的大多數 Executor 實現還實現 ExecutorService 接口，這是對 Executor 的擴展，它還管理執行服務的生命周期。這使它們更易
于
管理，并向生命可能比單獨 Executor 的生命更長的應用程序提供服務。 

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 實現，每個實現都實現不同的執行策略。什么是執行策略？執行策略定義何時在哪個線程中運行任務，

執行任務可能消耗的資源級別（線程、內存等等），以及如果執行程序超載該怎么辦。 

執行程序通常通過工廠方法例示，而不是通過構造函數。Executors 類包含用于構造許多不同類型的 Executor 實現的靜態工廠方法：

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

更可靠的 Web 服務器 -- 使用 Executor

前面 如何不對任務進行管理 中的代碼顯示了如何不用編寫可靠服務器應用程序。幸運的是，修復這個示例非常簡單，只需將 Thread.start() 調用替換

為向 Executor 提交任務即可：

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);
    }
  }
}

注意，本例與前例之間的區別僅在于 Executor 的創建以及如何提交執行的任務。 

定制 ThreadPoolExecutor

 
 
Executors 中的 newFixedThreadPool 和 newCachedThreadPool 工廠方法返回的 Executor 是類 ThreadPoolExecutor 的實例，是高度可定制的。 
通過使用包含 ThreadFactory 變量的工廠方法或構造函數的版本，可以定義池線程的創建。ThreadFactory 是工廠對象，其構造執行程序要使用的新線程。
使用定制的線程工廠，創建的線程可以包含有用的線程名稱，并且這些線程是守護線程，屬于特定線程組或具有特定優先級。 
下面是線程工廠的例子，它創建守護線程，而不是創建用戶線程： 

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

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

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

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 中其他類別的有用的類也是同步工具。這組類相互協作，控制一個或多個線程的執行流。 
Semaphore、CyclicBarrier、CountdownLatch 和 Exchanger 類都是同步工具的例子。每個類都有線程可以調用的方法，
方法是否被阻塞取決于正在使用的特定同步工具的狀態和規則。 

Semaphore

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

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

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

Exchanger 通常用于一個線程填充緩沖（通過讀取 socket），而另一個線程清空緩沖（通過處理從 socket 收到的命令）的情況。當兩個線程在屏障處集合時，它們交換緩沖。下列代碼說明了這項技術： 

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 語言內置了鎖定工具 -- synchronized 關鍵字。當線程獲得監視器時（內置鎖定），其他線程如果試圖獲得相同鎖定，那么它們將被阻塞，直到第一個線程釋放該鎖定。同步還確保隨后獲得相同鎖定的線程可以看到之前的線程在具有該鎖定時所修改的變量的值，從而確保如果類正確地同步了共享狀態的訪問權，那么線程將不會看到變量的"失效"值，這是緩存或編譯器優化的結果。 

雖然同步沒有什么問題，但它有一些限制，在一些高級應用程序中會造成不便。Lock 接口將內置監視器鎖定的鎖定行為普遍化，允許多個鎖定實現，同時提供一些內置鎖定缺少的功能，如計時的等待、可中斷的等待、鎖定輪詢、每個鎖定有多個條件等待集合以及無阻塞結構的鎖定。 

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 是具有與隱式監視器鎖定（使用 synchronized 方法和語句訪問）相同的基本行為和語義的 Lock 的實現，但它具有擴展的能力。 

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

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

JVM 將花費較少的時間來調度線程，而用更多個時間執行線程。 

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

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

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

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

Condition

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

ReadWriteLock

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

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

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

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