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

RUNNING

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

SHUTDOWN

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

STOP

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

TIDYING

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

TERMINATED

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

6. 線程池原理？各個參數的作用。

ThreadPoolExecutor的構造函數：

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

幾個核心參數的作用：

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

四種飽和拒絕策略

• AbortPolicy(拋出一個異常，默認的)
• DiscardPolicy(直接丟棄任務)
• DiscardOldestPolicy（丟棄隊列里最老的任務，將當前這個任務繼續(xù)提交給線程池）
• CallerRunsPolicy（交給線程池調用所在的線程進行處理)

線程池原理：

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

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

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

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

7. ThreadLocal的使用場景有哪些？原理？內存泄漏？

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

ThreadLocal的應用場景

• 數據庫連接池
• 會話管理中使用

ThreadLocal內存結構圖：

ThreadLocal原理

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

ThreadLocal 內存泄露問題

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

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

弱引用：只要垃圾回收機制一運行，不管JVM的內存空間是否充足，都會回收該對象占用的內存。

弱引用比較容易被回收。因此，如果ThreadLocal（ThreadLocalMap的Key）被垃圾回收器回收了，但是因為ThreadLocalMap生命周期和Thread是一樣的，它這時候如果不被回收，就會出現這種情況：ThreadLocalMap的key沒了，value還在，這就會造成了內存泄漏問題。

如何解決內存泄漏問題？使用完ThreadLocal后，及時調用remove()方法釋放內存空間。

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

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

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

大家可以看下消息隊列的有序性是怎么推導的哈：

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

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

這樣還是可能會有問題，因為從MQ服務器到服務端，可能存在網絡延遲，雖然M1先發(fā)送，但是它比M2晚到。

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

消息隊列保證順序性整體思路就是這樣啦。比如Kafka的全局有序消息，就是這種思想的體現: 就是生產者發(fā)消息時，1個Topic只能對應1個Partition，一個Consumer，內部單線程消費。

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

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

Nacos作為配置中心的功能是基于Raft算法來實現的。

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

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

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

領導選舉過程

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

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

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

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

10、聊一聊TCC補償機制

TCC是分布式事務的一種解決方案。它采用了補償機制，其核心思想是：針對每個操作，都要注冊一個與其對應的確認和補償（撤銷）操作。TCC（Try-Confirm-Cancel）包括三段流程：

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

下面再拿用戶下單購買禮物作為例子來模擬TCC實現分布式事務的過程：

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

TCC的Try階段：

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

TCC的Confirm階段：

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

TCC的Cancel階段：

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

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

審核編輯 ：李倩