干貨！關(guān)于Java基礎(chǔ)的16個(gè)問題總結(jié)

小伙伴們，請(qǐng)聽題~~

說說進(jìn)程和線程的區(qū)別？

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

由于進(jìn)程是資源分配和調(diào)度的基本單位，因?yàn)檫M(jìn)程的創(chuàng)建、銷毀、切換產(chǎn)生大量的時(shí)間和空間的開銷，進(jìn)程的數(shù)量不能太多，而線程是比進(jìn)程更小的能獨(dú)立運(yùn)行的基本單位，他是進(jìn)程的一個(gè)實(shí)體，可以減少程序并發(fā)執(zhí)行時(shí)的時(shí)間和空間開銷，使得操作系統(tǒng)具有更好的并發(fā)性。

線程基本不擁有系統(tǒng)資源，只有一些運(yùn)行時(shí)必不可少的資源，比如程序計(jì)數(shù)器、寄存器和棧，進(jìn)程則占有堆、棧。

知道synchronized原理嗎？

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

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

執(zhí)行monitorexit指令時(shí)則會(huì)把計(jì)數(shù)器-1，當(dāng)計(jì)數(shù)器值為0時(shí)，則鎖釋放，處于等待隊(duì)列中的線程再繼續(xù)競(jìng)爭(zhēng)鎖。

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

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

實(shí)際上大部分時(shí)候我認(rèn)為說到monitorenter就行了，但是為了更清楚的描述，還是再具體一點(diǎn)。

如果再深入到源碼來說，synchronized實(shí)際上有兩個(gè)隊(duì)列waitSet和entryList。

1. 當(dāng)多個(gè)線程進(jìn)入同步代碼塊時(shí)，首先進(jìn)入entryList
2. 有一個(gè)線程獲取到monitor鎖后，就賦值給當(dāng)前線程，并且計(jì)數(shù)器+1
3. 如果線程調(diào)用wait方法，將釋放鎖，當(dāng)前線程置為null，計(jì)數(shù)器-1，同時(shí)進(jìn)入waitSet等待被喚醒，調(diào)用notify或者notifyAll之后又會(huì)進(jìn)入entryList競(jìng)爭(zhēng)鎖
4. 如果線程執(zhí)行完畢，同樣釋放鎖，計(jì)數(shù)器-1，當(dāng)前線程置為null

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

從JDK1.6版本之后，synchronized本身也在不斷優(yōu)化鎖的機(jī)制，有些情況下他并不會(huì)是一個(gè)很重量級(jí)的鎖了。優(yōu)化機(jī)制包括自適應(yīng)鎖、自旋鎖、鎖消除、鎖粗化、輕量級(jí)鎖和偏向鎖。

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

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

自適應(yīng)鎖：自適應(yīng)鎖就是自適應(yīng)的自旋鎖，自旋的時(shí)間不是固定時(shí)間，而是由前一次在同一個(gè)鎖上的自旋時(shí)間和鎖的持有者狀態(tài)來決定。

鎖消除：鎖消除指的是JVM檢測(cè)到一些同步的代碼塊，完全不存在數(shù)據(jù)競(jìng)爭(zhēng)的場(chǎng)景，也就是不需要加鎖，就會(huì)進(jìn)行鎖消除。

鎖粗化：鎖粗化指的是有很多操作都是對(duì)同一個(gè)對(duì)象進(jìn)行加鎖，就會(huì)把鎖的同步范圍擴(kuò)展到整個(gè)操作序列之外。

偏向鎖：當(dāng)線程訪問同步塊獲取鎖時(shí)，會(huì)在對(duì)象頭和棧幀中的鎖記錄里存儲(chǔ)偏向鎖的線程ID，之后這個(gè)線程再次進(jìn)入同步塊時(shí)都不需要CAS來加鎖和解鎖了，偏向鎖會(huì)永遠(yuǎn)偏向第一個(gè)獲得鎖的線程，如果后續(xù)沒有其他線程獲得過這個(gè)鎖，持有鎖的線程就永遠(yuǎn)不需要進(jìn)行同步，反之，當(dāng)有其他線程競(jìng)爭(zhēng)偏向鎖時(shí)，持有偏向鎖的線程就會(huì)釋放偏向鎖?？梢杂眠^設(shè)置-XX:+UseBiasedLocking開啟偏向鎖。

輕量級(jí)鎖：JVM的對(duì)象的對(duì)象頭中包含有一些鎖的標(biāo)志位，代碼進(jìn)入同步塊的時(shí)候，JVM將會(huì)使用CAS方式來嘗試獲取鎖，如果更新成功則會(huì)把對(duì)象頭中的狀態(tài)位標(biāo)記為輕量級(jí)鎖，如果更新失敗，當(dāng)前線程就嘗試自旋來獲得鎖。

