說說進程和線程的區(qū)別鸠天？

進程是程序的一次執(zhí)行讼育，是系統(tǒng)進行資源分配和調(diào)度的獨立單位，他的作用是是程序能夠并發(fā)執(zhí)行提高資源利用率和吞吐率稠集。

由于進程是資源分配和調(diào)度的基本單位奶段，因為進程的創(chuàng)建、銷毀剥纷、切換產(chǎn)生大量的時間和空間的開銷痹籍，進程的數(shù)量不能太多，而線程是比進程更小的能獨立運行的基本單位晦鞋，他是進程的一個實體蹲缠，可以減少程序并發(fā)執(zhí)行時的時間和空間開銷刺洒，使得操作系統(tǒng)具有更好的并發(fā)性。

線程基本不擁有系統(tǒng)資源吼砂，只有一些運行時必不可少的資源逆航，比如程序計數(shù)器、寄存器和棧渔肩，進程則占有堆因俐、棧。

知道synchronized原理嗎周偎？

synchronized是java提供的原子性內(nèi)置鎖抹剩，這種內(nèi)置的并且使用者看不到的鎖也被稱為監(jiān)視器鎖，使用synchronized之后蓉坎，會在編譯之后在同步的代碼塊前后加上monitorenter和monitorexit字節(jié)碼指令澳眷，他依賴操作系統(tǒng)底層互斥鎖實現(xiàn)。他的作用主要就是實現(xiàn)原子性操作和解決共享變量的內(nèi)存可見性問題蛉艾。

執(zhí)行monitorenter指令時會嘗試獲取對象鎖钳踊，如果對象沒有被鎖定或者已經(jīng)獲得了鎖，鎖的計數(shù)器+1勿侯。此時其他競爭鎖的線程則會進入等待隊列中拓瞪。

執(zhí)行monitorexit指令時則會把計數(shù)器-1，當計數(shù)器值為0時助琐，則鎖釋放祭埂，處于等待隊列中的線程再繼續(xù)競爭鎖。

synchronized是排它鎖兵钮，當一個線程獲得鎖之后蛆橡，其他線程必須等待該線程釋放鎖后才能獲得鎖，而且由于Java中的線程和操作系統(tǒng)原生線程是一一對應的掘譬，線程被阻塞或者喚醒時時會從用戶態(tài)切換到內(nèi)核態(tài)泰演，這種轉(zhuǎn)換非常消耗性能。

從內(nèi)存語義來說屁药，加鎖的過程會清除工作內(nèi)存中的共享變量粥血，再從主內(nèi)存讀取，而釋放鎖的過程則是將工作內(nèi)存中的共享變量寫回主內(nèi)存酿箭。

實際上大部分時候我認為說到monitorenter就行了复亏，但是為了更清楚的描述，還是再具體一點缭嫡。

如果再深入到源碼來說缔御，synchronized實際上有兩個隊列waitSet和entryList。

1. 當多個線程進入同步代碼塊時妇蛀，首先進入entryList
2. 有一個線程獲取到monitor鎖后耕突，就賦值給當前線程笤成，并且計數(shù)器+1
3. 如果線程調(diào)用wait方法，將釋放鎖眷茁，當前線程置為null炕泳，計數(shù)器-1，同時進入waitSet等待被喚醒上祈，調(diào)用notify或者notifyAll之后又會進入entryList競爭鎖

4. 如果線程執(zhí)行完畢培遵，同樣釋放鎖，計數(shù)器-1登刺，當前線程置為null

   
   

那鎖的優(yōu)化機制了解嗎籽腕？

從JDK1.6版本之后，synchronized本身也在不斷優(yōu)化鎖的機制纸俭，有些情況下他并不會是一個很重量級的鎖了皇耗。優(yōu)化機制包括自適應鎖、自旋鎖揍很、鎖消除郎楼、鎖粗化、輕量級鎖和偏向鎖女轿。

鎖的狀態(tài)從低到高依次為無鎖->偏向鎖->輕量級鎖->重量級鎖箭启，升級的過程就是從低到高，降級在一定條件也是有可能發(fā)生的蛉迹。

