java多线程学习笔记。
java多線程學(xué)習(xí)筆記
線程的優(yōu)缺點(diǎn)：
- 多線程的好處：
- 線程的風(fēng)險(xiǎn)：
一、概念
????? ?1.進(jìn)程：程序（任務(wù)）的執(zhí)行過(guò)程--正在執(zhí)行的（動(dòng)態(tài)）?進(jìn)程是資源（內(nèi)存，文件）和線程的載體。
? ? ? ? ?每個(gè)進(jìn)程都有獨(dú)立的代碼和數(shù)據(jù)空間（進(jìn)程上下文），進(jìn)程間的切換會(huì)有較大的開(kāi)銷，一個(gè)進(jìn)程包含1--n個(gè)線程。（進(jìn)程是資源分配的最小單位）。
????? ?2.線程: 系統(tǒng)執(zhí)行的最小單元（線程共享進(jìn)程的資源）【一個(gè)進(jìn)程可以有多個(gè)線程】
同一類線程共享代碼和數(shù)據(jù)空間，每個(gè)線程有獨(dú)立的運(yùn)行棧和程序計(jì)數(shù)器(PC)，線程切換開(kāi)銷小。（線程是cpu調(diào)度的最小單位）
????? ?3.線程的交互：互斥，同步
????? ?4.使用多線程的目的是更好的利用CPU資源
????? ?5.多線程：一個(gè)程序（進(jìn)程）運(yùn)行時(shí)產(chǎn)生了多個(gè)線程。?
????? ?6.并發(fā)與并行：
?
- 并行：多個(gè)CPU實(shí)例（多臺(tái)機(jī)器）同時(shí)執(zhí)行一段處理邏輯，是真正的同時(shí)。又稱共行性，是指能處理多個(gè)同時(shí)性活動(dòng)的能力；并行性指兩個(gè)或兩個(gè)以上事件或活動(dòng)在同一時(shí)刻發(fā)生。在多道程序環(huán)境下，并行性使多個(gè)程序同一時(shí)刻可在不同CPU上同時(shí)執(zhí)行。
- 并發(fā)：通過(guò)CPU調(diào)度算法（同一個(gè)CPU），讓用戶看上去同時(shí)執(zhí)行（宏觀上來(lái)看是同時(shí)的），實(shí)際上從CPU操作層面不是真正的同時(shí)。并發(fā)往往在場(chǎng)景中有公用的資源，那么針對(duì)這個(gè)公用的資源往往產(chǎn)生瓶頸，我們會(huì)用tps或者qps來(lái)反應(yīng)這個(gè)系統(tǒng)的處理能力。在微觀上他們都是序列被處理的，只不過(guò)資源不會(huì)在某一個(gè)上被阻塞(一般是通過(guò)時(shí)間片輪轉(zhuǎn))。如果是同一時(shí)刻到達(dá)的請(qǐng)求也會(huì)根據(jù)優(yōu)先級(jí)的不同，而先后進(jìn)入隊(duì)列排隊(duì)等候執(zhí)行。并發(fā)的實(shí)質(zhì)是一個(gè)物理CPU(也可以多個(gè)物理CPU) 在若干道程序之間多路復(fù)用，并發(fā)性是對(duì)有限物理資源強(qiáng)制行使多用戶共享以提高效率。
- 并發(fā)和并行的區(qū)別：
1.并發(fā)是一次處理很多事情（一個(gè)人做多件事情），并行是同時(shí)做很多事情（多個(gè)人做很多事情）
2.并發(fā)是獨(dú)立執(zhí)行過(guò)程的組合，而并行是同時(shí)執(zhí)行（可能相關(guān)的）計(jì)算。
3.并發(fā)是兩個(gè)任務(wù)可以在重疊的時(shí)間段內(nèi)啟動(dòng)，運(yùn)行和完成。并行是任務(wù)在同一時(shí)間運(yùn)行，例如，在多核處理器上。
4.并行是指同時(shí)發(fā)生的兩個(gè)并發(fā)事件，具有并發(fā)的含義，而并發(fā)則不一定并行，也亦是說(shuō)并發(fā)事件之間不一定要同一時(shí)刻發(fā)生。? -
通過(guò)多線程實(shí)現(xiàn)并發(fā)，并行：
- java中的Thread類定義了多線程，通過(guò)多線程可以實(shí)現(xiàn)并發(fā)或并行。
- 在CPU比較繁忙，資源不足的時(shí)候（開(kāi)啟了很多進(jìn)程），操作系統(tǒng)只為一個(gè)含有多線程的進(jìn)程分配僅有的CPU資源，這些線程就會(huì)為自己盡量多搶時(shí)間片，這就是通過(guò)多線程實(shí)現(xiàn)并發(fā)，線程之間會(huì)競(jìng)爭(zhēng)CPU資源爭(zhēng)取執(zhí)行機(jī)會(huì)。
- 在CPU資源比較充足的時(shí)候，一個(gè)進(jìn)程內(nèi)的多線程，可以被分配到不同的CPU資源，這就是通過(guò)多線程實(shí)現(xiàn)并行。
- 至于多線程實(shí)現(xiàn)的是并發(fā)還是并行？上面所說(shuō)，所寫(xiě)多線程可能被分配到一個(gè)CPU內(nèi)核中執(zhí)行，也可能被分配到不同CPU執(zhí)行，分配過(guò)程是操作系統(tǒng)所為，不可人為控制。所有，如果有人問(wèn)我我所寫(xiě)的多線程是并發(fā)還是并行的？我會(huì)說(shuō)，都有可能。
- 不管并發(fā)還是并行，都提高了程序?qū)PU資源的利用率，最大限度地利用CPU資源。
二、java對(duì)線程的支持
? ? 1.Runnable接口
? ? 2.Thread類
????3.Callable接口
join()：線程A中調(diào)用線程B的B.join()方法，那么線程A放棄cpu資源，等待線程B執(zhí)行完畢之后線程A再繼續(xù)執(zhí)行。可以用來(lái)將并行的線程改為串行執(zhí)行。并且只有線程A調(diào)用了start()方法之后才能調(diào)用join()方法。join是通過(guò)調(diào)用wait()方法來(lái)實(shí)現(xiàn)的。
yield():就是當(dāng)前線程不忙的時(shí)候，暗示自己的資源可以讓出來(lái)。
Thread.yield();
- Yield是一個(gè)靜態(tài)的原生(native)方法
- Yield告訴當(dāng)前正在執(zhí)行的線程把運(yùn)行機(jī)會(huì)交給線程池中擁有相同優(yōu)先級(jí)的線程。
- Yield不能保證使得當(dāng)前正在運(yùn)行的線程迅速轉(zhuǎn)換到可運(yùn)行的狀態(tài)
- 它僅能使一個(gè)線程從運(yùn)行狀態(tài)轉(zhuǎn)到可運(yùn)行狀態(tài)，而不是等待或阻塞狀態(tài)
- 放棄當(dāng)前cpu資源，但放棄的時(shí)間不確定，有可能剛放棄，馬上又獲得cpu時(shí)間片。
?
wait():讓當(dāng)前線程進(jìn)入等待狀態(tài)，并釋放鎖，一直到其他線程調(diào)用當(dāng)前線程的notify或者notifyall方法，或者超時(shí)，等待的線程才會(huì)被喚醒，進(jìn)入可運(yùn)行狀態(tài)。
notify：隨機(jī)喚醒等待同一資源的線程。
notifyall：喚醒所有等待同一資源的線程。
?
注：wait和notify必須被包含在synchronized里面，否則會(huì)拋異常，
? ? ? wait執(zhí)行之后立馬釋放鎖，? notify執(zhí)行之后，會(huì)繼續(xù)吧加鎖的代碼執(zhí)行完了之后才釋放鎖。
?
ThreadLocal：線程可以用該類set()值，并且多線程相互之間set的值互不影響get的獲取。
InheritableThreadLocal：可以繼承父線程才值，但是如果子線程獲取值的同時(shí)，父線程修改了值，那么子線程獲取到的依然是舊的值。
?
?
Thread和Runnable的區(qū)別
????如果一個(gè)類繼承Thread，則不適合資源共享。但是如果實(shí)現(xiàn)了Runable接口的話，則很容易的實(shí)現(xiàn)資源共享。
總結(jié)：
實(shí)現(xiàn)Runnable接口比繼承Thread類所具有的優(yōu)勢(shì)：
1）：適合多個(gè)相同的程序代碼的線程去處理同一個(gè)資源
2）：可以避免java中的單繼承的限制
3）：增加程序的健壯性，代碼可以被多個(gè)線程共享，代碼和數(shù)據(jù)獨(dú)立
4）：線程池只能放入實(shí)現(xiàn)Runable或callable類線程，不能直接放入繼承Thread的類
在java中，每次程序運(yùn)行至少啟動(dòng)2個(gè)線程。一個(gè)是main線程，一個(gè)是垃圾收集線程。因?yàn)槊慨?dāng)使用java命令執(zhí)行一個(gè)類的時(shí)候，實(shí)際上都會(huì)啟動(dòng)一個(gè)ＪＶＭ，每一個(gè)ｊＶＭ實(shí)習(xí)在就是在操作系統(tǒng)中啟動(dòng)了一個(gè)進(jìn)程。
?
Callable和Runnale的區(qū)別
Callable可以有返回值和拋出異常。
?
??三、線程的狀態(tài)
? ? 線程和進(jìn)程一樣分為五個(gè)階段：創(chuàng)建、就緒、運(yùn)行、阻塞、終止。
?
?
1、新建狀態(tài)（New）：新創(chuàng)建了一個(gè)線程對(duì)象。
2、就緒狀態(tài)（Runnable）：線程對(duì)象創(chuàng)建后，其他線程調(diào)用了該對(duì)象的start()方法。該狀態(tài)的線程位于可運(yùn)行線程池中，變得可運(yùn)行，等待獲取CPU的使用權(quán)。
3、運(yùn)行狀態(tài)（Running）：就緒狀態(tài)的線程獲取了CPU，執(zhí)行程序代碼。
4、阻塞狀態(tài)（Blocked）：阻塞狀態(tài)是線程因?yàn)槟撤N原因放棄CPU使用權(quán)，暫時(shí)停止運(yùn)行。直到線程進(jìn)入就緒狀態(tài)，才有機(jī)會(huì)轉(zhuǎn)到運(yùn)行狀態(tài)。阻塞的情況分三種：
（一）、等待阻塞：運(yùn)行的線程執(zhí)行wait()方法，JVM會(huì)把該線程放入等待池中。(wait會(huì)釋放持有的鎖)
（二）、同步阻塞：運(yùn)行的線程在獲取對(duì)象的同步鎖時(shí)，若該同步鎖被別的線程占用，則JVM會(huì)把該線程放入鎖池中。
（三）、其他阻塞：運(yùn)行的線程執(zhí)行sleep()或join()方法，或者發(fā)出了I/O請(qǐng)求時(shí)，JVM會(huì)把該線程置為阻塞狀態(tài)。當(dāng)sleep()狀態(tài)超時(shí)、join()等待線程終止或者超時(shí)、或者I/O處理完畢時(shí)，線程重新轉(zhuǎn)入就緒狀態(tài)。（注意,sleep是不會(huì)釋放持有的鎖）
5、死亡狀態(tài)（Dead）：線程執(zhí)行完了或者因異常退出了run()方法，該線程結(jié)束生命周期。
?
- 取消和中斷：
interrupt（）；
- 不安全的取消
單獨(dú)使用一個(gè)取消標(biāo)志位.
Stop(),suspend(),resume()是過(guò)期的api，很大的副作用，容易導(dǎo)致死鎖或者數(shù)據(jù)不一致。
- 安全的終止線程
? ? ??使用線程的中斷 :
interrupt() 中斷線程標(biāo)記，本質(zhì)是將線程的中斷標(biāo)志位設(shè)為true，其他線程向需要中斷的線程打個(gè)招呼。是否真正進(jìn)行中斷由線程自己決定。
isInterrupted() ：線程檢查自己的中斷標(biāo)志位，不會(huì)將狀態(tài)重置。
interrupted()：靜態(tài)方法Thread.interrupted()?返回當(dāng)前中斷狀態(tài)并且將中斷標(biāo)志位復(fù)位為false：配合Thread.curentThread().interrupt(),來(lái)中斷當(dāng)前線程。
由上面的中斷機(jī)制可知Java里是沒(méi)有搶占式任務(wù)，只有協(xié)作式任務(wù)。
為何要用中斷，線程處于阻塞（如調(diào)用了java的sleep,wait等等方法時(shí)）的時(shí)候，是不會(huì)理會(huì)我們自己設(shè)置的取消標(biāo)志位的，但是這些阻塞方法都會(huì)檢查線程的中斷標(biāo)志位
當(dāng)使用
Thread?t1 = new Thread(new MyThread());
t1.interrupt();
t1設(shè)置的中斷標(biāo)記不會(huì)作用到MyThread類中。
?
中斷標(biāo)志是Thread的而非Runnable的。
在沉睡中停止：當(dāng)wait或sleep遇到interrupt，會(huì)拋出InterruptedException
?
- 不可中斷的阻塞
?java.io中的同步 socket?I/O:inputSream?和outputStream中的read和write方法都不響應(yīng)中斷。通過(guò)關(guān)閉底層的Socket來(lái)使其拋出一個(gè)SocketException。
java.nio中的同步I/O：
Selector的異步I/O：
注：在Thread中通過(guò)覆寫(xiě)interrupt來(lái)封裝非標(biāo)準(zhǔn)取消。
public class OverrideInterrupt extends Thread {private final Socket socket;private final InputStream in;public OverrideInterrupt(Socket socket, InputStream in) {this.socket = socket;this.in = in;}@Overridepublic void interrupt() {try {//關(guān)閉底層的套接字socket.close();} catch (IOException e) {e.printStackTrace();//.....}finally {//同時(shí)中斷線程super.interrupt();}}@Overridepublic void run(){try{byte[] buf = new byte[10];while(true){//}}catch (Exception e){//允許線程退出}} }?
線程間的通信：
通過(guò)管道來(lái)實(shí)現(xiàn)，pipedStream（pipedInputStream，pipedOutputStream）和pipedWriter，pipedReader
四、 線程調(diào)度
線程的調(diào)度
1、調(diào)整線程優(yōu)先級(jí)：Java線程有優(yōu)先級(jí)，優(yōu)先級(jí)高的線程會(huì)獲得較多的運(yùn)行機(jī)會(huì)。
?
Java線程的優(yōu)先級(jí)用整數(shù)表示，取值范圍是1~10，Thread類有以下三個(gè)靜態(tài)常量：
static int MAX_PRIORITY
????????? 線程可以具有的最高優(yōu)先級(jí)，取值為10。
static int MIN_PRIORITY
????????? 線程可以具有的最低優(yōu)先級(jí)，取值為1。
static int NORM_PRIORITY
????????? 分配給線程的默認(rèn)優(yōu)先級(jí)，取值為5。
?
Thread類的setPriority()和getPriority()方法分別用來(lái)設(shè)置和獲取線程的優(yōu)先級(jí)。
?
每個(gè)線程都有默認(rèn)的優(yōu)先級(jí)。主線程的默認(rèn)優(yōu)先級(jí)為T(mén)hread.NORM_PRIORITY。
線程的優(yōu)先級(jí)有繼承關(guān)系，比如A線程中創(chuàng)建了B線程，那么B將和A具有相同的優(yōu)先級(jí)。
JVM提供了10個(gè)線程優(yōu)先級(jí)，但與常見(jiàn)的操作系統(tǒng)都不能很好的映射。如果希望程序能移植到各個(gè)操作系統(tǒng)中，應(yīng)該僅僅使用Thread類有以下三個(gè)靜態(tài)常量作為優(yōu)先級(jí)，這樣能保證同樣的優(yōu)先級(jí)采用了同樣的調(diào)度方式。
?
2、線程睡眠：Thread.sleep(long millis)方法，使線程轉(zhuǎn)到阻塞狀態(tài)。millis參數(shù)設(shè)定睡眠的時(shí)間，以毫秒為單位。當(dāng)睡眠結(jié)束后，就轉(zhuǎn)為就緒（Runnable）狀態(tài)。sleep()平臺(tái)移植性好。
?
3、線程等待：Object類中的wait()方法，導(dǎo)致當(dāng)前的線程等待，直到其他線程調(diào)用此對(duì)象的 notify() 方法或 notifyAll() 喚醒方法。這個(gè)兩個(gè)喚醒方法也是Object類中的方法，行為等價(jià)于調(diào)用 wait(0) 一樣。
?
4、線程讓步：Thread.yield() 方法，暫停當(dāng)前正在執(zhí)行的線程對(duì)象，把執(zhí)行機(jī)會(huì)讓給相同或者更高優(yōu)先級(jí)的線程。
?
5、線程加入：join()方法，等待其他線程終止。在當(dāng)前線程中調(diào)用另一個(gè)線程的join()方法，則當(dāng)前線程轉(zhuǎn)入阻塞狀態(tài)，直到另一個(gè)進(jìn)程運(yùn)行結(jié)束，當(dāng)前線程再由阻塞轉(zhuǎn)為就緒狀態(tài)。
?
6、線程喚醒：Object類中的notify()方法，喚醒在此對(duì)象監(jiān)視器上等待的單個(gè)線程。如果所有線程都在此對(duì)象上等待，則會(huì)選擇喚醒其中一個(gè)線程。選擇是任意性的，并在對(duì)實(shí)現(xiàn)做出決定時(shí)發(fā)生。線程通過(guò)調(diào)用其中一個(gè) wait 方法，在對(duì)象的監(jiān)視器上等待。 直到當(dāng)前的線程放棄此對(duì)象上的鎖定，才能繼續(xù)執(zhí)行被喚醒的線程。被喚醒的線程將以常規(guī)方式與在該對(duì)象上主動(dòng)同步的其他所有線程進(jìn)行競(jìng)爭(zhēng)；例如，喚醒的線程在作為鎖定此對(duì)象的下一個(gè)線程方面沒(méi)有可靠的特權(quán)或劣勢(shì)。類似的方法還有一個(gè)notifyAll()，喚醒在此對(duì)象監(jiān)視器上等待的所有線程。
?注意：Thread中suspend()和resume()兩個(gè)方法在JDK1.5中已經(jīng)廢除，不再介紹。因?yàn)橛兴梨i傾向。
五、常用函數(shù)?
?六、volitale
(1)java內(nèi)存與多線程中的三個(gè)概念
1. 原子性：指一些操作要么全部執(zhí)行，要么全部不執(zhí)行。
在java中，基本數(shù)據(jù)類型的讀取賦值都是原子性操作。即這些操作是不可被中斷的，要么執(zhí)行，要么不執(zhí)行。
i=3; //原子性;i = i+2;++i;j = i;2.可見(jiàn)性：多個(gè)線程操作一個(gè)變量，變量值被線程修改時(shí)，其他線程能夠立即看見(jiàn)修改后的值。
每個(gè)線程都有自己的線程棧，當(dāng)線程執(zhí)行需要的數(shù)據(jù)時(shí)，會(huì)再主存（內(nèi)存）中數(shù)據(jù)拷貝到自己的線程棧中，然后對(duì)自己線程棧中的副本進(jìn)行操作，操作完了之后將數(shù)據(jù)save回到內(nèi)存中。
java提供的volitale可以保證數(shù)據(jù)的可見(jiàn)性
3.有序性：程序按照代碼的先后順序執(zhí)行，編譯器編譯時(shí)會(huì)對(duì)代碼進(jìn)行指令重排，編譯器通過(guò)限制語(yǔ)句的執(zhí)行順序來(lái)保證程序的正確性，重排之后的代碼可能和我們寫(xiě)的時(shí)候的順序不一樣。?
在單線程中，改變指令的順序可能不會(huì)產(chǎn)生不良后果，但是在多線程中就不一定了。例如：
?
//線程1: context = loadContext(); //語(yǔ)句1 inited = true; //語(yǔ)句2//線程2: while(!inited ){sleep() } doSomethingwithconfig(context);由于語(yǔ)句1和語(yǔ)句2沒(méi)有數(shù)據(jù)依賴性，所以編譯器可能會(huì)將兩條指令重新排序，如果先執(zhí)行語(yǔ)句2，這時(shí)線程1被阻塞，然后線程2的while循環(huán)條件不滿足，接著往下執(zhí)行，但是由于context沒(méi)有賦值，于是會(huì)產(chǎn)生錯(cuò)誤。
(2)volitale關(guān)鍵字的作用
volitale保障了可見(jiàn)性和一定程度的有序性，但是不保證原子性。
?
一旦一個(gè)共享變量（類的成員變量、類的靜態(tài)成員變量）被volatile修飾之后，那么就具備了兩層語(yǔ)義：
1）保證了不同線程對(duì)這個(gè)變量進(jìn)行操作時(shí)的可見(jiàn)性，即一個(gè)線程修改了某個(gè)變量的值，這新值對(duì)其他線程來(lái)說(shuō)是立即可見(jiàn)的。
2）禁止進(jìn)行指令重排序。
先看一段代碼，假如線程1先執(zhí)行，線程2后執(zhí)行：
//線程1 boolean stop = false; while(!stop){doSomething(); }//線程2 stop = true;?
這段代碼是很典型的一段代碼，很多人在中斷線程時(shí)可能都會(huì)采用這種標(biāo)記辦法。但是事實(shí)上，這段代碼會(huì)完全運(yùn)行正確么？即一定會(huì)將線程中斷么？不一定，也許在大多數(shù)時(shí)候，這個(gè)代碼能夠把線程中斷，但是也有可能會(huì)導(dǎo)致無(wú)法中斷線程（雖然這個(gè)可能性很小，但是只要一旦發(fā)生這種情況就會(huì)造成死循環(huán)了）。
下面解釋一下這段代碼為何有可能導(dǎo)致無(wú)法中斷線程。在前面已經(jīng)解釋過(guò)，每個(gè)線程在運(yùn)行過(guò)程中都有自己的工作內(nèi)存，那么線程1在運(yùn)行的時(shí)候，會(huì)將stop變量的值拷貝一份放在自己的工作內(nèi)存當(dāng)中。
那么當(dāng)線程2更改了stop變量的值之后，但是還沒(méi)來(lái)得及寫(xiě)入主存當(dāng)中，線程2轉(zhuǎn)去做其他事情了，那么線程1由于不知道線程2對(duì)stop變量的更改，因此還會(huì)一直循環(huán)下去。
但是用volatile修飾之后就變得不一樣了：
第一：使用volatile關(guān)鍵字會(huì)強(qiáng)制將修改的值立即寫(xiě)入主存；
第二：使用volatile關(guān)鍵字的話，當(dāng)線程2進(jìn)行修改時(shí)，會(huì)導(dǎo)致線程1的工作內(nèi)存中緩存變量stop的緩存行無(wú)效；
第三：由于線程1的工作內(nèi)存中緩存變量stop的緩存行無(wú)效，所以線程1再次讀取變量stop的值時(shí)會(huì)去主存讀取。
那么在線程2修改stop值時(shí)（當(dāng)然這里包括2個(gè)操作，修改線程2工作內(nèi)存中的值，然后將修改后的值寫(xiě)入內(nèi)存），會(huì)使得線程1的工作內(nèi)存中緩存變量stop的緩存行無(wú)效，然后線程1讀取時(shí)，發(fā)現(xiàn)自己的緩存行無(wú)效，它會(huì)等待緩存行對(duì)應(yīng)的主存地址被更新之后，然后去對(duì)應(yīng)的主存讀取最新的值。
那么線程1讀取到的就是最新的正確的值。
2、volitale關(guān)鍵字不能保證原子性?
下面看一個(gè)例子：?
?
根源就在這里，自增操作不是原子性操作，而且volatile也無(wú)法保證對(duì)變量的任何操作都是原子性的。
3、volitale關(guān)鍵字在一定程度上保證有序性
在前面提到volatile關(guān)鍵字能禁止指令重排序，所以volatile能在一定程度上保證有序性。
volatile關(guān)鍵字禁止指令重排序有兩層意思：
1）當(dāng)程序執(zhí)行到volatile變量的讀操作或者寫(xiě)操作時(shí)，在其前面的操作的更改肯定全部已經(jīng)進(jìn)行，且結(jié)果已經(jīng)對(duì)后面的操作可見(jiàn)；在其后面的操作肯定還沒(méi)有進(jìn)行；
2）在進(jìn)行指令優(yōu)化時(shí)，不能將在對(duì)volatile變量訪問(wèn)的語(yǔ)句放在其后面執(zhí)行，也不能把volatile變量后面的語(yǔ)句放到其前面執(zhí)行。
?
即使不使用volatile關(guān)鍵字，jvm也會(huì)盡量保證變量的可見(jiàn)性，比如sleep一段時(shí)間后，其它線程再去取就能取到最新，但是如果cpu一直很繁忙，那么就不能保證可見(jiàn)性，volatile是強(qiáng)制保證變量的可見(jiàn)性。
volatile修飾引用類型的時(shí)候，它只關(guān)心引用的變化，不關(guān)心引用內(nèi)部屬性的變化，所以volatile最好只修飾基本類型，不要去修飾引用類型。
結(jié)論：當(dāng)沒(méi)有把握的時(shí)候，最好不要使用。
volatile基于內(nèi)存屏障實(shí)現(xiàn)，保證一定的有序性
volatile基于實(shí)現(xiàn)保證可見(jiàn)性
總線風(fēng)暴：
由于Volatile的MESI緩存一致性協(xié)議，需要不斷的從主內(nèi)存嗅探和cas不斷循環(huán)，無(wú)效交互會(huì)導(dǎo)致總線帶寬達(dá)到峰值。
解決辦法：部分volatile和cas使用synchronize
鎖
概念：
鎖(lock)或互斥(mutex)是一種同步機(jī)制，用于在有許多執(zhí)行線程的環(huán)境中強(qiáng)制對(duì)資源的訪問(wèn)限制。鎖旨在強(qiáng)制實(shí)施互斥排他、并發(fā)控制策略。
1、鎖開(kāi)銷 lock overhead 鎖占用內(nèi)存空間、 cpu初始化和銷毀鎖、獲取和釋放鎖的時(shí)間。程序使用的鎖越多，相應(yīng)的鎖開(kāi)銷越大
2、鎖競(jìng)爭(zhēng) lock contention 一個(gè)進(jìn)程或線程試圖獲取另一個(gè)進(jìn)程或線程持有的鎖，就會(huì)發(fā)生鎖競(jìng)爭(zhēng)。鎖粒度越小，發(fā)生鎖競(jìng)爭(zhēng)的可能性就越小
3、死鎖 deadlock 至少兩個(gè)任務(wù)中的每一個(gè)都等待另一個(gè)任務(wù)持有的鎖的情況鎖粒度是衡量鎖保護(hù)的數(shù)據(jù)量大小，通常選擇粗粒度的鎖(鎖的數(shù)量少，每個(gè)鎖保護(hù)大量的數(shù)據(jù))，在當(dāng)單進(jìn)程訪問(wèn)受保護(hù)的數(shù)據(jù)時(shí)鎖開(kāi)銷小，但是當(dāng)多個(gè)進(jìn)程同時(shí)訪問(wèn)時(shí)性能很差。因?yàn)樵龃罅随i的競(jìng)爭(zhēng)。相反，使用細(xì)粒度的鎖(鎖數(shù)量多，每個(gè)鎖保護(hù)少量的數(shù)據(jù))增加了鎖的開(kāi)銷但是減少了鎖競(jìng)爭(zhēng)。例如數(shù)據(jù)庫(kù)中，鎖的粒度有表鎖、頁(yè)鎖、行鎖、字段鎖、字段的一部分鎖?
java的線程是映射到操作系統(tǒng)原生線程之上的，如果要阻塞或喚醒一個(gè)線程就需要操作系統(tǒng)介入，線程狀態(tài)切換會(huì)消耗cpu的處理時(shí)間。
1.鎖的分類（按特性）：
- 公平鎖/非公平鎖
- 可重入鎖(遞歸鎖)
- 獨(dú)享鎖/共享鎖
- 互斥鎖/讀寫(xiě)鎖
- 樂(lè)觀鎖/悲觀鎖
- 分段鎖
- 偏向鎖/輕量級(jí)鎖/重量級(jí)鎖
- 自旋鎖
1.1公平鎖/非公平鎖：
公平鎖：指多個(gè)線程按照申請(qǐng)鎖的順序來(lái)獲取鎖。CLH隊(duì)列排隊(duì)
非公平鎖：不按照申請(qǐng)鎖的順序來(lái)獲取鎖。可能會(huì)造成優(yōu)先級(jí)反轉(zhuǎn)或者饑餓現(xiàn)象，如:synchronized。 上來(lái)不排隊(duì)，直接插隊(duì)。
區(qū)別：非公平鎖的吞吐量比公平鎖大；
1.2可重入鎖(遞歸鎖):
同一個(gè)線程在外層方法獲取鎖的時(shí)候，在進(jìn)入內(nèi)層方法會(huì)自動(dòng)獲取鎖。好處是可一定程度避免死鎖。如：ReentrantLock，synchronized
可重入鎖加鎖和解鎖的次數(shù)要相等。
1.3獨(dú)享鎖/共享鎖：
都是通過(guò)AQS來(lái)實(shí)現(xiàn)的
獨(dú)享鎖：一次只能被一個(gè)線程所持有，如：synchronized，ReentrantLock，ReadWriteLock的寫(xiě)鎖。
共享鎖：可被多個(gè)線程所持有，如：ReadWriteLock的讀鎖。
1.4互斥鎖/讀寫(xiě)鎖:
互斥鎖 :ReentrantLock
讀寫(xiě)鎖:ReadWriteLock
1.5分段鎖：
分段鎖的設(shè)計(jì)目的是細(xì)化鎖的粒度，當(dāng)操作不需要更新整個(gè)數(shù)組的時(shí)候，就僅僅針對(duì)數(shù)組中的一項(xiàng)進(jìn)行加鎖操作；
如：ConcurrentHashMap 其并發(fā)的實(shí)現(xiàn)就是通過(guò)分段鎖的形式來(lái)實(shí)現(xiàn)高效的并發(fā)操作。
ConcurrentHashMap中的分段鎖稱為Segment，它即類似于HashMap（JDK7與JDK8中HashMap的實(shí)現(xiàn)）的結(jié)構(gòu)，即內(nèi)部擁有一個(gè)Entry數(shù)組，數(shù)組中的每個(gè)元素又是一個(gè)鏈表；同時(shí)又是一個(gè)ReentrantLock（Segment繼承了ReentrantLock)。
當(dāng)需要put元素的時(shí)候，并不是對(duì)整個(gè)hashmap進(jìn)行加鎖，而是先通過(guò)hashcode來(lái)知道他要放在那一個(gè)分段中，然后對(duì)這個(gè)分段進(jìn)行加鎖，所以當(dāng)多線程put的時(shí)候，只要不是放在一個(gè)分段中，就實(shí)現(xiàn)了真正的并行的插入。
但是，在統(tǒng)計(jì)size的時(shí)候，可就是獲取hashmap全局信息的時(shí)候，就需要獲取所有的分段鎖才能統(tǒng)計(jì)。
1.6偏向鎖/輕量級(jí)鎖/重量級(jí)鎖：
是針對(duì)Synchronized的狀態(tài)的鎖，這三種鎖的狀態(tài)是通過(guò)對(duì)象監(jiān)視器在對(duì)象頭中的字段來(lái)表明的。
從jdk1.6開(kāi)始為了減少獲得鎖和釋放鎖帶來(lái)的性能消耗，引入了“偏向鎖”和“輕量級(jí)鎖”。
偏向鎖：是指一段同步代碼一直被一個(gè)線程所訪問(wèn)，那么該線程會(huì)自動(dòng)獲取鎖。降低獲取鎖的代價(jià)。
輕量級(jí)鎖：是指當(dāng)鎖是偏向鎖的時(shí)候，被另一個(gè)線程所訪問(wèn)，偏向鎖就會(huì)升級(jí)為輕量級(jí)鎖，其他線程會(huì)通過(guò)自旋的形式嘗試獲取鎖，不會(huì)阻塞，提高性能。
重量級(jí)鎖：是指當(dāng)鎖為輕量級(jí)鎖的時(shí)候，另一個(gè)線程雖然是自旋，但自旋不會(huì)一直持續(xù)下去，當(dāng)自旋一定次數(shù)的時(shí)候，還沒(méi)有獲取到鎖，就會(huì)進(jìn)入阻塞，該鎖膨脹為重量級(jí)鎖。重量級(jí)鎖會(huì)讓其他申請(qǐng)的線程進(jìn)入阻塞，性能降低。
鎖共有四種狀態(tài)，級(jí)別從低到高分別是：無(wú)鎖狀態(tài)、偏向鎖狀態(tài)、輕量級(jí)鎖狀態(tài)和重量級(jí)鎖狀態(tài)。隨著競(jìng)爭(zhēng)情況鎖狀態(tài)逐漸升級(jí)、鎖可以升級(jí)但不能降級(jí)。
詳解轉(zhuǎn)自：https://blog.csdn.net/u010648018/article/details/79750608
1.7自旋鎖：
自旋鎖是指嘗試獲取鎖的線程不會(huì)立即阻塞，而是采用循環(huán)的方式去嘗試獲取鎖，這樣的好處是減少線程上下文切換的消耗，缺點(diǎn)是循環(huán)會(huì)消耗CPU。
public class SpinLock {private AtomicReference<Thread> sign =new AtomicReference<>();public void lock(){Thread current = Thread.currentThread();while(!sign.compareAndSet(null, current)){}}public void unlock (){Thread current = Thread.currentThread();sign.compareAndSet(current, null);}}使用了CAS原子操作，lock函數(shù)將owner設(shè)置為當(dāng)前線程，并且預(yù)測(cè)原來(lái)的值為空。unlock函數(shù)將owner設(shè)置為null，并且預(yù)測(cè)值為當(dāng)前線程。
當(dāng)有第二個(gè)線程調(diào)用lock操作時(shí)由于owner值不為空，導(dǎo)致循環(huán)一直被執(zhí)行，直至第一個(gè)線程調(diào)用unlock函數(shù)將owner設(shè)置為null，第二個(gè)線程才能進(jìn)入臨界區(qū)。
由于自旋鎖只是將當(dāng)前線程不停地執(zhí)行循環(huán)體，不進(jìn)行線程狀態(tài)的改變，所以響應(yīng)速度更快。但當(dāng)線程數(shù)不停增加時(shí)，性能下降明顯，因?yàn)槊總€(gè)線程都需要執(zhí)行，占用CPU時(shí)間。如果線程競(jìng)爭(zhēng)不激烈，并且保持鎖的時(shí)間段。適合使用自旋鎖。
注：該例子為非公平鎖，獲得鎖的先后順序，不會(huì)按照進(jìn)入lock的先后順序進(jìn)行。
?
1.8樂(lè)觀鎖/悲觀鎖:
悲觀鎖：（Pessimistic Lock）它指的是對(duì)數(shù)據(jù)被外界（包括本系統(tǒng)當(dāng)前的其他事務(wù)，以及來(lái)自外部系統(tǒng)的事務(wù)處理）修改持保守態(tài)度。有極強(qiáng)的占有和排他性。整個(gè)過(guò)程，數(shù)據(jù)呈現(xiàn)鎖死狀態(tài)，悲觀鎖一般依靠數(shù)據(jù)庫(kù)的鎖機(jī)制。悲觀的認(rèn)為，不加鎖的并發(fā)操作一定會(huì)出問(wèn)題
樂(lè)觀鎖：（ Optimistic Locking ）因?yàn)楸^鎖往往依靠數(shù)據(jù)庫(kù)的鎖機(jī)制來(lái)實(shí)現(xiàn)，這樣對(duì)數(shù)據(jù)庫(kù)的性能有影響，樂(lè)觀鎖解決了這個(gè)問(wèn)題，通過(guò)數(shù)據(jù)版本機(jī)制來(lái)實(shí)現(xiàn)樂(lè)觀鎖，給數(shù)據(jù)制定一個(gè)版本，讀取數(shù)據(jù)的時(shí)候把版本一起讀出來(lái)，更新數(shù)據(jù)時(shí)，版本號(hào)加1，在提交的時(shí)候，把讀取的版本號(hào)和數(shù)據(jù)庫(kù)當(dāng)前的版本號(hào)進(jìn)行比較，如果提交的版本號(hào)大于數(shù)據(jù)庫(kù)版本號(hào)，則執(zhí)行更新，否則失敗。樂(lè)觀的認(rèn)為，不加鎖的并發(fā)操作是沒(méi)有事情的。
悲觀鎖就是java的鎖機(jī)制，樂(lè)觀鎖就是不加鎖，而通過(guò)CAS算法來(lái)實(shí)現(xiàn)。
java中的樂(lè)觀鎖：通過(guò)CAS來(lái)實(shí)現(xiàn)樂(lè)觀鎖的思想，比如AtomicInteger。當(dāng)多個(gè)線程嘗試使用CAS同時(shí)更新一個(gè)變量時(shí)，只有一個(gè)線程操作能執(zhí)行成功，其他的都執(zhí)行失敗，并且失敗的線程不會(huì)被掛起，并且可以再次嘗試（循環(huán)）。
CAS操作中包含三個(gè)操作數(shù)：
?V：需要讀寫(xiě)的內(nèi)存位置
?A：用于比較的預(yù)期原值，類似數(shù)據(jù)的版本號(hào)。
?B：將被寫(xiě)入的新值
如果V的值與A的值相匹配，那么處理器就會(huì)講該位置更新為B。反之，不做操作。?
CAS缺點(diǎn)：
1.ABA問(wèn)題：線程1讀取值為B，其他線程將A改為B再改為A，那么線程1最后去比較的時(shí)候，是能匹配的，但是其實(shí)值在中途已經(jīng)被其他線程改過(guò)了。通過(guò)每次修改加標(biāo)識(shí)（如版本號(hào)）來(lái)解決，如AtomicStampedReference就是這樣解決的。
2.開(kāi)銷大：因?yàn)榭赡軙?huì)自旋（循環(huán)），所以會(huì)有很大的開(kāi)銷。如果JVM能支持處理器提供的pause指令，那么在效率上會(huì)有一定的提升。
3.只能保證一個(gè)共享變量的原子操作：多個(gè)共享變量就會(huì)出現(xiàn)問(wèn)題。通過(guò)將多個(gè)變量封裝到一個(gè)對(duì)象中來(lái)解決，AtomicReference提供了保證引用對(duì)象之間的原子性。
當(dāng)線程競(jìng)爭(zhēng)少的時(shí)候使用樂(lè)光鎖，當(dāng)線程競(jìng)爭(zhēng)大的時(shí)候就直接使用悲觀鎖。
2.synchronized
多線程訪問(wèn)同步方法的7種情況：
串行執(zhí)行
并行方法，不是一個(gè)對(duì)象。
串行執(zhí)行，只有一個(gè)Class對(duì)象
串行執(zhí)行
串行，this是同一個(gè)
?并行執(zhí)行，鎖對(duì)象不是同一個(gè)
synchronized會(huì)自動(dòng)釋放，Lock等不會(huì)
核心思想
例外：鎖對(duì)象是*.class以及synchronized修飾的是static方法的時(shí)候，所有對(duì)象共用同一把類鎖（對(duì)應(yīng)2、3、4、6種情況）
ps:不能使用string常量，Integer,Long來(lái)做鎖，因?yàn)橹貙?xiě)了equals，雖然連個(gè)字符串相等，但是實(shí)際上不是一個(gè)對(duì)象。要使用的話要使用，string.intern()；
synchronized（"A"）;synchronized（"A"）; 兩個(gè)A雖然相等，但是實(shí)際上是兩個(gè)對(duì)象。
性質(zhì)：
1、可重入：
? 同一個(gè)線程的外層函數(shù)獲取鎖后，內(nèi)層函數(shù)可以直接再次獲取該鎖。
2、不可中斷
原理
1、加鎖和釋放鎖的原理：Monitor
2、可重入原理：加鎖次數(shù)計(jì)數(shù)器。
3、可見(jiàn)性原理：內(nèi)存模型圖
https://www.cnblogs.com/paddix/p/5367116.html
https://www.jianshu.com/p/d53bf830fa09
http://www.importnew.com/21866.html
實(shí)現(xiàn)原理：https://blog.csdn.net/thousa_ho/article/details/77992743
https://ifeve.com/java-synchronized/?tdsourcetag=s_pcqq_aiomsg
缺點(diǎn)
1、效率低
- 鎖的釋放情況少
- 視圖獲取鎖時(shí)不能設(shè)置超時(shí)時(shí)間
- 不能中斷一個(gè)正在視圖獲取鎖的線程
2、靈活度較差
- 加鎖和釋放鎖的時(shí)機(jī)單一
- 每個(gè)鎖僅有單一的對(duì)象
3、無(wú)法知道是否成功獲取到鎖
用法：
對(duì)象鎖：只要多線程訪問(wèn)的是同一個(gè)對(duì)象（new?object（）），就會(huì)有鎖。
類鎖：多線程訪問(wèn)的是對(duì)象屬于同一個(gè)類型，才會(huì)有鎖。
注：無(wú)論synchronized怎么使用（修飾方法或者修飾代碼塊，相同或者不同的方法或者代碼塊）
? ? ? ?只要是對(duì)象鎖，同一個(gè)對(duì)象就會(huì)有鎖；
? ? ? ?只要是類鎖，只要是同一個(gè)類就會(huì)有鎖。
1、synchronized 修飾方法時(shí)?
???a.修飾非靜態(tài)方法時(shí)，鎖住的是對(duì)象
?b.修飾靜態(tài)方法時(shí)，鎖住的是類
2.synchronized修飾代碼塊
a.靜態(tài)方法中的代碼塊，只能synchronized（obj.class）,鎖住類
b.非靜態(tài)方法中的代碼塊，synchronized既可以鎖對(duì)象，也可以是類，如：
synchronized(this)//當(dāng)前對(duì)象
synchronized(obj)//某個(gè)對(duì)象
synchronized(obj.class)//某個(gè)對(duì)象的類型
?注：synchronized關(guān)鍵字不會(huì)被子類繼承，override的時(shí)候，如果沒(méi)有重寫(xiě)則可以繼承，可以通過(guò)子類的鎖調(diào)用父類的加鎖方法。
?
?
注意點(diǎn)
1、鎖對(duì)象不能為空、作用域不宜過(guò)大、避免死鎖
2、盡量使用JUC包下的類，再考慮Synchronized，再考慮Lock
3.Lock
https://www.cnblogs.com/dolphin0520/p/3923167.html
https://www.cnblogs.com/aishangJava/p/6555291.html
ReentrantLock：https://blog.csdn.net/u014730165/article/details/82144848
ReentrantReadWriteLock：https://www.cnblogs.com/zaizhoumo/p/7782941.html
?
AQS:https://www.cnblogs.com/daydaynobug/p/6752837.html
https://blog.csdn.net/zhangdong2012/article/details/79983404
設(shè)計(jì)模式：模板方法
CLH隊(duì)列：雙向鏈表
?
?
?
4.lock和synchronized的區(qū)別
https://www.cnblogs.com/iyyy/p/7993788.html
https://blog.csdn.net/u012403290/article/details/64910926?locationNum=11&fps=1
線程池
1.?線程池的優(yōu)點(diǎn)
- 降低資源的消耗
- 提高響應(yīng)速度，任務(wù)：T1創(chuàng)建線程時(shí)間，T2任務(wù)執(zhí)行時(shí)間，T3線程銷毀時(shí)間，線程池沒(méi)有或者減少T1和T3
- 提高線程的可管理性。
2.?線程池的主要處理流程
1）線程池判斷核心線程池里的線程是否都在執(zhí)行任務(wù)。如果不是，則創(chuàng)建一個(gè)新的工作線程來(lái)執(zhí)行任務(wù)。如果核心線程池里的線程都在執(zhí)行任務(wù)，則進(jìn)入下個(gè)流程。
2）線程池判斷工作隊(duì)列是否已經(jīng)滿。如果工作隊(duì)列沒(méi)有滿，則將新提交的任務(wù)存儲(chǔ)在這個(gè)工作隊(duì)列里。如果工作隊(duì)列滿了，則進(jìn)入下個(gè)流程。
3）線程池判斷線程池的線程是否都處于工作狀態(tài)。如果沒(méi)有，則創(chuàng)建一個(gè)新的工作線程來(lái)執(zhí)行任務(wù)。如果已經(jīng)滿了，則交給飽和策略來(lái)處理這個(gè)任務(wù)。
3.?ThreadPoolExecutor
1）如果當(dāng)前運(yùn)行的線程少于corePoolSize，則創(chuàng)建新線程來(lái)執(zhí)行任務(wù)（注意，執(zhí)行這一步驟需要獲取全局鎖）。
2）如果運(yùn)行的線程等于或多于corePoolSize，則將任務(wù)加入BlockingQueue。
3）如果無(wú)法將任務(wù)加入BlockingQueue（隊(duì)列已滿），則創(chuàng)建新的線程來(lái)處理任務(wù)（注意，執(zhí)行這一步驟需要獲取全局鎖）。
4）如果創(chuàng)建新線程將使當(dāng)前運(yùn)行的線程超出maximumPoolSize，任務(wù)將被拒絕，并調(diào)用RejectedExecutionHandler.rejectedExecution()方法。
public ThreadPoolExecutor(int corePoolSize,int maximumPoolSize,long keepAliveTime,TimeUnit unit,BlockingQueue<Runnable> workQueue,ThreadFactory threadFactory,RejectedExecutionHandler handler)
corePoolSize
線程池中的核心線程數(shù)，當(dāng)提交一個(gè)任務(wù)時(shí)，線程池創(chuàng)建一個(gè)新線程執(zhí)行任務(wù)，直到當(dāng)前線程數(shù)等于corePoolSize；
如果當(dāng)前線程數(shù)為corePoolSize，繼續(xù)提交的任務(wù)被保存到阻塞隊(duì)列中，等待被執(zhí)行；
如果執(zhí)行了線程池的prestartAllCoreThreads()方法，線程池會(huì)提前創(chuàng)建并啟動(dòng)所有核心線程。
maximumPoolSize
線程池中允許的最大線程數(shù)。如果當(dāng)前阻塞隊(duì)列滿了，且繼續(xù)提交任務(wù)，則創(chuàng)建新的線程執(zhí)行任務(wù)，前提是當(dāng)前線程數(shù)小于maximumPoolSize
keepAliveTime
線程空閑時(shí)的存活時(shí)間，即當(dāng)線程沒(méi)有任務(wù)執(zhí)行時(shí)，繼續(xù)存活的時(shí)間。默認(rèn)情況下，該參數(shù)只在線程數(shù)大于corePoolSize時(shí)才有用
TimeUnit
keepAliveTime的時(shí)間單位
workQueue
workQueue必須是BlockingQueue阻塞隊(duì)列。當(dāng)線程池中的線程數(shù)超過(guò)它的corePoolSize的時(shí)候，線程會(huì)進(jìn)入阻塞隊(duì)列進(jìn)行阻塞等待。通過(guò)workQueue，線程池實(shí)現(xiàn)了阻塞功能
threadFactory
創(chuàng)建線程的工廠，通過(guò)自定義的線程工廠可以給每個(gè)新建的線程設(shè)置一個(gè)具有識(shí)別度的線程名
Executors靜態(tài)工廠里默認(rèn)的threadFactory，線程的命名規(guī)則是“pool-數(shù)字-thread-數(shù)字”
RejectedExecutionHandler（飽和策略）
線程池的飽和策略，當(dāng)阻塞隊(duì)列滿了，且沒(méi)有空閑的工作線程，如果繼續(xù)提交任務(wù)，必須采取一種策略處理該任務(wù)，線程池提供了4種策略：
（1）AbortPolicy：直接拋出異常，默認(rèn)策略；
（2）CallerRunsPolicy：用調(diào)用者所在的線程來(lái)執(zhí)行任務(wù)；
（3）DiscardOldestPolicy：丟棄阻塞隊(duì)列中靠最前的任務(wù)，并執(zhí)行當(dāng)前任務(wù)；
（4）DiscardPolicy：直接丟棄任務(wù)；
當(dāng)然也可以根據(jù)應(yīng)用場(chǎng)景實(shí)現(xiàn)RejectedExecutionHandler接口，自定義飽和策略，如記錄日志或持久化存儲(chǔ)不能處理的任務(wù)。
?
關(guān)閉線程池
ShutDown():interrupt方法來(lái)終止線程
shutDownNow() 嘗試停止所有正在執(zhí)行的線程
????? ?
合理地配置線程池
? ? ? ? 線程數(shù)配置：
-
任務(wù)：計(jì)算密集型，IO密集型，混合型
-
計(jì)算密集型=計(jì)算機(jī)的cpu數(shù)或計(jì)算機(jī)的cpu數(shù)+1（應(yīng)付頁(yè)缺失）
-
IO密集型=計(jì)算機(jī)的cpu數(shù)*2
-
混合型，拆分成計(jì)算密集型，IO密集型
-
Runtime.getRuntime().availableProcessors();當(dāng)前機(jī)器中的cpu核心個(gè)數(shù)
-
盡量有界隊(duì)列，不要使用無(wú)界隊(duì)列
?
Executor框架調(diào)度模型：
在HotSpot VM的線程模型中，Java線程（java.lang.Thread）被一對(duì)一映射為本地操作系統(tǒng)線程。Java線程啟動(dòng)時(shí)會(huì)創(chuàng)建一個(gè)本地操作系統(tǒng)線程；當(dāng)該Java線程終止時(shí)，這個(gè)操作系統(tǒng)線程也會(huì)被回收。操作系統(tǒng)會(huì)調(diào)度所有線程并將它們分配給可用的CPU。
在上層，Java多線程程序通常把應(yīng)用分解為若干個(gè)任務(wù)，然后使用用戶級(jí)的調(diào)度器（Executor框架）將這些任務(wù)映射為固定數(shù)量的線程；在底層，操作系統(tǒng)內(nèi)核將這些線程映射到硬件處理器上。
應(yīng)用程序通過(guò)Executor框架控制上層的調(diào)度；而下層的調(diào)度由操作系統(tǒng)內(nèi)核控制，下層的調(diào)度不受應(yīng)用程序的控制。
?
?
三大組成部分：任務(wù)，任務(wù)的執(zhí)行，異步計(jì)算的結(jié)果
????????
任務(wù)
包括被執(zhí)行任務(wù)需要實(shí)現(xiàn)的接口：Runnable接口或Callable接口。
任務(wù)的執(zhí)行
包括任務(wù)執(zhí)行機(jī)制的核心接口Executor，以及繼承自Executor的ExecutorService接口。Executor框架有兩個(gè)關(guān)鍵類實(shí)現(xiàn)了ExecutorService接口（ThreadPoolExecutor和ScheduledThreadPoolExecutor）。
異步計(jì)算的結(jié)果
包括接口Future和實(shí)現(xiàn)Future接口的FutureTask類。
成員結(jié)構(gòu)
Executor是一個(gè)接口，它是Executor框架的基礎(chǔ)，它將任務(wù)的提交與任務(wù)的執(zhí)行分離開(kāi)來(lái)。
ExecutorService接口繼承了Executor，在其上做了一些shutdown()、submit()的擴(kuò)展，可以說(shuō)是真正的線程池接口；
AbstractExecutorService抽象類實(shí)現(xiàn)了ExecutorService接口中的大部分方法；
ThreadPoolExecutor是線程池的核心實(shí)現(xiàn)類，用來(lái)執(zhí)行被提交的任務(wù)。
ScheduledExecutorService接口繼承了ExecutorService接口，提供了帶"周期執(zhí)行"功能ExecutorService；
ScheduledThreadPoolExecutor是一個(gè)實(shí)現(xiàn)類，可以在給定的延遲后運(yùn)行命令，或者定期執(zhí)行命令。ScheduledThreadPoolExecutor比Timer更靈活，功能更強(qiáng)大。
Future接口和實(shí)現(xiàn)Future接口的FutureTask類，代表異步計(jì)算的結(jié)果。
Runnable接口和Callable接口的實(shí)現(xiàn)類，都可以被ThreadPoolExecutor或Scheduled-ThreadPoolExecutor執(zhí)行。
Executor框架基本使用流程
主線程首先要?jiǎng)?chuàng)建實(shí)現(xiàn)Runnable或者Callable接口的任務(wù)對(duì)象。
工具類Executors可以把一個(gè)Runnable對(duì)象封裝為一個(gè)Callable對(duì)象（Executors.callable（Runnable task）或Executors.callable（Runnable task，Object resule））。然后可以把Runnable對(duì)象直接交給ExecutorService執(zhí)行（ExecutorService.execute（Runnablecommand））；或者也可以把Runnable對(duì)象或Callable對(duì)象提交給ExecutorService執(zhí)行（Executor-Service.submit（Runnable task）或ExecutorService.submit（Callable<T>task））。
如果執(zhí)行ExecutorService.submit（…），ExecutorService將返回一個(gè)實(shí)現(xiàn)Future接口的對(duì)象（到目前為止的JDK中，返回的是FutureTask對(duì)象）。由于FutureTask實(shí)現(xiàn)了Runnable，程序員也可以創(chuàng)建FutureTask，然后直接交給ExecutorService執(zhí)行。
最后，主線程可以執(zhí)行FutureTask.get()方法來(lái)等待任務(wù)執(zhí)行完成。主線程也可以執(zhí)行FutureTask.cancel（boolean mayInterruptIfRunning）來(lái)取消此任務(wù)的執(zhí)行。
?
ThreadPoolExecutor通常使用工廠類Executors來(lái)創(chuàng)建。Executors可以創(chuàng)建3種類型的ThreadPoolExecutor：SingleThreadExecutor、FixedThreadPool和CachedThreadPool。
FixedThreadPool
創(chuàng)建使用固定線程數(shù)的FixedThreadPool的API。適用于為了滿足資源管理的需求，而需要限制當(dāng)前線程數(shù)量的應(yīng)用場(chǎng)景，適用于負(fù)載比較重的服務(wù)器。FixedThreadPool的corePoolSize和maximumPoolSize都被設(shè)置為創(chuàng)建FixedThreadPool時(shí)指定的參數(shù)nThreads。
當(dāng)線程池中的線程數(shù)大于corePoolSize時(shí)，keepAliveTime為多余的空閑線程等待新任務(wù)的最長(zhǎng)時(shí)間，超過(guò)這個(gè)時(shí)間后多余的線程將被終止。這里把keepAliveTime設(shè)置為0L，意味著多余的空閑線程會(huì)被立即終止。
FixedThreadPool使用無(wú)界隊(duì)列LinkedBlockingQueue作為線程池的工作隊(duì)列（隊(duì)列的容量為Integer.MAX_VALUE）。使用無(wú)界隊(duì)列作為工作隊(duì)列會(huì)對(duì)線程池帶來(lái)如下影響。
1）當(dāng)線程池中的線程數(shù)達(dá)到corePoolSize后，新任務(wù)將在無(wú)界隊(duì)列中等待，因此線程池中的線程數(shù)不會(huì)超過(guò)corePoolSize。
2）由于1，使用無(wú)界隊(duì)列時(shí)maximumPoolSize將是一個(gè)無(wú)效參數(shù)。
3）由于1和2，使用無(wú)界隊(duì)列時(shí)keepAliveTime將是一個(gè)無(wú)效參數(shù)。
4）由于使用無(wú)界隊(duì)列，運(yùn)行中的FixedThreadPool（未執(zhí)行方法shutdown()或
shutdownNow()）不會(huì)拒絕任務(wù)（不會(huì)調(diào)用RejectedExecutionHandler.rejectedExecution方法）。
SingleThreadExecutor
創(chuàng)建使用單個(gè)線程的SingleThread-Executor的API，適用于需要保證順序地執(zhí)行各個(gè)任務(wù)；并且在任意時(shí)間點(diǎn)，不會(huì)有多個(gè)線程是活動(dòng)的應(yīng)用場(chǎng)景。
corePoolSize和maximumPoolSize被設(shè)置為1。其他參數(shù)與FixedThreadPool相同。SingleThreadExecutor使用無(wú)界隊(duì)列LinkedBlockingQueue作為線程池的工作隊(duì)列（隊(duì)列的容量為Integer.MAX_VALUE）。
CachedThreadPool
創(chuàng)建一個(gè)會(huì)根據(jù)需要?jiǎng)?chuàng)建新線程的CachedThreadPool的API。大小無(wú)界的線程池，適用于執(zhí)行很多的短期異步任務(wù)的小程序，或者是負(fù)載較輕的服務(wù)器。
corePoolSize被設(shè)置為0，即corePool為空；maximumPoolSize被設(shè)置為Integer.MAX_VALUE，即maximumPool是無(wú)界的。這里把keepAliveTime設(shè)置為60L，意味著CachedThreadPool中的空閑線程等待新任務(wù)的最長(zhǎng)時(shí)間為60秒，空閑線程超過(guò)60秒后將會(huì)被終止。
FixedThreadPool和SingleThreadExecutor使用無(wú)界隊(duì)列LinkedBlockingQueue作為線程池的工作隊(duì)列。CachedThreadPool使用沒(méi)有容量的SynchronousQueue作為線程池的工作隊(duì)列，但CachedThreadPool的maximumPool是無(wú)界的。這意味著，如果主線程提交任務(wù)的速度高于maximumPool中線程處理任務(wù)的速度時(shí)，CachedThreadPool會(huì)不斷創(chuàng)建新線程。極端情況下，CachedThreadPool會(huì)因?yàn)閯?chuàng)建過(guò)多線程而耗盡CPU和內(nèi)存資源。
WorkStealingPool
利用所有運(yùn)行的處理器數(shù)目來(lái)創(chuàng)建一個(gè)工作竊取的線程池，使用forkjoin實(shí)現(xiàn)。
ScheduledThreadPoolExecutor
使用工廠類Executors來(lái)創(chuàng)建。Executors可以創(chuàng)建2種類
型的ScheduledThreadPoolExecutor，如下。
·ScheduledThreadPoolExecutor。包含若干個(gè)線程的ScheduledThreadPoolExecutor。
·SingleThreadScheduledExecutor。只包含一個(gè)線程的ScheduledThreadPoolExecutor。
ScheduledThreadPoolExecutor適用于需要多個(gè)后臺(tái)線程執(zhí)行周期任務(wù)，同時(shí)為了滿足資源管理的需求而需要限制后臺(tái)線程的數(shù)量的應(yīng)用場(chǎng)景。
SingleThreadScheduledExecutor適用于需要單個(gè)后臺(tái)線程執(zhí)行周期任務(wù)，同時(shí)需要保證順序地執(zhí)行各個(gè)任務(wù)的應(yīng)用場(chǎng)景。
?
對(duì)這4個(gè)步驟的說(shuō)明。
1）線程1從DelayQueue中獲取已到期的ScheduledFutureTask（DelayQueue.take()）。到期任務(wù)是指ScheduledFutureTask的time大于等于當(dāng)前時(shí)間。
2）線程1執(zhí)行這個(gè)ScheduledFutureTask。
3）線程1修改ScheduledFutureTask的time變量為下次將要被執(zhí)行的時(shí)間。
4）線程1把這個(gè)修改time之后的ScheduledFutureTask放回DelayQueue中（Delay-
Queue.add()）。
有關(guān)提交定時(shí)任務(wù)的四個(gè)方法：
//向定時(shí)任務(wù)線程池提交一個(gè)延時(shí)Runnable任務(wù)（僅執(zhí)行一次）
public?ScheduledFuture<?> schedule(Runnable command, long?delay, TimeUnit unit)
?
//向定時(shí)任務(wù)線程池提交一個(gè)延時(shí)的Callable任務(wù)（僅執(zhí)行一次）
public?<V> ScheduledFuture<V> schedule(Callable<V> callable, long?delay, TimeUnit unit);
?
//向定時(shí)任務(wù)線程池提交一個(gè)固定時(shí)間間隔執(zhí)行的任務(wù)
public?ScheduledFuture<?> scheduleAtFixedRate(Runnable command, long?initialDelay,
??????????????????????????????????????????????????long?period, TimeUnit unit)
?
//向定時(shí)任務(wù)線程池提交一個(gè)固定延時(shí)間隔執(zhí)行的任務(wù)
public?ScheduledFuture<?> scheduleWithFixedDelay(Runnable command, long?initialDelay,
??????????????????????????????????????????????????????long?delay, TimeUnit unit);
固定時(shí)間間隔的任務(wù)不論每次任務(wù)花費(fèi)多少時(shí)間，下次任務(wù)開(kāi)始執(zhí)行時(shí)間是確定的，當(dāng)然執(zhí)行任務(wù)的時(shí)間不能超過(guò)執(zhí)行周期。
固定延時(shí)間隔的任務(wù)是指每次執(zhí)行完任務(wù)以后都延時(shí)一個(gè)固定的時(shí)間。由于操作系統(tǒng)調(diào)度以及每次任務(wù)執(zhí)行的語(yǔ)句可能不同，所以每次任務(wù)執(zhí)行所花費(fèi)的時(shí)間是不確定的，也就導(dǎo)致了每次任務(wù)的執(zhí)行周期存在一定的波動(dòng)。
注意：定時(shí)或延時(shí)任務(wù)中所涉及到時(shí)間、周期不能保證實(shí)時(shí)性及準(zhǔn)確性，實(shí)際運(yùn)行中會(huì)有一定的誤差。
ScheduleThreadPoolExecutor與Timer相比的優(yōu)勢(shì):
（1）Timer是基于絕對(duì)時(shí)間的延時(shí)執(zhí)行或周期執(zhí)行，當(dāng)系統(tǒng)時(shí)間改變，則任務(wù)的執(zhí)行會(huì)受到的影響。而ScheduleThreadPoolExecutore中，任務(wù)時(shí)基于相對(duì)時(shí)間進(jìn)行周期或延時(shí)操作。
（2）Timer也可以提交多個(gè)TimeTask任務(wù)，但只有一個(gè)線程來(lái)執(zhí)行所有的TimeTask，這樣并發(fā)性受到影響。而ScheduleThreadPoolExecutore可以設(shè)定池中線程的數(shù)量。
（3）Timer不會(huì)捕獲TimerTask的異常，只是簡(jiǎn)單地停止，這樣勢(shì)必會(huì)影響其他TimeTask的執(zhí)行。而ScheduleThreadPoolExecutore中，如果一個(gè)線程因某些原因停止，線程池可以自動(dòng)創(chuàng)建新的線程來(lái)維護(hù)池中線程的數(shù)量。
scheduleAtFixedRate定時(shí)任務(wù)超時(shí)問(wèn)題
若任務(wù)處理時(shí)長(zhǎng)超出設(shè)置的定時(shí)頻率時(shí)長(zhǎng),本次任務(wù)執(zhí)行完才開(kāi)始下次任務(wù),下次任務(wù)已經(jīng)處于超時(shí)狀態(tài),會(huì)馬上開(kāi)始執(zhí)行.
若任務(wù)處理時(shí)長(zhǎng)小于定時(shí)頻率時(shí)長(zhǎng),任務(wù)執(zhí)行完后,定時(shí)器等待,下次任務(wù)會(huì)在定時(shí)器等待頻率時(shí)長(zhǎng)后執(zhí)行
如下例子:
設(shè)置定時(shí)任務(wù)每60s執(zhí)行一次
若第一次任務(wù)時(shí)長(zhǎng)80s,第二次任務(wù)時(shí)長(zhǎng)20ms,第三次任務(wù)時(shí)長(zhǎng)50ms
第一次任務(wù)第0s開(kāi)始,第80s結(jié)束;
第二次任務(wù)第80s開(kāi)始,第110s結(jié)束;(上次任務(wù)已超時(shí),本次不會(huì)再等待60s,會(huì)馬上開(kāi)始),
第三次任務(wù)第150s開(kāi)始,第200s結(jié)束.
第四次任務(wù)第210s開(kāi)始.....
?
Callable、Future和FutureTask詳解
Future接口和實(shí)現(xiàn)Future接口的FutureTask類用來(lái)表示異步計(jì)算的結(jié)果。
當(dāng)我們把Runnable接口或Callable接口的實(shí)現(xiàn)類提交（submit）給ThreadPoolExecutor或ScheduledThreadPoolExecutor時(shí)，ThreadPoolExecutor或ScheduledThreadPoolExecutor會(huì)向我們返回一個(gè)FutureTask對(duì)象。
Runnable接口和Callable接口的實(shí)現(xiàn)類，都可以被ThreadPoolExecutor或Scheduled-ThreadPoolExecutor執(zhí)行。它們之間的區(qū)別是Runnable不會(huì)返回結(jié)果，而Callable可以返回結(jié)果。
除了可以自己創(chuàng)建實(shí)現(xiàn)Callable接口的對(duì)象外，還可以使用工廠類Executors來(lái)把一個(gè)Runnable包裝成一個(gè)Callable。
Executors提供的，把一個(gè)Runnable包裝成一個(gè)Callable的API。
public static Callable<Object> callable(Runnable task)? // 假設(shè)返回對(duì)象Callable1
Executors提供的，把一個(gè)Runnable和一個(gè)待返回的結(jié)果包裝成一個(gè)Callable的API。
public static <T> Callable<T> callable(Runnable task, T result)? // 假設(shè)返回對(duì)象Callable2
當(dāng)任務(wù)成功完成后FutureTask.get()將返回該任務(wù)的結(jié)果。例如，如果提交的是對(duì)象Callable1，FutureTask.get()方法將返回null；如果提交的是對(duì)象Callable2，FutureTask.get()方法將返回result對(duì)象。
FutureTask除了實(shí)現(xiàn)Future接口外，還實(shí)現(xiàn)了Runnable接口。因此，FutureTask可以交給Executor執(zhí)行，也可以由調(diào)用線程直接執(zhí)行（FutureTask.run()）。
當(dāng)FutureTask處于未啟動(dòng)或已啟動(dòng)狀態(tài)時(shí)，執(zhí)行FutureTask.get()方法將導(dǎo)致調(diào)用線程阻塞；當(dāng)FutureTask處于已完成狀態(tài)時(shí)，執(zhí)行FutureTask.get()方法將導(dǎo)致調(diào)用線程立即返回結(jié)果或拋出異常。
當(dāng)FutureTask處于未啟動(dòng)狀態(tài)時(shí)，執(zhí)行FutureTask.cancel()方法將導(dǎo)致此任務(wù)永遠(yuǎn)不會(huì)被執(zhí)行；當(dāng)FutureTask處于已啟動(dòng)狀態(tài)時(shí)，執(zhí)行FutureTask.cancel（true）方法將以中斷執(zhí)行此任務(wù)線程的方式來(lái)試圖停止任務(wù)；當(dāng)FutureTask處于已啟動(dòng)狀態(tài)時(shí)，執(zhí)行FutureTask.cancel（false）方法將不會(huì)對(duì)正在執(zhí)行此任務(wù)的線程產(chǎn)生影響（讓正在執(zhí)行的任務(wù)運(yùn)行完成）；當(dāng)FutureTask處于已完成狀態(tài)時(shí)，執(zhí)行FutureTask.cancel（…）方法將返回false。
CompletionService詳解
CompletionService實(shí)際上可以看做是Executor和BlockingQueue的結(jié)合體。CompletionService在接收到要執(zhí)行的任務(wù)時(shí)，通過(guò)類似BlockingQueue的put和take獲得任務(wù)執(zhí)行的結(jié)果。CompletionService的一個(gè)實(shí)現(xiàn)是ExecutorCompletionService，ExecutorCompletionService把具體的計(jì)算任務(wù)交給Executor完成。在實(shí)現(xiàn)上，ExecutorCompletionService在構(gòu)造函數(shù)中會(huì)創(chuàng)建一個(gè)BlockingQueue（使用的基于鏈表的無(wú)界隊(duì)列LinkedBlockingQueue），該BlockingQueue的作用是保存Executor執(zhí)行的結(jié)果。當(dāng)計(jì)算完成時(shí)，調(diào)用FutureTask的done方法。當(dāng)提交一個(gè)任務(wù)到ExecutorCompletionService時(shí)，首先將任務(wù)包裝成QueueingFuture，它是FutureTask的一個(gè)子類，然后改寫(xiě)FutureTask的done方法，之后把Executor執(zhí)行的計(jì)算結(jié)果放入BlockingQueue中。
與ExecutorService最主要的區(qū)別在于submit的task不一定是按照加入時(shí)的順序完成的。CompletionService對(duì)ExecutorService進(jìn)行了包裝，內(nèi)部維護(hù)一個(gè)保存Future對(duì)象的BlockingQueue。只有當(dāng)這個(gè)Future對(duì)象狀態(tài)是結(jié)束的時(shí)候，才會(huì)加入到這個(gè)Queue中，take()方法其實(shí)就是Producer-Consumer中的Consumer。它會(huì)從Queue中取出Future對(duì)象，如果Queue是空的，就會(huì)阻塞在那里，直到有完成的Future對(duì)象加入到Queue中。所以，先完成的必定先被取出。這樣就減少了不必要的等待時(shí)間。
總結(jié)：
使用方法一，自己創(chuàng)建一個(gè)集合來(lái)保存Future存根并循環(huán)調(diào)用其返回結(jié)果的時(shí)候，主線程并不能保證首先獲得的是最先完成任務(wù)的線程返回值。它只是按加入線程池的順序返回。因?yàn)閠ake方法是阻塞方法，后面的任務(wù)完成了，前面的任務(wù)卻沒(méi)有完成，主程序就那樣等待在那兒，只到前面的完成了，它才知道原來(lái)后面的也完成了。
使用方法二，使用CompletionService來(lái)維護(hù)處理線程不的返回結(jié)果時(shí)，主線程總是能夠拿到最先完成的任務(wù)的返回值，而不管它們加入線程池的順序。
?
?
減少鎖的競(jìng)爭(zhēng):
快進(jìn)快出，縮小鎖的范圍，將與鎖無(wú)關(guān)的，有大量計(jì)算或者阻塞操作的代碼移出同步范圍。
減小鎖的粒度，多個(gè)相互獨(dú)立的狀態(tài)變量可以使用多個(gè)鎖來(lái)保護(hù)，每個(gè)鎖只保護(hù)一個(gè)變量。
鎖的分段，例如ConcurrentHashMap中的實(shí)現(xiàn)。
減少獨(dú)占鎖的使用，例如讀多寫(xiě)少的情況下，用讀寫(xiě)鎖替換排他鎖。
?
?
底層實(shí)現(xiàn)原理和JMM
?
?
?
CountDownLatch
是一個(gè)同步工具類，用來(lái)協(xié)調(diào)多個(gè)線程之間的同步。
CountDownLatch countDownLatch = new CountDownLatch(N);
當(dāng)線程1.執(zhí)行countDownLatch.await();方法后，進(jìn)入等待（等同wait()），當(dāng)其他線程執(zhí)行N次countDownLatch..countDown();之后，才會(huì)被喚醒。?
內(nèi)部實(shí)現(xiàn)： AQS。
ps:只能在初始化的時(shí)候，定義N。并且只能使用一次。
?
CyclicBarrier：循環(huán)柵欄
讓所有線程都等待完成后才會(huì)繼續(xù)下一步行動(dòng)。等到一批數(shù)量集合完成之后，再進(jìn)行下一步。
CyclicBarrier 的字面意思是可循環(huán)使用（Cyclic）的屏障（Barrier）。它要做的事情是，讓一組線程到達(dá)一個(gè)屏障（也可以叫同步點(diǎn)）時(shí)被阻塞，直到最后一個(gè)線程到達(dá)屏障時(shí)，屏障才會(huì)開(kāi)門(mén)，所有被屏障攔截的線程才會(huì)繼續(xù)干活。CyclicBarrier默認(rèn)的構(gòu)造方法是CyclicBarrier(int parties)，其參數(shù)表示屏障攔截的線程數(shù)量，每個(gè)線程調(diào)用await方法告訴CyclicBarrier我已經(jīng)到達(dá)了屏障，然后當(dāng)前線程被阻塞。?
await();進(jìn)入等待，當(dāng)?shù)却木€程數(shù)量達(dá)到指定的數(shù)量，就會(huì)被喚醒，繼續(xù)執(zhí)行。
?
Semaphore ：信號(hào)量
基于AQS實(shí)現(xiàn)的。內(nèi)部也定義了一個(gè)Sync ，AQS的實(shí)現(xiàn)類
?
LockSupport：
LockSupport是一個(gè)線程工具類，所有的方法都是靜態(tài)方法，可以讓線程在任意位置阻塞，也可以在任意位置喚醒。
主要的方法：park（阻塞線程）和unpark（喚醒線程）。
（1）wait和notify都是Object中的方法,在調(diào)用這兩個(gè)方法前必須先獲得鎖對(duì)象，但是park不需要獲取某個(gè)對(duì)象的鎖就可以鎖住線程。
（2）notify只能隨機(jī)選擇一個(gè)線程喚醒，無(wú)法喚醒指定的線程，unpark卻可以喚醒一個(gè)指定的線程。unpark可以先執(zhí)行，則park不阻塞。
public static void park(Object blocker); // 暫停當(dāng)前線程 public static void parkNanos(Object blocker, long nanos); // 暫停當(dāng)前線程，不過(guò)有超時(shí)時(shí)間的限制 public static void parkUntil(Object blocker, long deadline); // 暫停當(dāng)前線程，直到某個(gè)時(shí)間 public static void park(); // 無(wú)期限暫停當(dāng)前線程 public static void parkNanos(long nanos); // 暫停當(dāng)前線程，不過(guò)有超時(shí)時(shí)間的限制 public static void parkUntil(long deadline); // 暫停當(dāng)前線程，直到某個(gè)時(shí)間 public static void unpark(Thread thread); // 恢復(fù)當(dāng)前線程 public static Object getBlocker(Thread t);?
總結(jié)
以上是生活随笔為你收集整理的java多线程学习笔记。的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 荧光染料 ICG-HSA 吲哚菁绿修饰人
- 下一篇： Win10下双系统Ubuntu14.04