線程池各個(gè)狀態(tài)切換狀態(tài)圖如下：

RUNNING

• 該狀態(tài)的線程池會(huì)接收新任務(wù)，并處理阻塞隊(duì)列中的任務(wù);
• 調(diào)用線程池的shutdown()方法，可以切換到SHUTDOWN狀態(tài);
• 調(diào)用線程池的shutdownNow()方法，可以切換到STOP狀態(tài);

SHUTDOWN

• 該狀態(tài)的線程池不會(huì)接收新任務(wù)，但會(huì)處理阻塞隊(duì)列中的任務(wù)；
• 隊(duì)列為空，并且線程池中執(zhí)行的任務(wù)也為空,進(jìn)入TIDYING狀態(tài);

STOP

• 該狀態(tài)的線程不會(huì)接收新任務(wù)，也不會(huì)處理阻塞隊(duì)列中的任務(wù)，而且會(huì)中斷正在運(yùn)行的任務(wù)；
• 線程池中執(zhí)行的任務(wù)為空,進(jìn)入TIDYING狀態(tài);

TIDYING

• 該狀態(tài)表明所有的任務(wù)已經(jīng)運(yùn)行終止，記錄的任務(wù)數(shù)量為0。
• terminated()執(zhí)行完畢，進(jìn)入TERMINATED狀態(tài)

TERMINATED

• 該狀態(tài)表示線程池徹底終止

6. 線程池原理？各個(gè)參數(shù)的作用。

ThreadPoolExecutor的構(gòu)造函數(shù)：

publicThreadPoolExecutor(intcorePoolSize,intmaximumPoolSize,longkeepAliveTime,TimeUnitunit,
BlockingQueueworkQueue,
ThreadFactorythreadFactory,
RejectedExecutionHandlerhandler)

幾個(gè)核心參數(shù)的作用：

• corePoolSize：線程池核心線程數(shù)最大值
• maximumPoolSize：線程池最大線程數(shù)大小
• keepAliveTime：線程池中非核心線程空閑的存活時(shí)間大小
• unit：線程空閑存活時(shí)間單位
• workQueue：存放任務(wù)的阻塞隊(duì)列
• threadFactory：用于設(shè)置創(chuàng)建線程的工廠，可以給創(chuàng)建的線程設(shè)置有意義的名字，可方便排查問題。
• handler：線城池的飽和策略事件，主要有四種類型。

四種飽和拒絕策略

• AbortPolicy(拋出一個(gè)異常，默認(rèn)的)
• DiscardPolicy(直接丟棄任務(wù))
• DiscardOldestPolicy（丟棄隊(duì)列里最老的任務(wù)，將當(dāng)前這個(gè)任務(wù)繼續(xù)提交給線程池）
• CallerRunsPolicy（交給線程池調(diào)用所在的線程進(jìn)行處理)

線程池原理：

• 提交一個(gè)任務(wù)，線程池里存活的核心線程數(shù)小于線程數(shù)corePoolSize時(shí)，線程池會(huì)創(chuàng)建一個(gè)核心線程去處理提交的任務(wù)。
• 如果線程池核心線程數(shù)已滿，即線程數(shù)已經(jīng)等于corePoolSize，一個(gè)新提交的任務(wù)，會(huì)被放進(jìn)任務(wù)隊(duì)列workQueue排隊(duì)等待執(zhí)行。
• 當(dāng)線程池里面存活的線程數(shù)已經(jīng)等于corePoolSize了,并且任務(wù)隊(duì)列workQueue也滿，判斷線程數(shù)是否達(dá)到maximumPoolSize，即最大線程數(shù)是否已滿，如果沒到達(dá)，創(chuàng)建一個(gè)非核心線程執(zhí)行提交的任務(wù)。
• 如果當(dāng)前的線程數(shù)達(dá)到了maximumPoolSize，還有新的任務(wù)過來的話，直接采用拒絕策略處理。