自旋鎖：由于大部分時候，鎖被占用的時間很短放妈，共享變量的鎖定時間也很短北救，所有沒有必要掛起線程，用戶態(tài)和內(nèi)核態(tài)的來回上下文切換嚴重影響性能芜抒。自旋的概念就是讓線程執(zhí)行一個忙循環(huán)珍策，可以理解為就是啥也不干，防止從用戶態(tài)轉(zhuǎn)入內(nèi)核態(tài)宅倒，自旋鎖可以通過設置-XX:+UseSpining來開啟攘宙，自旋的默認次數(shù)是10次，可以使用-XX:PreBlockSpin設置拐迁。

自適應鎖：自適應鎖就是自適應的自旋鎖蹭劈，自旋的時間不是固定時間，而是由前一次在同一個鎖上的自旋時間和鎖的持有者狀態(tài)來決定线召。

鎖消除：鎖消除指的是JVM檢測到一些同步的代碼塊铺韧，完全不存在數(shù)據(jù)競爭的場景，也就是不需要加鎖缓淹，就會進行鎖消除哈打。

鎖粗化：鎖粗化指的是有很多操作都是對同一個對象進行加鎖塔逃，就會把鎖的同步范圍擴展到整個操作序列之外。

偏向鎖：當線程訪問同步塊獲取鎖時料仗，會在對象頭和棧幀中的鎖記錄里存儲偏向鎖的線程ID湾盗，之后這個線程再次進入同步塊時都不需要CAS來加鎖和解鎖了，偏向鎖會永遠偏向第一個獲得鎖的線程立轧，如果后續(xù)沒有其他線程獲得過這個鎖淹仑，持有鎖的線程就永遠不需要進行同步，反之肺孵，當有其他線程競爭偏向鎖時匀借，持有偏向鎖的線程就會釋放偏向鎖∑骄剑可以用過設置-XX:+UseBiasedLocking開啟偏向鎖吓肋。

輕量級鎖：JVM的對象的對象頭中包含有一些鎖的標志位，代碼進入同步塊的時候瑰艘，JVM將會使用CAS方式來嘗試獲取鎖是鬼，如果更新成功則會把對象頭中的狀態(tài)位標記為輕量級鎖，如果更新失敗紫新，當前線程就嘗試自旋來獲得鎖均蜜。

整個鎖升級的過程非常復雜，我盡力去除一些無用的環(huán)節(jié)芒率，簡單來描述整個升級的機制囤耳。

簡單點說，偏向鎖就是通過對象頭的偏向線程ID來對比偶芍，甚至都不需要CAS了充择，而輕量級鎖主要就是通過CAS修改對象頭鎖記錄和自旋來實現(xiàn)，重量級鎖則是除了擁有鎖的線程其他全部阻塞匪蟀。

那對象頭具體都包含哪些內(nèi)容椎麦？

在我們常用的Hotspot虛擬機中封救，對象在內(nèi)存中布局實際包含3個部分：

1. 對象頭
2. 實例數(shù)據(jù)
3. 對齊填充

而對象頭包含兩部分內(nèi)容茅坛，Mark Word中的內(nèi)容會隨著鎖標志位而發(fā)生變化，所以只說存儲結(jié)構(gòu)就好了役衡。

1. 對象自身運行時所需的數(shù)據(jù)段化，也被稱為Mark Word嘁捷，也就是用于輕量級鎖和偏向鎖的關鍵點。具體的內(nèi)容包含對象的hashcode穗泵、分代年齡普气、輕量級鎖指針、重量級鎖指針佃延、GC標記现诀、偏向鎖線程ID夷磕、偏向鎖時間戳。

2. 存儲類型指針仔沿，也就是指向類的元數(shù)據(jù)的指針坐桩，通過這個指針才能確定對象是屬于哪個類的實例。 如果是數(shù)組的話封锉，則還包含了數(shù)組的長度

   
   

對于加鎖绵跷，那再說下ReentrantLock原理？他和synchronized有什么區(qū)別成福？

相比于synchronized碾局，ReentrantLock需要顯式的獲取鎖和釋放鎖，相對現(xiàn)在基本都是用JDK7和JDK8的版本奴艾，ReentrantLock的效率和synchronized區(qū)別基本可以持平了净当。他們的主要區(qū)別有以下幾點：

1. 等待可中斷，當持有鎖的線程長時間不釋放鎖的時候蕴潦，等待中的線程可以選擇放棄等待像啼，轉(zhuǎn)而處理其他的任務。
2. 公平鎖：synchronized和ReentrantLock默認都是非公平鎖潭苞，但是ReentrantLock可以通過構(gòu)造函數(shù)傳參改變忽冻。只不過使用公平鎖的話會導致性能急劇下降。
3. 綁定多個條件：ReentrantLock可以同時綁定多個Condition條件對象此疹。

