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