為了形象描述線程池執(zhí)行，我打個(gè)比喻：

• 核心線程比作公司正式員工
• 非核心線程比作外包員工
• 阻塞隊(duì)列比作需求池
• 提交任務(wù)比作提需求

• 當(dāng)產(chǎn)品提個(gè)需求，正式員工（核心線程）先接需求（執(zhí)行任務(wù)）
• 如果正式員工都有需求在做，即核心線程數(shù)已滿），產(chǎn)品就把需求先放需求池（阻塞隊(duì)列）。
• 如果需求池(阻塞隊(duì)列)也滿了，但是這時(shí)候產(chǎn)品繼續(xù)提需求,怎么辦呢？那就請(qǐng)外包（非核心線程）來做。
• 如果所有員工（最大線程數(shù)也滿了）都有需求在做了，那就執(zhí)行拒絕策略。
• 如果外包員工把需求做完了，它經(jīng)過一段（keepAliveTime）空閑時(shí)間，就離開公司了。

7. ThreadLocal的使用場(chǎng)景有哪些？原理？?jī)?nèi)存泄漏？

ThreadLocal，即線程本地變量。如果你創(chuàng)建了一個(gè)ThreadLocal變量，那么訪問這個(gè)變量的每個(gè)線程都會(huì)有這個(gè)變量的一個(gè)本地拷貝，多個(gè)線程操作這個(gè)變量的時(shí)候，實(shí)際是操作自己本地內(nèi)存里面的變量，從而起到線程隔離的作用，避免了線程安全問題。

ThreadLocal的應(yīng)用場(chǎng)景

• 數(shù)據(jù)庫連接池
• 會(huì)話管理中使用

ThreadLocal內(nèi)存結(jié)構(gòu)圖：

ThreadLocal原理

• Thread對(duì)象中持有一個(gè)ThreadLocal.ThreadLocalMap的成員變量。
• ThreadLocalMap內(nèi)部維護(hù)了Entry數(shù)組，每個(gè)Entry代表一個(gè)完整的對(duì)象，key是ThreadLocal本身，value是ThreadLocal的泛型值。
• 每個(gè)線程在往ThreadLocal里設(shè)置值的時(shí)候，都是往自己的ThreadLocalMap里存，讀也是以某個(gè)ThreadLocal作為引用，在自己的map里找對(duì)應(yīng)的key，從而實(shí)現(xiàn)了線程隔離。

ThreadLocal 內(nèi)存泄露問題

先看看一下的TreadLocal的引用示意圖哈，

ThreadLocalMap中使用的 key 為 ThreadLocal 的弱引用，如下

弱引用：只要垃圾回收機(jī)制一運(yùn)行，不管JVM的內(nèi)存空間是否充足，都會(huì)回收該對(duì)象占用的內(nèi)存。

弱引用比較容易被回收。因此，如果ThreadLocal（ThreadLocalMap的Key）被垃圾回收器回收了，但是因?yàn)門hreadLocalMap生命周期和Thread是一樣的，它這時(shí)候如果不被回收，就會(huì)出現(xiàn)這種情況：ThreadLocalMap的key沒了，value還在，這就會(huì)造成了內(nèi)存泄漏問題。

如何解決內(nèi)存泄漏問題？使用完ThreadLocal后，及時(shí)調(diào)用remove()方法釋放內(nèi)存空間。

8、kafka是如何保證消息的有序性？

kafka這樣保證消息有序性的：

• 一個(gè) topic，一個(gè) partition，一個(gè) consumer，內(nèi)部單線程消費(fèi)，單線程吞吐量太低，一般不會(huì)用這個(gè)。（全局有序性）
• 寫 N 個(gè)內(nèi)存 queue，具有相同 key 的數(shù)據(jù)都到同一個(gè)內(nèi)存 queue；然后對(duì)于 N 個(gè)線程，每個(gè)線程分別消費(fèi)一個(gè)內(nèi)存 queue 即可，這樣就能保證順序性。