ReentrantLock基于AQS(AbstractQueuedSynchronizer 抽象隊列同步器)實現(xiàn)僧诚。別說了，我知道問題了秀菱，AQS原理我來講振诬。

AQS內(nèi)部維護一個state狀態(tài)位，嘗試加鎖的時候通過CAS(CompareAndSwap)修改值衍菱，如果成功設置為1，并且把當前線程ID賦值肩豁，則代表加鎖成功脊串，一旦獲取到鎖，其他的線程將會被阻塞進入阻塞隊列自旋清钥，獲得鎖的線程釋放鎖的時候?qū)拘炎枞犃兄械木€程琼锋，釋放鎖的時候則會把state重新置為0，同時當前線程ID置為空祟昭。

CAS的原理呢缕坎？

CAS叫做CompareAndSwap，比較并交換篡悟，主要是通過處理器的指令來保證操作的原子性谜叹，它包含三個操作數(shù)：

1. 變量內(nèi)存地址匾寝，V表示
2. 舊的預期值，A表示
3. 準備設置的新值荷腊，B表示

當執(zhí)行CAS指令時艳悔，只有當V等于A時，才會用B去更新V的值女仰，否則就不會執(zhí)行更新操作猜年。

那么CAS有什么缺點嗎？

CAS的缺點主要有3點：

ABA問題：ABA的問題指的是在CAS更新的過程中疾忍，當讀取到的值是A乔外，然后準備賦值的時候仍然是A，但是實際上有可能A的值被改成了B一罩，然后又被改回了A杨幼，這個CAS更新的漏洞就叫做ABA。只是ABA的問題大部分場景下都不影響并發(fā)的最終效果擒抛。

Java中有AtomicStampedReference來解決這個問題推汽，他加入了預期標志和更新后標志兩個字段，更新時不光檢查值歧沪，還要檢查當前的標志是否等于預期標志歹撒，全部相等的話才會更新。

循環(huán)時間長開銷大：自旋CAS的方式如果長時間不成功诊胞，會給CPU帶來很大的開銷暖夭。

只能保證一個共享變量的原子操作：只對一個共享變量操作可以保證原子性，但是多個則不行撵孤，多個可以通過AtomicReference來處理或者使用鎖synchronized實現(xiàn)迈着。

好，說說HashMap原理吧邪码？

HashMap主要由數(shù)組和鏈表組成裕菠，他不是線程安全的。核心的點就是put插入數(shù)據(jù)的過程闭专，get查詢數(shù)據(jù)以及擴容的方式奴潘。JDK1.7和1.8的主要區(qū)別在于頭插和尾插方式的修改，頭插容易導致HashMap鏈表死循環(huán)影钉，并且1.8之后加入紅黑樹對性能有提升画髓。

put插入數(shù)據(jù)流程

往map插入元素的時候首先通過對key hash然后與數(shù)組長度-1進行與運算((n-1)&hash)，都是2的次冪所以等同于取模平委，但是位運算的效率更高奈虾。找到數(shù)組中的位置之后，如果數(shù)組中沒有元素直接存入，反之則判斷key是否相同肉微，key相同就覆蓋匾鸥，否則就會插入到鏈表的尾部，如果鏈表的長度超過8浪册，則會轉(zhuǎn)換成紅黑樹扫腺，最后判斷數(shù)組長度是否超過默認的長度*負載因子也就是12，超過則進行擴容村象。

get查詢數(shù)據(jù)

查詢數(shù)據(jù)相對來說就比較簡單了笆环，首先計算出hash值，然后去數(shù)組查詢厚者，是紅黑樹就去紅黑樹查躁劣，鏈表就遍歷鏈表查詢就可以了。

resize擴容過程

擴容的過程就是對key重新計算hash库菲，然后把數(shù)據(jù)拷貝到新的數(shù)組账忘。

那多線程環(huán)境怎么使用Map呢？ConcurrentHashmap了解過嗎熙宇？

多線程環(huán)境可以使用Collections.synchronizedMap同步加鎖的方式鳖擒，還可以使用HashTable，但是同步的方式顯然性能不達標烫止，而ConurrentHashMap更適合高并發(fā)場景使用蒋荚。

