鎖:
- 內置鎖 (監視器鎖): 每個java對象都可以做一個實現同步的鎖,這些鎖被成為內置鎖. 獲得鎖的唯一途徑就是進入有這個鎖保護的代碼塊或方法
- 重入鎖: 由于內置鎖是可重入的,因此如果某個線程試圖獲得一個以已經由他自己持有的鎖, 那么這個請求就會成功.重入意味著獲取鎖的操作粒度是"線程",而不是"調用"
volatile 使用條件(必須同時滿足所有條件):
- 對變量的寫入操作不依賴變量的當前值,或者你能確保只有單個線程更新變量的值
- 該變量不會與其他狀態變量一起納入不變性條件中
- 在訪問變量時間不需要加鎖
高并發術語
|
術語 |
英文單詞 |
描述 |
|
比較并交換 |
Compare and Swap |
CAS操作需要輸入兩個數值，一個舊值（期望操作前的值）和一個新值，在操作期間先比較下舊值有沒有發生變化，如果沒有發生變化，才交換成新值，發生了變化則不交換。 |
|
CPU流水線 |
CPU pipeline |
CPU流水線的工作方式就象工業生產上的裝配流水線，在CPU中由5~6個不同功能的電路單元組成一條指令處理流水線，然后將一條X86指令分成5~6步后再由這些電路單元分別執行，這樣就能實現在一個CPU時鐘周期完成一條指令，因此提高CPU的運算速度。 |
|
內存順序沖突 |
Memory order violation |
內存順序沖突一般是由假共享引起，假共享是指多個CPU同時修改同一個緩存行的不同部分而引起其中一個CPU的操作無效，當出現這個內存順序沖突時，CPU必須清空流水線。 |
|
共享變量 |
|
在多個線程之間能夠被共享的變量被稱為共享變量。共享變量包括所有的實例變量，靜態變量和數組元素。他們都被存放在堆內存中，Volatile只作用于共享變量。 |
|
內存屏障 |
Memory Barriers |
是一組處理器指令，用于實現對內存操作的順序限制。 |
|
緩沖行 |
Cache line |
緩存中可以分配的最小存儲單位。處理器填寫緩存線時會加載整個緩存線，需要使用多個主內存讀周期。 |
|
原子操作 |
Atomic operations |
不可中斷的一個或一系列操作。 |
|
緩存行填充 |
cache line fill |
當處理器識別到從內存中讀取操作數是可緩存的，處理器讀取整個緩存行到適當的緩存（L1，L2，L3的或所有） |
|
緩存命中 |
cache hit |
如果進行高速緩存行填充操作的內存位置仍然是下次處理器訪問的地址時，處理器從緩存中讀取操作數，而不是從內存。 |
|
寫命中 |
write hit |
當處理器將操作數寫回到一個內存緩存的區域時，它首先會檢查這個緩存的內存地址是否在緩存行中，如果存在一個有效的緩存行，則處理器將這個操作數寫回到緩存，而不是寫回到內存，這個操作被稱為寫命中。 |
synchronized
volatile
concurrent
在并發編程中很常用的實用工具類。此包包括了幾個小的、已標準化的可擴展框架，以及一些提供有用功能的類，沒有這些類，這些功能會很難實現或實現起來冗長乏味。下面簡要描述主要的組件。另請參閱 locks 和 atomic 包。
執行程序
接口。Executor 是一個簡單的標準化接口，用于定義類似于線程的自定義子系統，包括線程池、異步 IO 和輕量級任務框架。根據所使用的具體 Executor 類的不同，可能在新創建的線程中，現有的任務執行線程中，或者調用 execute() 的線程中執行任務，并且可能順序或并發執行。ExecutorService 提供了多個完整的異步任務執行框架。ExecutorService 管理任務的排隊和安排，并允許受控制的關閉。ScheduledExecutorService 子接口及相關的接口添加了對延遲的和定期任務執行的支持。ExecutorService 提供了安排異步執行的方法，可執行由 Callable 表示的任何函數，結果類似于 Runnable。Future 返回函數的結果，允許確定執行是否完成，并提供取消執行的方法。RunnableFuture 是擁有 run 方法的 Future，run 方法執行時將設置其結果。
實現。類 ThreadPoolExecutor 和 ScheduledThreadPoolExecutor 提供可調的、靈活的線程池。Executors 類提供大多數 Executor 的常見類型和配置的工廠方法，以及使用它們的幾種實用工具方法。其他基于 Executor 的實用工具包括具體類 FutureTask，它提供 Future 的常見可擴展實現，以及 ExecutorCompletionService，它有助于協調對異步任務組的處理。
隊列
java.util.concurrent ConcurrentLinkedQueue 類提供了高效的、可伸縮的、線程安全的非阻塞 FIFO 隊列。java.util.concurrent 中的五個實現都支持擴展的 BlockingQueue 接口，該接口定義了 put 和 take 的阻塞版本：LinkedBlockingQueue、ArrayBlockingQueue、SynchronousQueue、PriorityBlockingQueue 和 DelayQueue。這些不同的類覆蓋了生產者-使用者、消息傳遞、并行任務執行和相關并發設計的大多數常見使用的上下文。BlockingDeque 接口擴展 BlockingQueue，以支持 FIFO 和 LIFO（基于堆棧）操作。LinkedBlockingDeque 類提供一個實現。
計時
TimeUnit 類為指定和控制基于超時的操作提供了多重粒度（包括納秒級）。該包中的大多數類除了包含不確定的等待之外，還包含基于超時的操作。在使用超時的所有情況中，超時指定了在表明已超時前該方法應該等待的最少時間。在超時發生后，實現會“盡力”檢測超時。但是，在檢測超時與超時之后再次實際執行線程之間可能要經過不確定的時間。接受超時期參數的所有方法將小于等于 0 的值視為根本不會等待。要“永遠”等待，可以使用 Long.MAX_VALUE 值。
同步器
四個類可協助實現常見的專用同步語句。Semaphore 是一個經典的并發工具。CountDownLatch 是一個極其簡單但又極其常用的實用工具，用于在保持給定數目的信號、事件或條件前阻塞執行。CyclicBarrier 是一個可重置的多路同步點，在某些并行編程風格中很有用。Exchanger 允許兩個線程在 collection 點交換對象，它在多流水線設計中是有用的。
并發 Collection
除隊列外，此包還提供了設計用于多線程上下文中的 Collection 實現：ConcurrentHashMap、ConcurrentSkipListMap、ConcurrentSkipListSet、CopyOnWriteArrayList 和 CopyOnWriteArraySet。當期望許多線程訪問一個給定 collection 時，ConcurrentHashMap 通常優于同步的 HashMap，ConcurrentSkipListMap 通常優于同步的 TreeMap。當期望的讀數和遍歷遠遠大于列表的更新數時，CopyOnWriteArrayList 優于同步的 ArrayList。
此包中與某些類一起使用的“Concurrent&rdquo前綴;是一種簡寫，表明與類似的“同步”類有所不同。例如，java.util.Hashtable 和Collections.synchronizedMap(new HashMap()) 是同步的，但 ConcurrentHashMap 則是“并發的”。并發 collection 是線程安全的，但是不受單個排他鎖的管理。在 ConcurrentHashMap 這一特定情況下，它可以安全地允許進行任意數目的并發讀取，以及數目可調的并發寫入。需要通過單個鎖不允許對 collection 的所有訪問時，“同步”類是很有用的，其代價是較差的可伸縮性。在期望多個線程訪問公共 collection 的其他情況中，通常“并發”版本要更好一些。當 collection 是未共享的，或者僅保持其他鎖時 collection 是可訪問的情況下，非同步 collection 則要更好一些。
大多數并發 Collection 實現（包括大多數 Queue）與常規的 java.util 約定也不同，因為它們的迭代器提供了弱一致的，而不是快速失敗的遍歷。弱一致的迭代器是線程安全的，但是在迭代時沒有必要凍結 collection，所以它不一定反映自迭代器創建以來的所有更新。
Java Language Specification 第 17 章定義了內存操作（如共享變量的讀寫）的 happen-before 關系。只有寫入操作 happen-before 讀取操作時，才保證一個線程寫入的結果對另一個線程的讀取是可視的。synchronized 和 volatile 構造 happen-before 關系，Thread.start() 和Thread.join() 方法形成 happen-before 關系。尤其是：
- 線程中的每個操作 happen-before 稍后按程序順序傳入的該線程中的每個操作。
- 一個解除鎖監視器的（
synchronized 阻塞或方法退出）happen-before 相同監視器的每個后續鎖（synchronized 阻塞或方法進入）。并且因為 happen-before 關系是可傳遞的，所以解除鎖定之前的線程的所有操作 happen-before 鎖定該監視器的任何線程后續的所有操作。 - 寫入
volatile 字段 happen-before 每個后續讀取相同字段。volatile 字段的讀取和寫入與進入和退出監視器具有相似的內存一致性效果，但不 需要互斥鎖。 - 在線程上調用
start happen-before 已啟動的線程中的任何線程。 - 線程中的所有操作 happen-before 從該線程上的
join 成功返回的任何其他線程。
java.util.concurrent 中所有類的方法及其子包擴展了這些對更高級別同步的保證。尤其是：
- 線程中將一個對象放入任何并發 collection 之前的操作 happen-before 從另一線程中的 collection 訪問或移除該元素的后續操作。
- 線程中向
Executor 提交 Runnable 之前的操作 happen-before 其執行開始。同樣適用于向 ExecutorService 提交 Callables。 - 異步計算（由
Future 表示）所采取的操作 happen-before 通過另一線程中 Future.get() 獲取結果后續的操作。 - “釋放”同步儲存方法（如
Lock.unlock、Semaphore.release 和 CountDownLatch.countDown）之前的操作 happen-before 另一線程中相同同步儲存對象成功“獲取”方法（如 Lock.lock、Semaphore.acquire、Condition.await 和 CountDownLatch.await）的后續操作。 - 對于通過
Exchanger 成功交換對象的每個線程對，每個線程中 exchange() 之前的操作 happen-before 另一線程中對應 exchange() 后續的操作。 - 調用
CyclicBarrier.await 之前的操作 happen-before 屏障操作所執行的操作，屏障操作所執行的操作 happen-before 從另一線程中對應await 成功返回的后續操作。
Condition
Condition 將 Object 監視器方法（wait、notify 和 notifyAll）分解成截然不同的對象，以便通過將這些對象與任意 Lock 實現組合使用，為每個對象提供多個等待 set（wait-set）。其中，Lock 替代了 synchronized 方法和語句的使用，Condition 替代了 Object 監視器方法的使用。
條件（也稱為條件隊列 或條件變量）為線程提供了一個含義，以便在某個狀態條件現在可能為 true 的另一個線程通知它之前，一直掛起該線程（即讓其“等待”）。因為訪問此共享狀態信息發生在不同的線程中，所以它必須受保護，因此要將某種形式的鎖與該條件相關聯。等待提供一個條件的主要屬性是：以原子方式 釋放相關的鎖，并掛起當前線程，就像 Object.wait 做的那樣。
Condition 實例實質上被綁定到一個鎖上。要為特定 Lock 實例獲得 Condition 實例，請使用其 newCondition() 方法。
作為一個示例，假定有一個綁定的緩沖區，它支持 put 和 take 方法。如果試圖在空的緩沖區上執行 take 操作，則在某一個項變得可用之前，線程將一直阻塞；如果試圖在滿的緩沖區上執行 put 操作，則在有空間變得可用之前，線程將一直阻塞。我們喜歡在單獨的等待 set 中保存 put 線程和 take 線程，這樣就可以在緩沖區中的項或空間變得可用時利用最佳規劃，一次只通知一個線程。可以使用兩個 Condition 實例來做到這一點。
class BoundedBuffer {
final Lock lock = new ReentrantLock();
final Condition notFull = lock.newCondition();
final Condition notEmpty = lock.newCondition();
final Object[] items = new Object[100];
int putptr, takeptr, count;
public void put(Object x) throws InterruptedException {
lock.lock();
try {
while (count == items.length)
notFull.await();
items[putptr] = x;
if (++putptr == items.length) putptr = 0;
++count;
notEmpty.signal();
} finally {
lock.unlock();
}
}
public Object take() throws InterruptedException {
lock.lock();
try {
while (count == 0)
notEmpty.await();
Object x = items[takeptr];
if (++takeptr == items.length) takeptr = 0;
--count;
notFull.signal();
return x;
} finally {
lock.unlock();
}
}
}
（ArrayBlockingQueue 類提供了這項功能，因此沒有理由去實現這個示例類。）
Condition 實現可以提供不同于 Object 監視器方法的行為和語義，比如受保證的通知排序，或者在執行通知時不需要保持一個鎖。如果某個實現提供了這樣特殊的語義，則該實現必須記錄這些語義。
注意，Condition 實例只是一些普通的對象，它們自身可以用作 synchronized 語句中的目標，并且可以調用自己的 wait 和notification 監視器方法。獲取 Condition 實例的監視器鎖或者使用其監視器方法，與獲取和該 Condition 相關的 Lock 或使用其 waiting 和 signalling 方法沒有什么特定的關系。為了避免混淆，建議除了在其自身的實現中之外，切勿以這種方式使用Condition 實例。
除非另行說明，否則為任何參數傳遞 null 值將導致拋出 NullPointerException。
實現注意事項
在等待 Condition 時，允許發生“虛假喚醒”，這通常作為對基礎平臺語義的讓步。對于大多數應用程序，這帶來的實際影響很小，因為 Condition 應該總是在一個循環中被等待，并測試正被等待的狀態聲明。某個實現可以隨意移除可能的虛假喚醒，但建議應用程序程序員總是假定這些虛假喚醒可能發生，因此總是在一個循環中等待。
三種形式的條件等待（可中斷、不可中斷和超時）在一些平臺上的實現以及它們的性能特征可能會有所不同。尤其是它可能很難提供這些特性和維護特定語義，比如排序保證。更進一步地說，中斷線程實際掛起的能力在所有平臺上并不是總是可行的。
因此，并不要求某個實現為所有三種形式的等待定義完全相同的保證或語義，也不要求其支持中斷線程的實際掛起。
要求實現清楚地記錄每個等待方法提供的語義和保證，在某個實現不支持中斷線程的掛起時，它必須遵從此接口中定義的中斷語義。
由于中斷通常意味著取消，而又通常很少進行中斷檢查，因此實現可以先于普通方法的返回來對中斷進行響應。即使出現在另一個操作后的中斷可能會釋放線程鎖時也是如此。實現應記錄此行為。