大家可以看下消息隊(duì)列的有序性是怎么推導(dǎo)的哈：

消息的有序性，就是指可以按照消息的發(fā)送順序來消費(fèi)。有些業(yè)務(wù)對(duì)消息的順序是有要求的，比如先下單再付款，最后再完成訂單，這樣等。假設(shè)生產(chǎn)者先后產(chǎn)生了兩條消息，分別是下單消息（M1），付款消息（M2），M1比M2先產(chǎn)生，如何保證M1比M2先被消費(fèi)呢。

為了保證消息的順序性，可以將將M1、M2發(fā)送到同一個(gè)Server上，當(dāng)M1發(fā)送完收到ack后，M2再發(fā)送。如圖：

這樣還是可能會(huì)有問題，因?yàn)閺腗Q服務(wù)器到服務(wù)端，可能存在網(wǎng)絡(luò)延遲，雖然M1先發(fā)送，但是它比M2晚到。

那還能怎么辦才能保證消息的順序性呢？將M1和M2發(fā)往同一個(gè)消費(fèi)者，且發(fā)送M1后，等到消費(fèi)端ACK成功后，才發(fā)送M2就得了。

消息隊(duì)列保證順序性整體思路就是這樣啦。比如Kafka的全局有序消息，就是這種思想的體現(xiàn): 就是生產(chǎn)者發(fā)消息時(shí)，1個(gè)Topic只能對(duì)應(yīng)1個(gè)Partition，一個(gè)Consumer，內(nèi)部單線程消費(fèi)。

但是這樣吞吐量太低，一般保證消息局部有序即可。在發(fā)消息的時(shí)候指定Partition Key，Kafka對(duì)其進(jìn)行Hash計(jì)算，根據(jù)計(jì)算結(jié)果決定放入哪個(gè)Partition。這樣Partition Key相同的消息會(huì)放在同一個(gè)Partition。然后多消費(fèi)者單線程消費(fèi)指定的Partition。

9、Nacos的選舉機(jī)制了解嘛？說下Raft算法？

Nacos作為配置中心的功能是基于Raft算法來實(shí)現(xiàn)的。

Raft 算法是分布式系統(tǒng)開發(fā)首選的共識(shí)算法，它通過“一切以領(lǐng)導(dǎo)者為準(zhǔn)”的方式，實(shí)現(xiàn)一系列值的共識(shí)和各節(jié)點(diǎn)日志的一致。

Raft選舉過程涉及三種角色和任期（Term）：

• Follower：默默地接收和處理來自Leader的消息，當(dāng)?shù)却齃eader心跳信息超時(shí)的時(shí)候，就主動(dòng)站出來，推薦自己當(dāng)Candidate。
• Candidate：向其他節(jié)點(diǎn)發(fā)送投票請(qǐng)求，通知其他節(jié)點(diǎn)來投票，如果贏得了大多數(shù)（N/2+1）選票，就晉升Leader。
• Leader：負(fù)責(zé)處理客戶端請(qǐng)求，進(jìn)行日志復(fù)制等操作，每一輪選舉的目標(biāo)就是選出一個(gè)領(lǐng)導(dǎo)者；領(lǐng)導(dǎo)者會(huì)不斷地發(fā)送心跳信息，通知其他節(jié)點(diǎn)“我是領(lǐng)導(dǎo)者，我還活著，你們不要發(fā)起新的選舉，不用找個(gè)新領(lǐng)導(dǎo)者來替代我。”
• Term：這跟民主社會(huì)的選舉很像，每一屆新的履職期稱之為一屆任期

領(lǐng)導(dǎo)選舉過程

1. 在初始時(shí)，集群中所有的節(jié)點(diǎn)都是Follower狀態(tài)，都被設(shè)定一個(gè)隨機(jī)選舉超時(shí)時(shí)間（一般150ms-300ms）：