ConcurrentHashmap在JDK1.7和1.8的版本改動比較大，1.7使用Segment+HashEntry分段鎖的方式實現(xiàn)馆蠕，1.8則拋棄了Segment期升，改為使用CAS+synchronized+Node實現(xiàn)，同樣也加入了紅黑樹互躬，避免鏈表過長導致性能的問題播赁。

1.7分段鎖

從結(jié)構(gòu)上說，1.7版本的ConcurrentHashMap采用分段鎖機制吼渡，里面包含一個Segment數(shù)組容为，Segment繼承與ReentrantLock，Segment則包含HashEntry的數(shù)組寺酪，HashEntry本身就是一個鏈表的結(jié)構(gòu)舟奠，具有保存key、value的能力能指向下一個節(jié)點的指針房维。

實際上就是相當于每個Segment都是一個HashMap，默認的Segment長度是16抬纸，也就是支持16個線程的并發(fā)寫咙俩，Segment之間相互不會受到影響。

put流程

其實發(fā)現(xiàn)整個流程和HashMap非常類似，只不過是先定位到具體的Segment阿趁，然后通過ReentrantLock去操作而已膜蛔，后面的流程我就簡化了，因為和HashMap基本上是一樣的脖阵。

1. 計算hash皂股，定位到segment，segment如果是空就先初始化
2. 使用ReentrantLock加鎖命黔，如果獲取鎖失敗則嘗試自旋呜呐，自旋超過次數(shù)就阻塞獲取，保證一定獲取鎖成功

3. 遍歷HashEntry悍募，就是和HashMap一樣蘑辑，數(shù)組中key和hash一樣就直接替換，不存在就再插入鏈表坠宴，鏈表同樣

   
   

get流程

get也很簡單洋魂，key通過hash定位到segment，再遍歷鏈表定位到具體的元素上喜鼓，需要注意的是value是volatile的副砍，所以get是不需要加鎖的。

1.8CAS+synchronized

1.8拋棄分段鎖庄岖，轉(zhuǎn)為用CAS+synchronized來實現(xiàn)豁翎，同樣HashEntry改為Node，也加入了紅黑樹的實現(xiàn)顿锰。主要還是看put的流程谨垃。

put流程

1. 首先計算hash，遍歷node數(shù)組硼控，如果node是空的話刘陶，就通過CAS+自旋的方式初始化
2. 如果當前數(shù)組位置是空則直接通過CAS自旋寫入數(shù)據(jù)
3. 如果hash==MOVED，說明需要擴容牢撼，執(zhí)行擴容

4. 如果都不滿足匙隔，就使用synchronized寫入數(shù)據(jù)，寫入數(shù)據(jù)同樣判斷鏈表熏版、紅黑樹纷责，鏈表寫入和HashMap的方式一樣，key hash一樣就覆蓋撼短，反之就尾插法再膳，鏈表長度超過8就轉(zhuǎn)換成紅黑樹

   
   

get查詢

get很簡單，通過key計算hash曲横，如果key hash相同就返回喂柒，如果是紅黑樹按照紅黑樹獲取不瓶，都不是就遍歷鏈表獲取。

volatile原理知道嗎灾杰？

相比synchronized的加鎖方式來解決共享變量的內(nèi)存可見性問題蚊丐，volatile就是更輕量的選擇，他沒有上下文切換的額外開銷成本艳吠。使用volatile聲明的變量麦备，可以確保值被更新的時候?qū)ζ渌€程立刻可見。volatile使用內(nèi)存屏障來保證不會發(fā)生指令重排昭娩，解決了內(nèi)存可見性的問題凛篙。

我們知道，線程都是從主內(nèi)存中讀取共享變量到工作內(nèi)存來操作题禀，完成之后再把結(jié)果寫會主內(nèi)存鞋诗，但是這樣就會帶來可見性問題。舉個例子迈嘹，假設現(xiàn)在我們是兩級緩存的雙核CPU架構(gòu)削彬，包含L1、L2兩級緩存秀仲。

1. 線程A首先獲取變量X的值融痛，由于最初兩級緩存都是空，所以直接從主內(nèi)存中讀取X神僵，假設X初始值為0雁刷，線程A讀取之后把X值都修改為1，同時寫回主內(nèi)存保礼。這時候緩存和主內(nèi)存的情況如下圖沛励。

   
   