整個(gè)鎖升級(jí)的過程非常復(fù)雜，我盡力去除一些無用的環(huán)節(jié)，簡(jiǎn)單來描述整個(gè)升級(jí)的機(jī)制。

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

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

在我們常用的Hotspot虛擬機(jī)中，對(duì)象在內(nèi)存中布局實(shí)際包含3個(gè)部分：

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

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

1. 對(duì)象自身運(yùn)行時(shí)所需的數(shù)據(jù)，也被稱為Mark Word，也就是用于輕量級(jí)鎖和偏向鎖的關(guān)鍵點(diǎn)。具體的內(nèi)容包含對(duì)象的hashcode、分代年齡、輕量級(jí)鎖指針、重量級(jí)鎖指針、GC標(biāo)記、偏向鎖線程ID、偏向鎖時(shí)間戳。
2. 存儲(chǔ)類型指針，也就是指向類的元數(shù)據(jù)的指針，通過這個(gè)指針才能確定對(duì)象是屬于哪個(gè)類的實(shí)例。

如果是數(shù)組的話，則還包含了數(shù)組的長(zhǎng)度

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

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

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

ReentrantLock基于AQS(AbstractQueuedSynchronizer 抽象隊(duì)列同步器)實(shí)現(xiàn)。別說了，我知道問題了，AQS原理我來講。

AQS內(nèi)部維護(hù)一個(gè)state狀態(tài)位，嘗試加鎖的時(shí)候通過CAS(CompareAndSwap)修改值，如果成功設(shè)置為1，并且把當(dāng)前線程ID賦值，則代表加鎖成功，一旦獲取到鎖，其他的線程將會(huì)被阻塞進(jìn)入阻塞隊(duì)列自旋，獲得鎖的線程釋放鎖的時(shí)候?qū)?huì)喚醒阻塞隊(duì)列中的線程，釋放鎖的時(shí)候則會(huì)把state重新置為0，同時(shí)當(dāng)前線程ID置為空。

CAS的原理呢？

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

1. 變量?jī)?nèi)存地址，V表示
2. 舊的預(yù)期值，A表示
3. 準(zhǔn)備設(shè)置的新值，B表示

當(dāng)執(zhí)行CAS指令時(shí)，只有當(dāng)V等于A時(shí)，才會(huì)用B去更新V的值，否則就不會(huì)執(zhí)行更新操作。

那么CAS有什么缺點(diǎn)嗎？

CAS的缺點(diǎn)主要有3點(diǎn)：

ABA問題：ABA的問題指的是在CAS更新的過程中，當(dāng)讀取到的值是A，然后準(zhǔn)備賦值的時(shí)候仍然是A，但是實(shí)際上有可能A的值被改成了B，然后又被改回了A，這個(gè)CAS更新的漏洞就叫做ABA。只是ABA的問題大部分場(chǎng)景下都不影響并發(fā)的最終效果。

Java中有AtomicStampedReference來解決這個(gè)問題，他加入了預(yù)期標(biāo)志和更新后標(biāo)志兩個(gè)字段，更新時(shí)不光檢查值，還要檢查當(dāng)前的標(biāo)志是否等于預(yù)期標(biāo)志，全部相等的話才會(huì)更新。

循環(huán)時(shí)間長(zhǎng)開銷大：自旋CAS的方式如果長(zhǎng)時(shí)間不成功，會(huì)給CPU帶來很大的開銷。

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

好，說說HashMap原理吧？

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

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

往map插入元素的時(shí)候首先通過對(duì)key hash然后與數(shù)組長(zhǎng)度-1進(jìn)行與運(yùn)算((n-1)&hash)，都是2的次冪所以等同于取模，但是位運(yùn)算的效率更高。找到數(shù)組中的位置之后，如果數(shù)組中沒有元素直接存入，反之則判斷key是否相同，key相同就覆蓋，否則就會(huì)插入到鏈表的尾部，如果鏈表的長(zhǎng)度超過8，則會(huì)轉(zhuǎn)換成紅黑樹，最后判斷數(shù)組長(zhǎng)度是否超過默認(rèn)的長(zhǎng)度*負(fù)載因子也就是12，超過則進(jìn)行擴(kuò)容。

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

查詢數(shù)據(jù)相對(duì)來說就比較簡(jiǎn)單了，首先計(jì)算出hash值，然后去數(shù)組查詢，是紅黑樹就去紅黑樹查，鏈表就遍歷鏈表查詢就可以了。

resize擴(kuò)容過程