2. 如果Follower在規(guī)定的超時(shí)時(shí)間，都沒有收到來自Leader的心跳，它就發(fā)起選舉：將自己的狀態(tài)切為 Candidate，增加自己的任期編號(hào)，然后向集群中的其它Follower節(jié)點(diǎn)發(fā)送請(qǐng)求，詢問其是否選舉自己成為L(zhǎng)eader：

3. 其他節(jié)點(diǎn)收到候選人A的請(qǐng)求投票消息后，如果在編號(hào)為1的這屆任期內(nèi)還沒有進(jìn)行過投票，那么它將把選票投給節(jié)點(diǎn)A，并增加自己的任期編號(hào)：

4. 當(dāng)收到來自集群中過半節(jié)點(diǎn)的接受投票后，A節(jié)點(diǎn)即成為本屆任期內(nèi) Leader，他將周期性地發(fā)送心跳消息，通知其他節(jié)點(diǎn)我是Leader，阻止Follower發(fā)起新的選舉：

10、聊一聊TCC補(bǔ)償機(jī)制

TCC是分布式事務(wù)的一種解決方案。它采用了補(bǔ)償機(jī)制，其核心思想是：針對(duì)每個(gè)操作，都要注冊(cè)一個(gè)與其對(duì)應(yīng)的確認(rèn)和補(bǔ)償（撤銷）操作。TCC（Try-Confirm-Cancel）包括三段流程：

• try階段：嘗試去執(zhí)行，完成所有業(yè)務(wù)的一致性檢查，預(yù)留必須的業(yè)務(wù)資源。
• Confirm階段：該階段對(duì)業(yè)務(wù)進(jìn)行確認(rèn)提交，不做任何檢查，因?yàn)閠ry階段已經(jīng)檢查過了，默認(rèn)Confirm階段是不會(huì)出錯(cuò)的。
• Cancel 階段：若業(yè)務(wù)執(zhí)行失敗，則進(jìn)入該階段，它會(huì)釋放try階段占用的所有業(yè)務(wù)資源，并回滾Confirm階段執(zhí)行的所有操作。

下面再拿用戶下單購買禮物作為例子來模擬TCC實(shí)現(xiàn)分布式事務(wù)的過程：

假設(shè)用戶A余額為100金幣，擁有的禮物為5朵。A花了10個(gè)金幣，下訂單，購買10朵玫瑰。余額、訂單、禮物都在不同數(shù)據(jù)庫。

TCC的Try階段：

• 生成一條訂單記錄，訂單狀態(tài)為待確認(rèn)。
• 將用戶A的賬戶金幣中余額更新為90，凍結(jié)金幣為10（預(yù)留業(yè)務(wù)資源）
• 將用戶的禮物數(shù)量為5，預(yù)增加數(shù)量為10。
• Try成功之后，便進(jìn)入Confirm階段
• Try過程發(fā)生任何異常，均進(jìn)入Cancel階段

TCC的Confirm階段：

• 訂單狀態(tài)更新為已支付
• 更新用戶余額為90，可凍結(jié)為0
• 用戶禮物數(shù)量更新為15，預(yù)增加為0
• Confirm過程發(fā)生任何異常，均進(jìn)入Cancel階段
• Confirm過程執(zhí)行成功，則該事務(wù)結(jié)束

TCC的Cancel階段：

• 修改訂單狀態(tài)為已取消
• 更新用戶余額回100
• 更新用戶禮物數(shù)量為5

• TCC的優(yōu)點(diǎn)是可以自定義數(shù)據(jù)庫操作的粒度，降低了鎖沖突，可以提升性能
• TCC的缺點(diǎn)是應(yīng)用侵入性強(qiáng)，需要根據(jù)網(wǎng)絡(luò)、系統(tǒng)故障等不同失敗原因?qū)崿F(xiàn)不同的回滾策略，實(shí)現(xiàn)難度大，一般借助TCC開源框架，ByteTCC，TCC-transaction等。

審核編輯 ：李倩