2. 線程B也同樣讀取變量X的值，由于L2緩存已經(jīng)有緩存X=1炮障，所以直接從L2緩存讀取目派，之后線程B把X修改為2，同時寫回L2和主內(nèi)存胁赢。這時候的X值入下圖所示企蹭。
   那么線程A如果再想獲取變量X的值，因為L1緩存已經(jīng)有x=1了智末，所以這時候變量內(nèi)存不可見問題就產(chǎn)生了谅摄，B修改為2的值對A來說沒有感知。

   
   

那么系馆，如果X變量用volatile修飾的話送漠，當線程A再次讀取變量X的話，CPU就會根據(jù)緩存一致性協(xié)議強制線程A重新從主內(nèi)存加載最新的值到自己的工作內(nèi)存由蘑，而不是直接用緩存中的值螺男。

再來說內(nèi)存屏障的問題棒厘，volatile修飾之后會加入不同的內(nèi)存屏障來保證可見性的問題能正確執(zhí)行。這里寫的屏障基于書中提供的內(nèi)容下隧，但是實際上由于CPU架構(gòu)不同，重排序的策略不同谓媒，提供的內(nèi)存屏障也不一樣淆院，比如x86平臺上，只有StoreLoad一種內(nèi)存屏障句惯。

1. StoreStore屏障土辩，保證上面的普通寫不和volatile寫發(fā)生重排序
2. StoreLoad屏障，保證volatile寫與后面可能的volatile讀寫不發(fā)生重排序
3. LoadLoad屏障抢野，禁止volatile讀與后面的普通讀重排序

4. LoadStore屏障拷淘，禁止volatile讀和后面的普通寫重排序

   
   

那么說說你對JMM內(nèi)存模型的理解？為什么需要JMM指孤？

本身隨著CPU和內(nèi)存的發(fā)展速度差異的問題启涯，導致CPU的速度遠快于內(nèi)存，所以現(xiàn)在的CPU加入了高速緩存恃轩，高速緩存一般可以分為L1结洼、L2、L3三級緩存叉跛∷扇蹋基于上面的例子我們知道了這導致了緩存一致性的問題，所以加入了緩存一致性協(xié)議筷厘，同時導致了內(nèi)存可見性的問題鸣峭，而編譯器和CPU的重排序?qū)е铝嗽有院陀行蛐缘膯栴}，JMM內(nèi)存模型正是對多線程操作下的一系列規(guī)范約束酥艳，因為不可能讓陳雇員的代碼去兼容所有的CPU摊溶，通過JMM我們才屏蔽了不同硬件和操作系統(tǒng)內(nèi)存的訪問差異，這樣保證了Java程序在不同的平臺下達到一致的內(nèi)存訪問效果玖雁，同時也是保證在高效并發(fā)的時候程序能夠正確執(zhí)行更扁。

• 原子性：Java內(nèi)存模型通過read、load赫冬、assign浓镜、use、store劲厌、write來保證原子性操作膛薛，此外還有l(wèi)ock和unlock，直接對應著synchronized關鍵字的monitorenter和monitorexit字節(jié)碼指令补鼻。
• 可見性：可見性的問題在上面的回答已經(jīng)說過哄啄，Java保證可見性可以認為通過volatile雅任、synchronized、final來實現(xiàn)咨跌。
• 有序性：由于處理器和編譯器的重排序?qū)е碌挠行蛐詥栴}沪么，Java通過volatile、synchronized來保證锌半。

happen-before規(guī)則

雖然指令重排提高了并發(fā)的性能禽车，但是Java虛擬機會對指令重排做出一些規(guī)則限制，并不能讓所有的指令都隨意的改變執(zhí)行位置刊殉，主要有以下幾點：

1. 單線程每個操作殉摔，happen-before于該線程中任意后續(xù)操作
2. volatile寫happen-before與后續(xù)對這個變量的讀
3. synchronized解鎖happen-before后續(xù)對這個鎖的加鎖
4. final變量的寫happen-before于final域?qū)ο蟮淖x，happen-before后續(xù)對final變量的讀
5. 傳遞性規(guī)則记焊，A先于B逸月，B先于C，那么A一定先于C發(fā)生

說了半天遍膜，到底工作內(nèi)存和主內(nèi)存是什么碗硬？

主內(nèi)存可以認為就是物理內(nèi)存，Java內(nèi)存模型中實際就是虛擬機內(nèi)存的一部分捌归。而工作內(nèi)存就是CPU緩存肛响，他有可能是寄存器也有可能是L1\L2\L3緩存，都是有可能的惜索。