擴(kuò)容的過程就是對(duì)key重新計(jì)算hash，然后把數(shù)據(jù)拷貝到新的數(shù)組。

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

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

ConcurrentHashmap在JDK1.7和1.8的版本改動(dòng)比較大，1.7使用Segment+HashEntry分段鎖的方式實(shí)現(xiàn)，1.8則拋棄了Segment，改為使用CAS+synchronized+Node實(shí)現(xiàn)，同樣也加入了紅黑樹，避免鏈表過長(zhǎng)導(dǎo)致性能的問題。

1.7分段鎖

從結(jié)構(gòu)上說，1.7版本的ConcurrentHashMap采用分段鎖機(jī)制，里面包含一個(gè)Segment數(shù)組，Segment繼承與ReentrantLock，Segment則包含HashEntry的數(shù)組，HashEntry本身就是一個(gè)鏈表的結(jié)構(gòu)，具有保存key、value的能力能指向下一個(gè)節(jié)點(diǎn)的指針。

實(shí)際上就是相當(dāng)于每個(gè)Segment都是一個(gè)HashMap，默認(rèn)的Segment長(zhǎng)度是16，也就是支持16個(gè)線程的并發(fā)寫，Segment之間相互不會(huì)受到影響。

put流程

其實(shí)發(fā)現(xiàn)整個(gè)流程和HashMap非常類似，只不過是先定位到具體的Segment，然后通過ReentrantLock去操作而已，后面的流程我就簡(jiǎn)化了，因?yàn)楹虷ashMap基本上是一樣的。

1. 計(jì)算hash，定位到segment，segment如果是空就先初始化
2. 使用ReentrantLock加鎖，如果獲取鎖失敗則嘗試自旋，自旋超過次數(shù)就阻塞獲取，保證一定獲取鎖成功
3. 遍歷HashEntry，就是和HashMap一樣，數(shù)組中key和hash一樣就直接替換，不存在就再插入鏈表，鏈表同樣

get流程

get也很簡(jiǎn)單，key通過hash定位到segment，再遍歷鏈表定位到具體的元素上，需要注意的是value是volatile的，所以get是不需要加鎖的。

1.8CAS+synchronized

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

put流程

1. 首先計(jì)算hash，遍歷node數(shù)組，如果node是空的話，就通過CAS+自旋的方式初始化
2. 如果當(dāng)前數(shù)組位置是空則直接通過CAS自旋寫入數(shù)據(jù)
3. 如果hash==MOVED，說明需要擴(kuò)容，執(zhí)行擴(kuò)容
4. 如果都不滿足，就使用synchronized寫入數(shù)據(jù)，寫入數(shù)據(jù)同樣判斷鏈表、紅黑樹，鏈表寫入和HashMap的方式一樣，key hash一樣就覆蓋，反之就尾插法，鏈表長(zhǎng)度超過8就轉(zhuǎn)換成紅黑樹

get查詢

get很簡(jiǎn)單，通過key計(jì)算hash，如果key hash相同就返回，如果是紅黑樹按照紅黑樹獲取，都不是就遍歷鏈表獲取。

volatile原理知道嗎？

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

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

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

2. 線程B也同樣讀取變量X的值，由于L2緩存已經(jīng)有緩存X=1，所以直接從L2緩存讀取，之后線程B把X修改為2，同時(shí)寫回L2和主內(nèi)存。這時(shí)候的X值入下圖所示。

   那么線程A如果再想獲取變量X的值，因?yàn)長(zhǎng)1緩存已經(jīng)有x=1了，所以這時(shí)候變量?jī)?nèi)存不可見問題就產(chǎn)生了，B修改為2的值對(duì)A來說沒有感知。

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

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

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

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

本身隨著CPU和內(nèi)存的發(fā)展速度差異的問題，導(dǎo)致CPU的速度遠(yuǎn)快于內(nèi)存，所以現(xiàn)在的CPU加入了高速緩存，高速緩存一般可以分為L(zhǎng)1、L2、L3三級(jí)緩存?；谏厦娴睦游覀冎懒诉@導(dǎo)致了緩存一致性的問題，所以加入了緩存一致性協(xié)議，同時(shí)導(dǎo)致了內(nèi)存可見性的問題，而編譯器和CPU的重排序?qū)е铝嗽有院陀行蛐缘膯栴}，JMM內(nèi)存模型正是對(duì)多線程操作下的一系列規(guī)范約束，因?yàn)椴豢赡茏岅惞蛦T的代碼去兼容所有的CPU，通過JMM我們才屏蔽了不同硬件和操作系統(tǒng)內(nèi)存的訪問差異，這樣保證了Java程序在不同的平臺(tái)下達(dá)到一致的內(nèi)存訪問效果，同時(shí)也是保證在高效并發(fā)的時(shí)候程序能夠正確執(zhí)行。

