Java多线程与并发编程终极宝典
閱讀本文需要了解的概念
原語
所謂原語，一般是指由若干條指令組成的程序段，用來實現某個特定功能，在執行過程中不可被中斷。在操作系統中，某些被進程調用的操作，如隊列操作、對信號量的操作、檢查啟動外設操作等，一旦開始執行，就不能被中斷，否則就會出現操作錯誤，造成系統混亂。所以，這些操作都要用原語來實現 原語是操作系統核心（不是由進程，而是由一組程序模塊組成）的一個組成部分，并且常駐內存，通常在管態下執行。原語一旦開始執行，就要連續執行完，不允許中斷。
對操作系統來說，原語就是不可中斷的一堆匯編指令。
對java程序來說，原語就是java native底層接口去調用的東西，java應用層面是不需要關心原語的。
串行
串行表示所有任務都一一按先后順序進行。串行意味著必須先裝完一車柴才能運送這車柴，只有運送到了，才能卸下這車柴，并且只有完成了這整個三個步驟，才能進行下一個步驟。串行是一次只能取得一個任務，并執行這個任務。
并行
并行意味著可以同時取得多個任務，并同時去執行所取得的這些任務。并行模式相當于將長長的一條隊列，劃分成了多條短隊列，所以并行縮短了任務隊列的長度。并行的效率從代碼層次上強依賴于多進程多線程代碼，從硬件角度上則依賴于多核 CPU。
并發
并發(concurrent)指的是多個程序可以同時運行的現象，更細化的是多進程可以同時運行或者多指令可以同時運行。但這不是重點，在描述并發的時候也不會去扣這種字眼是否精確，并發的重點在于它是一種現象, 并發描述的是多進程同時運行的現象。但實際上，對于單核心 CPU 來說，同一時刻能運行一個線程。所以，這里的"同時運行"表示的不是真的同一時刻有多個線程運行的現象，這是并行的概念，而是提供一種功能讓用戶看來多個程序同時運行起來了，但實際上這些程序中的進程不是一直霸占 CPU 的，而是執行一會停一會。要解決大并發問題，通常是將大任務分解成多個小任務, 由于操作系統對進程的調度是隨機的，所以切分成多個小任務后，可能會從任一小任務處執行。這可能會出現一些現象：
? 可能出現一個小任務執行了多次，還沒開始下個任務的情況。這時一般會采用隊列或類似的數據結構來存放各個小任務的成果
? 可能出現還沒準備好第一步就執行第二步的可能。這時，一般采用多路復用或異步的方式，比如只有準備好產生了事件通知才執行某個任務。
? 可以多進程/多線程的方式并行執行這些小任務。也可以單進程/單線程執行這些小任務，這時很可能要配合多路復用才能達到較高的效率
管程
管程(monitor)是保證了同一時刻只有一個進程在管程內活動,即管程內定義的操作在同一時刻只被一個進程調用(由編譯器實現).但是這樣并不能保證進程以設計的順序執行。
JVM 中同步是基于進入和退出管程(monitor)對象實現的，每個對象都會有一個管程(monitor)對象，管程(monitor)會隨著 java 對象一同創建和銷毀。執行線程首先要持有管程對象，然后才能執行方法，當方法完成之后會釋放管程，方法在執行時候會持有管程，其他線程無法再獲取同一個管程。
線程概念
進程與線程
進程（Process）是操作系統中程序運行和資源分配的基本單位，是操作系統結構的基礎。 程序是指令、數據及其組織形式的描述，進程是程序的實體。在當代面向線程設計的計算機結構中，進程是線程的容器。
線程（Thread）是操作系統能夠進行運算調度的最小單位。它被包含在進程之中，是進程中的實際運作單元。一個進程中可以并發多個線程，每條線程并行執行不同的任務，一個進程至少有一個線程，多個線程共享進程的內存資源。
JVM在HotSpot的線程模型下，Java線程會一對一映射為內核線程。這意味著，在Java中每次創建以及回收線程都會去內核創建以及回收。這就有可能導致：創建和銷毀線程所花費的時間和資源可能比處理的任務花費的時間和資源要更多。
守護線程
守護線程（daemon thread），是運行在后臺服務于其他線程的線程，周期性地執行某種任務或等待處理某些發生的事件。
java程序啟動后，至少有兩個線程，一個main線程，一個GC的守護線程。
JMM（Java Memory Model）
JMM是JVM規范的一部分，JVM規范包括了JMM。
java內存模型是定義了線程和主內存之間的抽象關系，即 JMM 定義了 JVM 在計算機內存(RAM)中的工作方式，以及各個線程對各種變量的訪問規則，即在虛擬機中將變量（線程共享的變量）存儲到內存和從內存中取出變量這樣底層細節。
每個線程創建時jvm會分配一個線程私有的工作內存（?？臻g）。
所有共享變量都存儲在主內存（堆空間+和方法區）。
線程操作共享變量過程是，復制一份到私有空間，在私有空間改完之后再寫入主內存，不能直接操作主內存，并且線程私有空間對其他線程不可見。
JMM關于線程同步的規定
1.線程解鎖前，必須把共享變量（非線程局部變量）寫入主內存。
2.線程加鎖前，必須讀取主內存的最新值到自己的工作內存。
3.加鎖解鎖是同一把鎖。
線程安全三要素
原子性
原子性是指一個操作不可被中斷，要么全部執行成功要么全部執行失敗。和關系型數據庫事務的原子性概念相同。
Java原子操作是指符合原子性的操作，不會被線程調度機制打斷的操作，這種操作一旦開始，就一直運行到結束，中間不會有任何 context switch (切換到另一個線程)。
jvm原子操作指令
jvm中讀寫相關的原子操作指令：
lock :它把一個變量標識為一個線程獨占的狀態
unlock:它釋放一個處理線程獨占狀態的變量，使釋放后的變量能被其它線程鎖定
read:它把一個變量的值從主內存中傳輸到線程的工作內存中，以便后面的load使用
load:將read命令傳輸的變量值放入工作內存中的變量副本
use:它把工作內存中一個變量的值傳遞給執行引擎，每當虛擬機遇到一個需要使用到變量的值的字節碼指令時將會執行這個操作
assign:它把一個從執行引擎接收到的值賦給工作內存的變量，每當虛擬機遇到一個給變量賦值的字節碼指令時執行這個操作
store:它把工作內存中一個變量的值傳送給主內存中以便隨后的write操作使用
write:它把store操作從工作內存中得到的變量的值放入主內存的變量中
jvm中讀寫相關的非原子操作指令：
iinc:自增或自減
java原子操作代碼
- java中，對基本數據類型的常量賦值操作都是原子性操作。
int a = 1; //原子
int b = 2; //原子
int c = a; //非原子 （讀a的值>賦值給c）
a++; //非原子 （讀a的值>值+1>賦值給a）
b = b + 1; //非原子 （讀b的值>值+1>賦值給b）
不過有個特例：
在32位的操作系統中，long和double不是原子操作，因為32位jdk在給64位的long變量賦值時，是兩次操作，先給32位賦值，然后給剩下的32位賦值，當多個線程出現競爭的時候，會出現A線程賦值了一半（32位），B線程給另一半（32位）賦值了。
long a = 1L; //32位系統中非原子，64位系統中原子
double b = 1.0; //32位系統中非原子，64位系統中原子
- java中，所有引用的賦值操作都是原子操作（只是給引用賦值是原子操作，也就是
Object obj1=是原子操作，new不是原子操作，但new是線程安全的）：
Object obj1=new Object();//'='原子，'new'非原子
Object obj2=obj1;//原子
- java中，所有
java.util.concurrent.atomic包下的類都是原子操作
java提供java.util.concurrent.atomic包來支持將非原子操作轉變成原子操作。
可見性
一個線程對主內存的修改可以及時的被其他線程觀察到。
JMM中每一個線程都有自己的獨立工作內存區，還有一個公共內存區(主內存)。線程執行時先把變量值從主內存拷貝到自己工作內存區中?？梢娦缘哪康木褪潜ＷC一個線程改變了變量后，其他線程及時刷新自己的工作區內存獲取最新值。
java中我們可以使用volatile、synchronized、Lock提供可見性的。當一個變量被volatile修飾時，對它的修改會立刻刷新到主存，并將其他線程緩存中的此變量清空，當其它線程需要讀取該變量時，會去主內存中讀取新值。而普通變量則不能保證每次都去主內存讀取到最新值，會有延遲。
synchronized和Lock也能夠保證可見性，線程在釋放鎖之前，會把變量值都刷回主存，且在持鎖后首先從主內存同步所有工作內存變量，但是synchronized和Lock的開銷都比volatile大。
有序性
被執行的代碼必須按編碼時的順序邏輯去執行，避免指令重排。
java中我們可以通過lock/unlock, volatile等關鍵字防止指令重排序。
JMM是允許編譯器和處理器對指令重排序的，但是規定了as-if-serial語義，即不管怎么重排序，程序的執行結果不能改變。比如下面的程序段：
int a = 1; //編譯器在編譯.java源文件為.class文件時，無法保證int a = 1在第一行，因為編譯器會優化重排代碼順序。
int b = 2; //編譯器在編譯.java源文件為.class文件時，無法保證int b = 2在第二行，因為編譯器會優化重排代碼順序。
int c = a + b; //編譯器不管怎么優化，int c = a + b一定是第三行，JMM保證了重排序不會影響到單線程的執行結果，所以c無法參與重排，必須排在a、b后面。
但是多線程環境中線程交替執行，即使只是將a和b進行重排，兩個線程中使用的變量能否保證一致性是無法確定的，結果無法預測，進而造成線程安全問題。
指令重排
計算機在執行程序時，為了提高性能，編譯器和處理器常常會對指令做重排，一般分以下3種
源代碼=>編譯器優化的重排=>指令并行的重排=>內存系統的重排=>最終執行的指令
volatile實現禁止指令重排優化，從而避免多線程環境下程序出現亂序執行的現象。
先了解一個概念，內存屏障( Memory Barrier)又稱內存柵欄，是一個CPU指令，它的作用有兩個：
一是保證特定操作的執行順序，
二是保證某些變量的內存可見性（利用該特性實現 volatile的內存可見性）。
由于編譯器和處理器都能執行指令重排優化。如果在指令間插入一條Memory Barrier則會告訴編譯器和CPU,不管什么指令都不能
和這條Memory Barrier指令重排序，也就是說通過插入內存屏障禁止在內存屏障前后的指令執行重排序優化。內存屏障另外一個作
用是強制刷出各種CPU的緩存數據，因此任何CPU上的線程都能讀取到這些數據的最新版本。
對 Volatile變量進行寫操作時，會在寫操作后加入一條store屏障指令，將工作內存中的共享變量值刷新回到主內存。
對 Volatile變量進行讀操作時，會在讀操作前加入一條load屏障指令，從主內存中讀取共享變量。
New操作的線程安全問題的思考
new操作符不可能有兩個線程能同時進入，多個線程進入會new出不同的對象，但構造方法里面的代碼是不能保證線程安全的，例如在構造函數中將this交給別的線程，那么就會出現線程安全問題。
只要不在構造函數或構造代碼塊將this交出去，那么在new操作符完成之前，別的線程無論如何也是無法獲取這個新對象的，必須等到new操作符操作結束，別的對象才能獲得該對象。
總之，多個線程不可能new出同一個對象，既然不是同一個對象，就不存在線程安全問題。
線程狀態
看這里：Java之線程狀態
創建線程的方式
1 繼承Thread類重寫run方法。
2 實現Runnable接口實現run方法，并將Runnable接口實現類的實例作為Thread的構造參數。
3 實現Callable接口實現run方法，并將Callable接口實現實現類的實例作為和FutureTask的構造參數創建FutureTask對象，然后將FutureTask對象作為Thread的構造參數。這種方式可以通過FutureTask.get獲取執行的返回值，獲取返回值時會阻塞。
Callable<String> call = new Callable<String>() {@Overridepublic String call() throws Exception {System.out.println("Running...");return "done";}};FutureTask<String> futureTask=new FutureTask<String>(call);Thread thread = new Thread(futureTask);thread.start();//futureTask.get():獲取任務執行結果，如果任務還沒完成則會阻塞等待直到任務執行完成。如果任務被取消則會拋出CancellationException異常，//如果任務執行過程發生異常則會拋出ExecutionException異常，如果阻塞等待過程中被中斷則會拋出InterruptedException異常。boolean result = (boolean) futureTask.get();String result = futureTask.get();System.out.println(result);
4 使用線程池。
為什么要用多線程
使用多線程最主要的原因是提高CPU利用率，更快的完成任務。
鎖概念
公平鎖
排好隊，不允許插隊。
在并發環境中，每個線程在獲取鎖時會先查看此鎖維護的等待隊列，如果為空，或者當前線程是等待隊列的第一
個，就占有鎖，否則就會加入到等待隊列中，隊列按照FIFO(先進先出)的規則依次發放鎖給線程。
new ReentrantLock(true)就是一個公平鎖
公平鎖性能會比非公平鎖低。
非公平鎖
排隊，但也允許插隊，誰的權重高誰先拿到鎖。
在并發環境中，每個線程在獲取鎖時會先查看此鎖維護的等待隊列，如果為空，或者當前線程是等待隊列的第一
個，就占有鎖，否則就會加入到等待隊列中，加入隊列時，權重高的排在最前面，如果排在后面的主動提升了權重（氪金了），則也可以重新排到前面去。
synchronized和new ReentrantLock(默認就是非公平鎖)和new ReentrantLock(false)都是非公平鎖
非公平鎖可能會導致饑餓問題和權重反轉。
饑餓問題
一直有權重高的在插隊，權重低的一直得不到執行。
自旋鎖
自旋鎖(spinlock)，自旋其實就是死循環、遞歸的意思。是指嘗試獲取鎖的線程不會立即阻塞，而是采用循環的方式去嘗試獲取鎖，這樣的好處是減少線程上下文切換的消耗，缺點是循環會消耗CPU。
java.util.concurrent.atomic包下的原子類很多都是使用的自旋鎖，而不是Lock或synchronized。
讀寫鎖
讀鎖，又稱共享鎖；寫鎖，又稱排他鎖。
將鎖根據情況拆分成讀鎖和寫鎖兩把鎖，就成了讀寫鎖。
讀寫鎖允許多個線程同時讀一個資源，不允許多個線程同時寫一個資源。
讀-讀能共存，讀-寫不能共存，寫寫不能共存。
jdk自帶的讀寫鎖：ReentrantReadWriteLock。
使用場景：
對共享資源有讀和寫的操作，且寫操作沒有讀操作那么頻繁。
在沒有寫操作的時候，多個線程同時讀一個資源沒有任何問題，所以應該允許多個線程同時讀取共享資源。
但是如果一個線程想去寫這些共享資源，就不應該允許其他線程對該資源進行讀和寫的操作了。
可重入鎖
可重入鎖又名遞歸鎖
在一個線程內，當鎖對象是同一個對象時，不用等鎖釋放即可再次獲得鎖，不會因為之前已經獲取過還沒釋放而阻塞。
Java中 ReentrantLock和 synchronized都是可重入鎖，可重入鎖的一個優點是可一定程度避免死鎖。
顯式鎖/隱式鎖
顯式鎖：需要顯式指定鎖對象、調用獲取鎖和釋放鎖的代碼，juc內的Lock相關鎖都是顯示鎖。
隱式鎖：可以不指定鎖對象、不需要顯式調用獲取鎖和釋放鎖的代碼。synchronized就是隱式鎖。
死鎖
死鎖是指兩個或兩個以上的線程互相持有對方所需要的資源，導致這些線程處于互相等待狀態，都無法繼續執行。
死鎖不單單發生于多線程，多進程、軟件系統都可能發生此種情況。
死鎖產生的條件：
1.條件互斥：進程/線程要求對所分配的資源進行排它性控制，即在一段時間內某資源僅為一進程/線程所占用。
2.請求和保持：當進程/線程因請求資源而阻塞時，對已獲得的資源保持不放。
3.不剝奪：進程/線程已獲得的資源在未使用完之前，不能剝奪，只能在使用完時由自己釋放。
4.環路等待：在發生死鎖時，必然存在一個進程/線程——資源的環形鏈。
死鎖一般產生的原因
系統資源不足
程序設計不當
防止死鎖
1、加鎖順序（線程按照一定的順序加鎖）
當多個線程需要相同的一些鎖，但是按照不同的順序加鎖，死鎖就很容易發生。
如果能確保所有的線程都是按照相同的順序獲得鎖，那么死鎖就不會發生。
2、加鎖時限（線程嘗試獲取鎖的時候加上一定的時限，超過時限則放棄對該鎖的請求，并釋放自己占有的鎖）
ReentrantLock類tryLock(long time, TimeUnit unit)方法可以嘗試獲取鎖，如果超過指定時間仍未獲取到鎖，則放棄獲取鎖。
鎖升級
在Java中，鎖共有4種狀態，級別從低到高依次為：無狀態鎖，偏向鎖，輕量級鎖和重量級鎖狀態，這幾個狀態會隨著競爭情況逐漸升級。鎖可以升級但不能降級。
鎖升級的圖示過程：
線程池
線程池的實現原理
線程池使用阻塞隊列，詳情請查看本文后面的阻塞隊列章節。
線程池的作用
- 控制線程數量
控制指定數量的線程運行，多余線程排隊。 - 線程復用
線程是稀缺資源，大量的任務每次都new Thread是對資源的嚴重浪費，線程池可以重復利用已創建的線程，降低線程創建和銷毀造成的資源消耗。 - 方便管理拓展
線程丟到一起可以方便統計和管理。
線程池提供了更多的功能，比如延時定時線程池ScheduledThreadPoolExecutor，就允許任務延期執行或定期執行。
線程池狀態
線程池有5種狀態：Running、ShutDown、Stop、Tidying、Terminated。
線程池各個狀態切換框架圖：
創建線程池的方式
一、自己new ThreadPoolExecutor。
二、使用Executors提供的靜態方法。
2.1. Executors.newFixedThreadPool(int nThreads)
創建一個固定長度的線程池，每當提交一個任務就創建一個線程，直到達到線程池的最大數量，這時線程規模將不再變化，當線程發生未預期的錯誤而結束時，線程池會補充一個新的線程。
2.2. Executors.newCachedThreadPool()
創建一個可自動擴縮容的線程池，如果線程池的規模超過了處理需求，將自動回收空閑線程，而當需求增加時，則可以自動添加新線程，線程池的規模不存在任何限制。
2.3. Executors.newSingleThreadExecutor()
這是一個單線程的Executor，它創建單個工作線程來執行任務，如果這個線程異常結束，會創建一個新的來替代它；它的特點是能確保依照任務在隊列中的順序來串行執行。
2.4. Executors.newScheduledThreadPool(int corePoolSize)
創建了一個固定長度的線程池，而且以延遲或定時的方式來執行任務，類似于Timer。
2.5. Executors.newWorkStealingPool
jdk1.8 提供的線程池，底層使用的是 ForkJoinPool 實現，創建一個擁有多個
任務隊列的線程池，可以減少連接數，創建當前可用 cpu 核數的線程來并行執行任務
public static ExecutorService newWorkStealingPool(int parallelism) {
/**
* parallelism：并行級別，通常默認為 JVM 可用的處理器個數
* factory：用于創建 ForkJoinPool 中使用的線程。
* handler：用于處理工作線程未處理的異常，默認為 null
* asyncMode：用于控制 WorkQueue 的工作模式:隊列---反隊
* ...
}
線程池7大核心參數
看這里：線程池七大參數的含義
線程池工作流程
1.如果核心線程corePoolSize還有空閑線程，那么新任務將交給空閑線程。
2.如果核心線程都滿負荷工作中，那么將添加任務到阻塞隊列workQueue。
3.如果阻塞隊列滿了，那么將使用最大線程數maximumPoolSize來創建更多的線程，以接收新的任務。
4.如果阻塞隊列滿了，最大線程數的全部線程也都在工作中，那么將啟用拒絕策略rejectedExecutionHandler。
5.如果任務執行完了，沒有新的任務提交了，將使用keepAliveTime來銷毀核心數之外的線程。
線程池常用方法
execute
ThreadPoolExecutor.execute在將來的某個時候執行給定的任務。任務可以在新線程中執行，也可以在現有的池線程中執行。如果任務不能提交執行，要么因為該執行器已經關閉，要么因為它的容量已經達到，任務將由當前RejectedExecutionHandler處理。
submit
ThreadPoolExecutor.submit提交一個Runnable任務執行，并返回一個表示該任務的future。成功完成后，Future的get方法將返回null。
shutdown
ThreadPoolExecutor.shutdown啟動一個有序的關閉，之前提交的任務將被執行，但不會接受新的任務。如果已經關閉，調用不會產生額外的效果。
該方法不等待之前提交的任務完成執行。使用awaitTerminationto這樣做。
shutdownNow
嘗試停止所有正在執行的任務，停止等待任務的處理，并返回等待執行的任務列表。從該方法返回時，這些任務將從任務隊列中取出(刪除)。
該方法不等待主動執行的任務終止。使用awaitterminate完成此操作。
除了盡最大努力嘗試停止正在積極執行的任務的處理外，沒有任何保證。這個實現通過Thread.interrupt取消任務，所以任何無法響應中斷的任務都可能永遠不會終止。
schedule
ScheduledExecutorService.schedule在指定延遲時間后調用任務。
schedule(Runnable command,//任務long delay, //從現在開始推遲執行的時間TimeUnit unit//delay的單位
)
線程池的submit和execute的區別
submit里面其實就是調用的execute，只不過execute沒有返回值，submit將run方法的返回值通過Future返回。
怎么設置線程池核心數
需要看我們的任務是CPU密集型還是IO密集型。
CPU密集型：
CPU密集的意思是該任務需要大量的運算，即需要長時間大量的CPU運行。
CPU密集型任務配置盡可能少的線程數量：
最佳線程池核心線程數=CPU核數+1
IO密集型：
IO密集型，即該任務需要大量的IO，會造成大量的阻塞。
在單線程上運行IO密集型的任務會導致浪費大量的CPU運算能力浪費在等待。
所以在IO密集型任務中使用多線程可以大大的加速程序運行，即使在單核CPU上，這種加速主要就是利用了被浪費掉的阻塞時間。
參考公式1：CPU核數/(1-阻塞系數)
阻塞系數在0.8~0.9之間
比如8核CPU:8/1-0.9=80個線程數
參考公式2：CPU核數*2
傳統并發編程
synchronized
同步代碼塊，代碼塊內的代碼需要獲取鎖對象才能執行，用于解決多線程中臟數據問題。
synchronized只有持有鎖時才對其他線程有排他性，當wait釋放鎖時，其他線程就可以進入synchronized代碼塊內的，Lock.lock和Condition.await同理。
代碼示例：
Object lock=new Object();
Thread a=new Thread(){public void run(){//a線程要干的活...synchronized(lock){//需要對共享變量進行操作，防止多個線程修改形成臟數據，使用synchronized加鎖...//如果a線程需要別的線程配合干的活，別的線程干完了，a線程繼續干活，這時候需要使用wait()，調用try {lock.wait();//一旦線程調用了wait，則必須等待其他線程釋放鎖并且調用notify，否則一直處于等待狀態，即使別的線程執行完畢a線程也不會自動從等待中恢復執行。} catch (InterruptedException e) {e.printStackTrace();}}}
};
a.start();
Thread b=new Thread(){public void run(){//b線程要干的活...synchronized(lock){//需要對共享變量進行操作，防止多個線程修改形成臟數據，使用synchronized加鎖...//b線程需要別的線程配合干的活，b線程干完了就通知其他線程執行。lock.notify();}}
};
b.start();
synchronized鎖
任何對象都可以作為synchronized鎖。synchronized定義在靜態方法上，鎖就是類的class對象，synchronized定義在實例方法上，鎖就是調用該方法的實例對象。
synchronized的重入的實現機理
使用javap編譯.class文件之后可以查看到synchronized相關字節碼代碼，以下內容皆源于此。
每個鎖對象擁有一個鎖計數器和一個指向持有該鎖的線程的指針。
當執行monitorenter時，如果目標鎖對象的計數器為零，那么說明它沒有被其他線程所持有，Java虛擬機會將該鎖對象的持有線程設置為當前線程，并且將其計數器加1。
在目標鎖對象的計數器不為零的情況下，如果鎖對象的持有線程是當前線程，那么Java虛擬機可以將其計數器加1，否則需要等待,直至持有線程釋放該鎖。
當執行 monitorexit時，Java虛擬機則需將鎖對象的計數器減1。計數器為零代表鎖已被釋放。
一個monitorenter為什么對應兩個monitorexit？
因為后面那個是為了保證異常情況下也能釋放鎖。
Object多線程相關方法
wait
Object.wait使線程處于等待狀態（線程狀態），除非其他線程釋放鎖并且調用notify，否則該線程一直處于等待狀態，即使別的線程執行完畢該線程也不會自動從等待中恢復執行。用于解決多線程中線程交互問題。
notify
Object.notify通知其他等待狀態的線程，變成可運行狀態，重新參與鎖競爭。用于解決多線程中線程交互問題。
notifyAll
Object.notifyAll和notify一樣，區別在于notify每次只喚醒一個線程，如果有多個線程在等待狀態，則隨機喚醒一個，而notifyAll將喚醒所有等待狀態的線程。
Thread常用方法
sleep
Thread.sleep讓出當前線程運行權，使線程處于記時等待狀態，不會釋放鎖。
yield
Thread.yield讓出當前線程運行權，不改變線程狀態，不會釋放鎖。
sleep和wait的區別
最重要的區別：sleep不會釋放鎖，wait會釋放鎖。
sleep和yield的區別
最重要的區別：sleep會改變線程狀態（變為timed waiting狀態），yield不會改變線程狀態（仍然是runnable）。
setPriority
thread.setPriority，設置線程權重,數值越大權重越高.在非公平鎖中，可以設置權重優化線程執行效率。
setDaemon
thread.setDaemon，設置線程為守護線程
setName
thread.setName，設置線程名稱
isAlive
thread.isAlive，獲取線程是否還活著。
只有New和Terminated狀態才會返回false，其余都返回true。
volatile
volatile保證內存的可見性和禁止指令重排序。用于解決多線程中臟數據問題。比synchronized更輕量級（說人話就是效率更高，更節省資源）。
以下程序的t1線程會死循環出不來，System.out.println("我看不到")不會執行，因為線程t1的flag是主內存flag的拷貝，而且是while循環開始時拷貝一份之后就不再拷貝，必須等while結束后才能重新從主內存拷貝，所以t1線程里的flag永遠為true。解決辦法就是在flag變量上加上volatileprivate static volatile boolean flag = false;。
private static boolean flag = false;public static void main(String[] args) {Thread t1 = new Thread(new Runnable() {@Overridepublic void run() {while (!flag) {}System.out.println("我看不到");}});t1.start();Thread t2 = new Thread(new Runnable() {@Overridepublic void run() {try {Thread.sleep(1000);} catch (InterruptedException e) {e.printStackTrace();}System.out.println("我改了");flag = true;}});t2.start();}
但是volatile只能保證可見性（說人話就是，多個地方讀沒問題），不能保證原子性（說人話就是，多個地方寫就有問題），以下程序如果反復多次運行，會發現幾乎每次打印結果都少于10000。
public static volatile int inc = 0;public static void main(String[] args) throws Exception {for (int i = 0; i < 100; i++) {new Thread() {public void run() {for (int j = 0; j < 100; j++) {inc=inc+1;}};}.start();}while (Thread.activeCount() > 1) {//如果有main線程之外的線程在運行，就一直循環，保證后面的打印在最后執行Thread.yield();}System.out.println(inc);}
因為，inc=inc+1操作并不是原子的操作。要想解決這個問題，不能用volatile，得用java.util.concurrent.atomic包下的原子類。下面代碼可以保證每次都打印10000。
public static AtomicInteger inc = new AtomicInteger(0);public static void main(String[] args) throws Exception {for (int i = 0; i < 100; i++) {new Thread() {public void run() {for (int j = 0; j < 100; j++) {inc.incrementAndGet();}};}.start();}while (Thread.activeCount() > 1) {//如果有main線程之外的線程在運行，就一直循環，保證后面的打印在最后執行Thread.yield();}System.out.println(inc);}
當然用synchronized也能解決問題，但沒必要。
虛假喚醒
虛假喚醒就是在多線程執行過程中，線程間的通信未按照我們幻想的順序喚醒，故出現數據不一致等不符合我們預期的結果。而出現虛假喚醒的問題就是在if語句上，將if換成while就行。
wait規范
Object.wait、Condition.await、LockSupport.park都應該在循環中使用。
JDK官方文檔給出代碼建議是這樣的：
/*** 建議的等待方法是在調用等待的while循環中檢查等待的條件，如下面的示例所示。除此之外，這種方法還避免了可能由虛假喚醒引起的問題。*/
synchronized (obj) {while (<條件不成立> and <如果沒有超時>) {long timeoutMillis = ... ; // 重新計算超時值int nanos = ... ;obj.wait(timeoutMillis, nanos);}... // 執行適合于條件或超時的操作
}
模擬問題
反復運行以下代碼就會發現問題，明明有判斷number == 0就wait卻還是會產生負數：
public class Test {public static void main(String[] args) {final Work work = new Work();new Thread("A") {public void run() {for (int i = 0; i < 10; i++) {work.producer();}}}.start();new Thread("B") {public void run() {for (int i = 0; i < 10; i++) {work.consumer();}}}.start();new Thread("C") {public void run() {for (int i = 0; i < 10; i++) {work.producer();}}}.start();new Thread("D") {public void run() {for (int i = 0; i < 10; i++) {work.consumer();}}}.start();}
}class Work{private int number = 0;private Lock lock = new ReentrantLock();private Condition condition = lock.newCondition();public void producer(){lock.lock();try {// 1判斷if (number != 0) {//這里不能用if，if會產生虛假喚醒問題// 等待，不能生產condition.await();}// 2干活number++;System.out.println(Thread.currentThread().getName() + "\t" + number);// 3通知喚醒condition.signalAll();} catch (Exception e) {e.printStackTrace();} finally {lock.unlock();}}public void consumer(){lock.lock();try {// 1判斷if (number == 0) {//這里不能用if，if會產生虛假喚醒問題// 等待，不能生產condition.await();}// 2干活number--;System.out.println(Thread.currentThread().getName() + "\t" + number);// 3通知喚醒condition.signalAll();} catch (Exception e) {e.printStackTrace();} finally {lock.unlock();}}
}
打印：
A 1
B 0
C 1
B 0
A 1
C 2
D 1
D 0
B -1
B -2
B -3
B -4
B -5
B -6
B -7
B -8
A -7
C -6
D -7
D -8
D -9
D -10
D -11
A -10
C -9
D -10
D -11
D -12
A -11
C -10
A -9
C -8
A -7
C -6
A -5
C -4
A -3
C -2
A -1
C 0
分析問題
我們可以來分析一下為什么會出現負數B -1（其實C 2也有問題，和B -1產生的原因一樣）：
當D消費了一個產品，使用了signalAll函數，把其他三個線程（ABC）都喚醒了，但B是消費者調用的是consumer函數，在被D喚醒之前，B被卡在await()函數，喚醒后因為是在if語句塊中，那么B不再需要再判斷number是否等于0，就直接往下執行number--的語句，因此造成了虛假喚醒的問題，解決的辦法很簡單，只需要把if語句換成while語句即可，讓他在被喚醒之后，再次判斷number的數量再決定能不能執行number–的操作。
JUC并發編程需要了解的概念
CAS
CAS是Compare and Swap的縮寫，意思就是比較并交換。是用來保證原子性，支持多線程中修改共享數據的問題。歸根結底還是為了解決多線程中臟數據問題。
設計思想就是：
如果線程中修改主內存時，預先估計一個值，如果這個值和主內存的值不匹配，那么就不修改，并重新從主內存讀取最新值，并將這個最新值作為預先估計的值，再次和主內存的值進行比較，如果和主內存的值相同，則修改。
java的juc包中很多線程同步相關的類都使用了cas設計思想，java的cas主要依賴于Unsafe提供的native方法來實現，Unsafe只是調用了底層c++的Atomic，c++的Atomic也是依賴于匯編層面的原語CMPXCHG指令。詳情：C++ atomic詳解。自旋cas實現的基本思路就是java層面循環調用c++的Atomic操作直到成功為止。
下面是java原子類的CompareAndSwap
public final int updateAndGet(IntUnaryOperator updateFunction) {int prev, next;do {prev = get();next = updateFunction.applyAsInt(prev);} while (!compareAndSet(prev, next));//循環獲取值并比較return next;}public final int getAndUpdate(IntUnaryOperator updateFunction) {int prev, next;do {prev = get();next = updateFunction.applyAsInt(prev);} while (!compareAndSet(prev, next));//循環獲取值并比較return prev;}public final boolean compareAndSet(int expect, int update) {return unsafe.compareAndSwapInt(this, valueOffset, expect, update);//這里就是調用下面c++的Unsafe_CompareAndSwapInt了}
下面代碼是java本地方法(c++)的CompareAndSwap
UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapInt(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jint e, jint x))UnsafeWrapper("Unsafe_CompareAndSwapInt");oop p= JNIHandles::resolve(obj);jint* addr =(jint * index_oop_from_field_offset_long(p, offset);return (jint)(Atomic:: cmpchg(x, addr, e))==e;//Atomic:: cmpchg，原子的調用匯編指令'CMPXCHG'
UNSAFE_END
cas屬于一種樂觀鎖，和根據版本號修改數據庫數據的樂觀鎖是一樣的。
cas缺點：
1.只是解決了原子性，沒有解決可見性，需要配合volatile一起使用。（所以java.util.concurrent.atomic包的類里使用了volatile）。
public class AtomicInteger extends Number implements java.io.Serializable {private static final Unsafe unsafe = Unsafe.getUnsafe();//unsafe提供原子性private static final long valueOffset;private volatile int value;//volatile提供可見性public AtomicInteger(int initialValue) {value = initialValue;}...
}
2.如果比較不一致就需要循環查詢最新值，這會耗費系統資源。
3.會引發ABA問題
ABA問題
主內存有個變量值為A，有兩個線程a和b同時讀取了主內存的A到自己內存空間，此后a線程修改主內存為B，然后又將主內存修改為A，此時如果b線程去修改主內存，就無法發覺變量值A已經被改過了，無法意識到此A非彼A。這個情況應該是要避免的。
如果不關心過程，只關心開頭A和結尾A對得上，那么ABA問題其實可以忽略。
但是有的業務，會要求一個線程操作過程不能被其他線程修改，這時候就需要解決ABA問題。
ABA問題的解決
加版本號。
jdk中提供了帶版本號的原子類型AtomicStampedReference。
JUC并發編程
juc是java.util.concurrent包的簡稱，傳統的synchronized并發編程性能太低，所以JDK1.5提供java.util.concurrent并發包，提供了一系列多線程并發編程相關的API和工具，用以替代傳統的synchronized并發編程。
atomic
java.util.concurrent.atomic包的相關類，提供原子操作相關的API和工具。
AtomicInteger
//以原子方式將輸入的數值與實例中的值(AtomicInteger里的value)相加，并返回結果。
int addAndGet(int delta)//如果輸入的數值等于預期值，則以原子方式將該值設置為輸入的值。
boolean compareAndSet(int expect, int update)//以原子方式將當前值加1，注意，這里返回的是自增之前的值。
int getAndIncrement()//最終會設置成newValue，使用lazySet設置值后，可能導致其他線程在之后的一小段時間內還算可以讀到舊的值。
void lazySet(int newValue)//以原子方式設置為newValue的值，并返回舊值。
int getAndSet(int newValue)
AtomicLong
原子長整型，使用同AtomicInteger。
AtomicBoolean
原子布爾值，使用同AtomicInteger。
AtomicDouble
java沒有提供AtomicDouble，如果需要可以使用谷歌的guava工具庫中有AtomicDouble。
<dependency><groupId>com.google.guava</groupId><artifactId>guava</artifactId></dependency>
AtomicReference
原子引用類，使用和AtomicInteger差不多，但參數都是對象引用。
AtomicStampedReference
帶版本號的引用原子類。原子引用類，使用和AtomicReference差不多，多了一個舊版本號參數而已（用來比較）。
其他原子類
AtomicIntegerArray，原子更新整型數組里的元素。
AtomicLongArray，原子更新長整型數組里的元素。
AtomicReferenceArray，原子更新引用類型數組里的元素。
同步與鎖（synchronized）
Lock
juc包下的所有鎖對象的超級接口。
最核心的方法就兩個：
void lock();//加鎖
void unlock();//解鎖
使用示例：
public void m() {lock.lock();try {// ...} finally {lock.unlock();}}
ReentrantLock
re=再次，entrant=進入，翻譯過來就是可重入鎖。
是代替synchronized的實現，是比synchronized更加輕量級的鎖。
示例代碼：
ReentrantLock lock = new ReentrantLock();// lockpublic void m1() {lock.lock();try {// ... method body} finally {lock.unlock();}}// tryLockpublic void m2() {if (lock.tryLock()) {try {// 你的業務代碼} finally {lock.unlock();}}else{// 你的業務代碼}}// tryLock timepublic void m3() {try{if (lock.tryLock(1, TimeUnit.MINUTES)) {try {// 你的業務代碼} finally {lock.unlock();}}else{// 你的業務代碼}}catch(Exception e){//當前線程被中斷（interrupted）時tryLock(time)會拋出異常。// 你的業務代碼}}// tryLock和tryLock timepublic void m5() {try{//強行插入一個公平的鎖if (lock.tryLock()||lock.tryLock(1, TimeUnit.MINUTES)) {try {// 你的業務代碼} finally {lock.unlock();}}else{// 你的業務代碼}}catch(Exception e){//當前線程被中斷（interrupted）時tryLock(time)會拋出異常。// 你的業務代碼}}
ReentrantLock和synchronized比較
-
原始構成不同
synchronized是關鍵字屬于JVM層面，依靠monitorenter和monitorexit指令還完成加鎖和解鎖。
（monitorenter和monitorexit底層是通過monitor對象來完成，其實wait/notify等方法也依賴于monitor對象，具體可以查看Monitor簡介）
Lock是具體類是api層面的鎖。 -
使用方法不同
synchronized不需要用戶去手動釋放鎖，當 synchronized代碼執行完后系統會自動讓線程釋放對鎖的占用。
ReentrantLock則需要用戶去手動釋放鎖，若沒有主動釋放鎖，就有可能導致出現死鎖現象。
需要lock()和unlock()方法配合try/finally語句塊來完成。 -
獲取鎖時阻塞是否可中斷
synchronized不可中斷，除非拋出異?；蛘哒＿\行完成。
ReentrantLock可用兩種方式中斷
1.設置超時方法 tryLock( long timeout, TimeUnit unit)。
2.lockInterruptibly()放代碼塊中，調用interrupt()方法可中斷。 -
獲取鎖是否公平
synchronized權重鎖（非公平鎖），可以通過Thread.setPriority(數值越大權重越高)設置線程權重。
ReentrantLock兩者都可以，默認不公平鎖，構造方法可以傳入boolean值，true為公平鎖， false為非公平鎖。 -
喚醒條件不同
synchronized只能調用Object的notify隨機喚醒一個或者notifyAll喚醒全部。
ReentrantLock支持多條件喚醒（一個Lock可以多次調用newCondition獲取不同的鑰匙），可以做到精確喚醒指定線程。
在實際項目中，使用synchronized還是ReentrantLock是根據業務要求來的，如果確實一定要獲取鎖的情況下才能繼續操作，那么可以使用synchronized，如果獲取不到鎖就返回提示這種業務，那就需要使用ReentrantLock。
ReentrantReadWriteLock
ReentrantReadWriteLock是jdk對讀寫鎖的一個實現。
ReentrantReadWriteLock 實現了 ReadWriteLock 接口，ReadWriteLock 接口定義了獲取讀鎖和寫鎖的規范，具體需要實現類去實現。
同時其還實現了Serializable接口，表示可以進行序列化，在源代碼中可以看到ReentrantReadWriteLock 實現了自己的序列化邏輯。
使用示例：
public void read() {lock.readLock().lock();try {// 讀取使用共享資源// ...} finally {lock.readLock().unlock();}}public void write() {lock.writeLock().lock();try {// 修改共享資源// ...} finally {lock.writeLock().unlock();}}
使用建議：
在線程持有讀鎖的情況下，該線程不能取得寫鎖(因為獲取寫鎖的時候，如果發現當前的讀鎖被占用，就馬上獲取失敗，不管讀鎖是不是被當前線程持有)。
在線程持有寫鎖的情況下，該線程可以繼續獲取讀鎖（獲取讀鎖時如果發現寫鎖被占用，只有寫鎖沒有被當前線程占用的情況才會獲取失敗）。
原因: 當線程獲取讀鎖的時候，可能有其他線程同時也在持有讀鎖，因此不能把獲取讀鎖的線程“升級”為寫鎖；而對于獲得寫鎖的線程，它一定獨占了讀寫鎖，因此可以繼續讓它獲取讀鎖，當它同時獲取了寫鎖和讀鎖后，還可以先釋放寫鎖繼續持有讀鎖，這樣一個寫鎖就“降級”為了讀鎖。
鎖降級：
ReentrantReadWriteLock能夠支持寫鎖降級成為讀鎖。
阻塞與喚醒（wait/notify）
Condition
Condition是一個接口，提供和wait/notify功能，Condition使用時需要依賴于Lock。用于解決多線程中線程交互問題。
Condition內部調用的就是LockSupport，是對LockSupport的加強。
Condition是線程等待和喚醒機制，是wait和notify的改良加強版。
await=wait，signal=notify
jdk自帶的實現有：
AbstractQueuedLongSynchronizer.ConditionObject
AbstractQueuedSynchronizer.ConditionObject
CountDownLatch
表面意思為倒數的門栓，實際是一種特殊的阻塞工具類，和Condition有點像，但不需要和Lock配合也可單獨使用。
CountDownLatch允許一個或者多個線程去等待其他線程完成操作。
CountDownLatch內部維護一個倒數的計數器，初始值是線程的數量，每當一個線程執行完畢后，計數器的值就-1，當計數器的值為0時，表示所有線程都執行完畢，方可繼續執行后續代碼，否則一直等待。
await:
調用await方法的線程會被掛起，它會等待直到count值為0才續執行。
多個線程執行await()方法，那么這幾個線程都將處于等待狀態，并且以共享模式享有同一個鎖。
await(long timeout, TimeUnit unit):
等待一定的時間后 count值還沒變為0的話，強行執行。
countDown:
將count值減1。countDown方法并沒有規定一個線程只能調用一次，當同一個線程調用多次countDown()方法時，每次都會使計數器減一。
CyclicBarrier
和CountDownLatch類似，也是一種特殊的阻塞工具類，只是將減法變成加法，加到目標值，調用await方法的線程才會執行。
Semaphore
又被稱為信號燈，一種特殊的阻塞工具類，在多線程環境下用于協調各個線程正確、合理的使用資源。
Semaphore內部維護了一個許可證列表，Semaphore允許一個線程獲取和釋放多個許可證。
acquire:獲取1個許可證
acquire(int):獲取n個許可證
如果許可證已分配完了，那么線程將進入等待狀態，直到其他線程釋放許可證才有機會再獲取許可。
release:釋放1個許可證
release(int):釋放n個許可證
線程釋放一個許可證，許可證將被歸還給Semaphore,
阻塞與喚醒底層支持（wait/notify）
AQS
是AbstractQueuedSynchronizer：抽象的隊列同步器，線程獲取不到鎖時，把它們放入隊列中來排隊獲取鎖。
是用來構建鎖或者其它同步器組件的重量級基礎框架及整個juc體系的基石，
通過內置的FIFO(先進先出的英文縮寫)隊列來完成資源獲取線程的排隊工作，并通過一個int類型變量
表示持有鎖的狀態。
LockSupport
lock support是什么
LockSupport是一個線程阻塞工具類，內部調用的是操作系統級別的native的阻塞原語。用于解決多線程中線程交互問題。
LockSupport是線程等待和喚醒機制，是wait和notify的改良加強版。
park=wait，unpark=notify
unpark可以在park執行之前被執行，如果unpark在park之前執行，則park被忽略。
使用場景
不需要lock的復雜功能，只需要wait和notify時使用。
一般來說，我們只需要調用Lock和Condition就夠了，不需要用到LockSupport。
底層實現
LockSupport的底層是調用Unsafe中的native方法實現的。
LockSupport內部維護了一個permit許可標志，permit只能為0或者1，為0表示不阻塞，為1表示阻塞，unpark就是將permit變成1
park和unpark方法實現阻塞線程和解除線程阻塞的。
LockSupport和每個使用它的線程都有一個許可( permit)關聯。 permit相當于1,0的開關，默認是0，
調用一次 unpark就加1變成1，調用一次park會消費 permit,也就是將1變成0，同時park立即返回。
如再次調用park會變成阻塞（因為 permit)為零了會阻塞在這里，一直到 permit變為1），這時調用 unpark會把 permit置為1。
每個線程都有一個相關的 permit, permiti最多只有一個，重復調用 unpark也不會積累憑證。
形象的理解
線程阻塞需要消耗憑證( permit),這個憑證最多只有1個。
當調用park方法時
*如果有憑證，則會直接消耗掉這個憑證然后正常退出；
*如果無憑證，就必須阻塞等待憑證可用
而 unpark則相反，它會增加一個憑證，但憑證最多只能有1個，累加無效。
為什么可以先喚醒線程后阻塞線程？
因為 unpark獲得了一個憑證，之后再調用park方法，就可以名正言順的憑證消費，故不會阻塞。
為什么喚醒兩次后阻塞兩次，但最終結果還會阻塞線程？
因為憑證的數量最多為1，連續調用兩次 unpark和調用一次 unpark效果一樣，只會增加一個憑證；
而調用兩次park卻需要消費兩個憑證，證不夠，不能放行。
Fork/Join
看這里：Java Fork/Join 并發編程
CompletableFuture
看這里：Java CompletableFuture 并發編程
多線程下正確使用集合
List線程安全問題
如下代碼list中可能會出現null值，并且數量也可能少于1000。
public static void main(String[] args) {List<String> list = new ArrayList<>();for (int i = 1; i <= 1000; i++) {new Thread() {public void run() {list.add(new Random().nextInt(1000)+"");};}.start();}while (Thread.activeCount() > 1) {// 如果有main線程之外的線程在運行，就一直循環，保證后面的打印在最后執行Thread.yield();}System.out.println(list.size());System.out.println(list);}
打印：
998
[null, null, 148, 890, 423, 771, 882, 521, 830,......
換成下面代碼，則會報java.lang.ArrayIndexOutOfBoundsException
public static void main(String[] args) {List<String> list = new ArrayList<>();for (int i = 1; i <= 1000; i++) {new Thread() {public void run() {list.add(new Random().nextInt(1000)+"");System.out.println(list.size());};}.start();}}
換成下面代碼，則會報java.util.ConcurrentModificationException
public static void main(String[] args) {List<String> list = new ArrayList<>();for (int i = 1; i <= 1000; i++) {new Thread() {public void run() {list.add(new Random().nextInt(1000)+"");System.out.println(list);};}.start();}}
原因：
ArrayList不是線程安全的，其提供的各種方法包括add方法都會在多線程環境下出現臟數據問題。
解決方案：
方案1
Vector代替ArrayList，Vector其實就是使用synchronized。不過Vector已經過時了，如里面提供的迭代器是老舊版本的迭代器，非常不推薦使用。
方案2
Collections.synchronizedList包裹ArrayList，其實也是使用synchronized。
方案3
CopyonwriteArrayList代替ArrayList，其實使用的是ReentrantLock，并且使用了讀寫分離思想，讀時不加鎖，修改才加鎖。
CopyonwriteArrayList源碼：
public E get(int index) {//不加鎖return get(getArray(), index);}public E set(int index, E element) {//加鎖final ReentrantLock lock = this.lock;lock.lock();try {Object[] elements = getArray();E oldValue = get(elements, index);if (oldValue != element) {int len = elements.length;Object[] newElements = Arrays.copyOf(elements, len);newElements[index] = element;setArray(newElements);} else {setArray(elements);}return oldValue;} finally {lock.unlock();}}
Set線程安全問題
和List差不多
1.使用Collections.synchronizedSet
1.使用java.util.concurrent.CopyOnWriteArraySet
Map線程安全問題
同ArrayList
1.使用Hashtable
2.使用Collections.synchronizedMap
3.使用java.util.concurrent.ConcurrentHashMap
阻塞隊列
阻塞隊列（BlockingQueue），首先它是一個隊列（Queue），而一個阻塞隊列在數據結構中所起的作用大致如下圖所示：
當阻塞隊列是空時，從隊列中獲取元素的操作將會被阻塞。也就是說試圖從空的阻塞隊列中獲取元素的線程將會被阻塞，直到其他的線程往空的隊列插入新的元素。
同樣當阻塞隊列是滿時，往隊列里添加元素的操作將會被阻塞。試圖往已滿的阻塞隊列中添加新元素的線程同樣也會被阻塞，直到其他的線程從列中移除一個或者多個元素或者完全清空隊列后使隊列重新變得空閑起來后才能繼續添加。
為什么需要阻塞隊列
好處是我們不需要關心什么時候需要阻塞線程，什么時候需要喚醒線程，因為這一切 BlockingQueue都給你一手包辦了
在 concurrent包發布以前，在多線程環境下，我們每個程序員都必須去自己控制這些細節，尤其還要兼顧效率和線程安全，而
這會給我們的程序帶來不小的復雜度。
常用的阻塞隊列
ArrayBlockingQueue:由數組結構組成的有界阻塞隊列。
LinkedBlockingQueue:由鏈表結構組成的有界（但大小默認值為 Integer.MAx_ VALUE)阻塞隊列。
PriorityBlockingQueue:支持優先級排序的無界阻塞隊列。
DelayQueue:使用優先級隊列實現的延遲無界阻塞隊列。
SynchronousQueue:不存儲元素的阻塞隊列，也即單個元素的隊列。
LinkedTransferQueue:由鏈表結構組成的無界阻塞隊列。
LinkedBlockingDeque:由鏈表結構組成的雙向阻塞隊列
阻塞隊列常用方法
| 方法類型 | 拋出異常 | 特殊值 | 阻塞 | 超時 |
|---|---|---|---|---|
| 插入 | add(e) | offer(e) | put(e) | offer(e,time, unit) |
| 移除 | remove() | poll() | take() | poll(time,unit) |
| 檢查 | element() | peek() | 不可用 | 不可用 |
| 結果 | 操作 |
|---|---|
| 拋出異常 | 當阻塞隊列滿時，再往隊列里add插入元素會拋 lllegalState Exception: Queue full。 當阻塞隊列空時，再往隊列里 remove移除元素會拋 NoSuchElementException |
| 特殊值 | 插入方法，成功ture失敗 false移除方法，成功返回出隊列的元素，隊列里面沒有就返回null。 |
| 一直阻塞 | 當阻塞隊列滿時，生產者線程繼續往隊列里put元素，隊列會一直阻塞生產線程直到put數據or響應中斷退出。 當阻塞隊列空時，消費者線程試圖從隊列里take元素，隊列會一直阻塞消費者線程直到隊列可用。 |
| 超時退出 | 當阻塞隊列滿時，隊列會阻塞生產者線程一定時間，超過后限時后生產者線程會退出 |
阻塞隊列使用場景
生產者消費者模式
消息中間件（也是生產者消費者模式）
線程池
連接池
ThreadLocal
看這里：ThreadLocal詳解
線上定位問題線程
看這里：Java定位問題線程
總結
以上是生活随笔為你收集整理的Java多线程与并发编程终极宝典的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 形式验证进阶 chipdriver_【饥
- 下一篇： 编辑词条