說說ThreadLocal原理特笋？

ThreadLocal可以理解為線程本地變量，他會在每個線程都創(chuàng)建一個副本巾兆，那么在線程之間訪問內(nèi)部副本變量就行了猎物，做到了線程之間互相隔離，相比于synchronized的做法是用空間來換時間角塑。

ThreadLocal有一個靜態(tài)內(nèi)部類ThreadLocalMap蔫磨，ThreadLocalMap又包含了一個Entry數(shù)組，Entry本身是一個弱引用圃伶，他的key是指向ThreadLocal的弱引用堤如，Entry具備了保存key value鍵值對的能力。

弱引用的目的是為了防止內(nèi)存泄露窒朋，如果是強引用那么ThreadLocal對象除非線程結(jié)束否則始終無法被回收搀罢，弱引用則會在下一次GC的時候被回收。

但是這樣還是會存在內(nèi)存泄露的問題侥猩，假如key和ThreadLocal對象被回收之后榔至，entry中就存在key為null，但是value有值的entry對象欺劳，但是永遠沒辦法被訪問到唧取，同樣除非線程結(jié)束運行铅鲤。

但是只要ThreadLocal使用恰當，在使用完之后調(diào)用remove方法刪除Entry對象枫弟，實際上是不會出現(xiàn)這個問題的邢享。

那引用類型有哪些？有什么區(qū)別媒区？

引用類型主要分為強軟弱虛四種：

1. 強引用指的就是代碼中普遍存在的賦值方式驼仪，比如A a = new A()這種。強引用關聯(lián)的對象袜漩，永遠不會被GC回收。
2. 軟引用可以用SoftReference來描述湾碎，指的是那些有用但是不是必須要的對象宙攻。系統(tǒng)在發(fā)生內(nèi)存溢出前會對這類引用的對象進行回收。
3. 弱引用可以用WeakReference來描述介褥，他的強度比軟引用更低一點座掘，弱引用的對象下一次GC的時候一定會被回收，而不管內(nèi)存是否足夠柔滔。
4. 虛引用也被稱作幻影引用溢陪，是最弱的引用關系，可以用PhantomReference來描述睛廊，他必須和ReferenceQueue一起使用形真，同樣的當發(fā)生GC的時候，虛引用也會被回收超全∨厮可以用虛引用來管理堆外內(nèi)存。

線程池原理知道嗎嘶朱？

首先線程池有幾個核心的參數(shù)概念：

1. 最大線程數(shù)maximumPoolSize
2. 核心線程數(shù)corePoolSize
3. 活躍時間keepAliveTime
4. 阻塞隊列workQueue
5. 拒絕策略RejectedExecutionHandler

當提交一個新任務到線程池時蛾坯，具體的執(zhí)行流程如下：

1. 當我們提交任務，線程池會根據(jù)corePoolSize大小創(chuàng)建若干任務數(shù)量線程執(zhí)行任務
2. 當任務的數(shù)量超過corePoolSize數(shù)量疏遏，后續(xù)的任務將會進入阻塞隊列阻塞排隊
3. 當阻塞隊列也滿了之后脉课，那么將會繼續(xù)創(chuàng)建(maximumPoolSize-corePoolSize)個數(shù)量的線程來執(zhí)行任務，如果任務處理完成财异，maximumPoolSize-corePoolSize額外創(chuàng)建的線程等待keepAliveTime之后被自動銷毀

4. 如果達到maximumPoolSize倘零，阻塞隊列還是滿的狀態(tài)，那么將根據(jù)不同的拒絕策略對應處理

   
   

拒絕策略有哪些宝当？

主要有4種拒絕策略：

1. AbortPolicy：直接丟棄任務视事，拋出異常，這是默認策略
2. CallerRunsPolicy：只用調(diào)用者所在的線程來處理任務
3. DiscardOldestPolicy：丟棄等待隊列中最舊的任務庆揩，并執(zhí)行當前任務
4. DiscardPolicy：直接丟棄任務俐东，也不拋出異常

最后

感謝大家看到這里跌穗，如果本文有什么不足之處，歡迎多多指教虏辫；如果你覺得對你有幫助蚌吸，請給我點個贊。
也歡迎大家關注我的公眾號：程序員麥冬砌庄，每天更新行業(yè)資訊羹唠！