原子性：Java內(nèi)存模型通過read、load、assign、use、store、write來保證原子性操作，此外還有l(wèi)ock和unlock，直接對(duì)應(yīng)著synchronized關(guān)鍵字的monitorenter和monitorexit字節(jié)碼指令。

可見性：可見性的問題在上面的回答已經(jīng)說過，Java保證可見性可以認(rèn)為通過volatile、synchronized、final來實(shí)現(xiàn)。

有序性：由于處理器和編譯器的重排序?qū)е碌挠行蛐詥栴}，Java通過volatile、synchronized來保證。

happen-before規(guī)則

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

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

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

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

說說ThreadLocal原理？

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

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

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

但是這樣還是會(huì)存在內(nèi)存泄露的問題，假如key和ThreadLocal對(duì)象被回收之后，entry中就存在key為null，但是value有值的entry對(duì)象，但是永遠(yuǎn)沒辦法被訪問到，同樣除非線程結(jié)束運(yùn)行。

但是只要ThreadLocal使用恰當(dāng)，在使用完之后調(diào)用remove方法刪除Entry對(duì)象，實(shí)際上是不會(huì)出現(xiàn)這個(gè)問題的。

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

引用類型主要分為強(qiáng)軟弱虛四種：

1. 強(qiáng)引用指的就是代碼中普遍存在的賦值方式，比如A a = new A()這種。強(qiáng)引用關(guān)聯(lián)的對(duì)象，永遠(yuǎn)不會(huì)被GC回收。
2. 軟引用可以用SoftReference來描述，指的是那些有用但是不是必須要的對(duì)象。系統(tǒng)在發(fā)生內(nèi)存溢出前會(huì)對(duì)這類引用的對(duì)象進(jìn)行回收。
3. 弱引用可以用WeakReference來描述，他的強(qiáng)度比軟引用更低一點(diǎn)，弱引用的對(duì)象下一次GC的時(shí)候一定會(huì)被回收，而不管內(nèi)存是否足夠。
4. 虛引用也被稱作幻影引用，是最弱的引用關(guān)系，可以用PhantomReference來描述，他必須和ReferenceQueue一起使用，同樣的當(dāng)發(fā)生GC的時(shí)候，虛引用也會(huì)被回收。可以用虛引用來管理堆外內(nèi)存。

線程池原理知道嗎？

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

1. 最大線程數(shù)maximumPoolSize

2. 核心線程數(shù)corePoolSize

3. 活躍時(shí)間keepAliveTime

4. 阻塞隊(duì)列workQueue

5. 拒絕策略RejectedExecutionHandler

當(dāng)提交一個(gè)新任務(wù)到線程池時(shí)，具體的執(zhí)行流程如下：

1. 當(dāng)我們提交任務(wù)，線程池會(huì)根據(jù)corePoolSize大小創(chuàng)建若干任務(wù)數(shù)量線程執(zhí)行任務(wù)
2. 當(dāng)任務(wù)的數(shù)量超過corePoolSize數(shù)量，后續(xù)的任務(wù)將會(huì)進(jìn)入阻塞隊(duì)列阻塞排隊(duì)
3. 當(dāng)阻塞隊(duì)列也滿了之后，那么將會(huì)繼續(xù)創(chuàng)建(maximumPoolSize-corePoolSize)個(gè)數(shù)量的線程來執(zhí)行任務(wù)，如果任務(wù)處理完成，maximumPoolSize-corePoolSize額外創(chuàng)建的線程等待keepAliveTime之后被自動(dòng)銷毀
4. 如果達(dá)到maximumPoolSize，阻塞隊(duì)列還是滿的狀態(tài)，那么將根據(jù)不同的拒絕策略對(duì)應(yīng)處理

拒絕策略有哪些？

主要有4種拒絕策略：

1. AbortPolicy：直接丟棄任務(wù)，拋出異常，這是默認(rèn)策略
2. CallerRunsPolicy：只用調(diào)用者所在的線程來處理任務(wù)
3. DiscardOldestPolicy：丟棄等待隊(duì)列中最舊的任務(wù)，并執(zhí)行當(dāng)前任務(wù)
4. DiscardPolicy：直接丟棄任務(wù)，也不拋出異常

—————END—————

喜歡本文的朋友，歡迎關(guān)注公眾號(hào)?程序員小灰，收看更多精彩內(nèi)容

       

        

         

          

           

            

             

              
             
             

              點(diǎn)個(gè)[在看]，是對(duì)小灰最大的支持！