問jvm相關（沒啥變數，只要不打斷把如下內容背下來基本就沒有問題可問了）

1. 先回答jvm概念：jvm是java虛擬機，有了jvm虛擬機之后程序可以跨平臺運行程序，平臺差異性由jvm來解決，另外jvm識別的是class二進制文件，意味著只要支持編譯成class文件的各種語言都能跑在jvm上，比如groovy、kotlin、scala等。
2. 回答運行時區域：jvm在啟動后運行時區域主要分為堆、方法區、虛擬機棧、本地方法棧、程序計數器，其中堆和方法區都是線程共享的，虛擬機棧、本地方法棧、程序計數器都是線程私有的，

• 程序計數器主要存放的是當前正在執行指令的地址，也是唯一不會發生內存溢出的區域。
• 本地方法棧主要存放加了native修飾的那些方法棧幀
• 虛擬機棧中主要存放棧幀，每個棧幀主要分為局部變量表、操作數棧、動態連接、返回地址等。一般一個線程對應的棧的默認大小為1mb,因此如果遞歸太多層容易發生棧內存溢出
• 方法區現在在jdk1.8中主要指元空間，而且內存理論上就是操作系統的剩余內存大小，當然也可以通過參數限制，主要存放類對象及元數據、運行時生成的字節碼對象比如cglib代理生成的類、以及一些jsp等
• 堆是jvm中內存占用最大的一塊，也是gc發生最多的區域，根據不同的gc類型可以劃分為不同的部分，目前主流的還是cms和parNew以及g1。現在用的最多的還是jdk1.8所以堆內存一般劃分為新生代和老年代，新生代中又劃分了eden和2個survivor區。

3. 回答gc: gc一般都是采用分代收集，比如新生代一般采用復制算法，即eden區滿了之后觸發minorgc，通過可達性分析將存活的對象移動到survivor1區，然后下次發生minorgc時將存活對象移動到survivor2區，交替執行。默認存活15次后對象晉升到老年代。如果老年代也滿了就會觸發full gc，老年代一般采用標記整理或者標記清除算法，fullgc對性能相比minorgc有較大影響，因此一般jvm調優的目標就是降低full gc的頻率。

• 一般來說jvm調優只是最后的手段，一般考慮從編程角度或者架構設計方面來優化性能，比如最常見的oom問題。

4. 過渡到內存溢出和內存泄漏

• oom常見的原因主要有棧溢出，比如寫了死遞歸或嵌套層數過多導致，這種通過日志比較容易排查
• 還有方法區溢出，一般是程序動態生成大量對象或者cglib字節碼增強或操作系統本身內存不足
• 還有一些類似于cannot open file或者socket相關錯誤，這種一般是系統資源耗盡或者設置的值過小
• 其他還有比如io等資源用完沒有即時釋放導致的內存溢出
• 除了上述比較容易排查的情況外，一般會設置啟動參數，發生oom時導出堆棧dump文件，可以通過mat進行分析，一般會給一些預測性的結果，此外也可以根據對象的深堆淺堆進行分析對象的引用情況。

5. 過渡到jdk命令。

• 除此外一般還有一些常用命令來分析程序運行情況
• 比如jps\jstat查看gc類加載等\jinfo查看系統程序參數及可動態修改\jstack查看線程快照信息，一般在死鎖時使用
• 我們生產也用arthas來排查不容易復現的問題，比如watch看出入參、trace看調用鏈等

緩存穿透（通常會結合實際場景問，變數較大）

1. 先說概念：緩存穿透是指訪問了緩存及數據庫中不存在的數據。
2. 解決方案：

• 一般來說根據業務場景可以做不同的處理，比如常見的增加參數校驗，對非法id進行過濾，像極少更新的數據或者對實時性要求不強的場景可以簡單的將不存在的key直接緩存起來，下次查詢直接返回空。
• 此外可以考慮采用布隆過濾器，布隆過濾器可以保證有的數據一定能命中，不存在的數據根據布隆過濾器空間大小存在一定的命中率，將所有合法的id放入其中，然后請求優先查詢布隆過濾器，這樣可以攔截絕大部分緩存穿透的情況，而redis的bitmap正好可以作為布隆過濾器。

緩存擊穿

1. 除了緩存穿透可能還會遇到緩存擊穿的情況，這種是指某一個熱點數據緩存過期導致短時間請求都打到數據庫上導致的性能問題。
2. 解決方案：

• 這種現象一般在緩存的有效期上下手，可以考慮根據熱點時間錯開過期時間，或者設置不過期或者提前預熱數據等。請求量不大的情況下可以在代碼層面對key加鎖，確保只有一個線程進行查庫操作，其他線程暫時等待。

緩存雪崩

1. 緩存雪崩可以理解成緩存擊穿的并發場景，處理方式類似。

雙親委派（主要問有啥好處，可能引申到tomcat打破的流程，或者其他還有哪些場景打破了，需要去了解）

1. 概念：雙親委派是當類加載器加載類時，自己先看是否已有緩存，沒有的話會交給父類加載器去加載，然后如果父類加載器找不到就會依次交給子類加載器加載。
2. 目的：主要目的就是為了jvm的運行安全考慮，舉個例子如果沒有這套機制，然后string類被惡意類加載加載，在tostring方法中執行惡意代碼，后果很嚴重。

• 除了安全問題外也能提高性能，因為類加載后會緩存起來。

說說Spring中用到的設計模式（比較開放的問題，不一定要全答，回答了一個設計模式可能會問該模式相關問題）

• 最先看到的就是模版設計模式，在abstractapplicationcontext里面的refresh方法能很好的體現出來，留了一些鉤子方法等子類實現
• 另外還有很多工廠模式，比如beanfactory等
• 還有比較常見的裝飾器模式的使用，很多地方都用到了wrapper包裝對象，比如beanwrapper,有了wrapper之后可以對bean的屬性進行讀寫操作，也可以做一些類型轉換的工作
• 還有aop中使用的動態代理模式，將符合切點條件的bean都生成代理對象，springboot2.0版本中默認使用cglib代理。
• 像剛說到的aop中還用到了適配器模式，因為切面分了好幾種比如前置后置環繞異常等，其中像前置這種沒有實現methodinterceptor接口，而aop的執行的必須要實現這個接口，所以會通過適配器模式來完成前置通知功能
• 此外aop還用了責任鏈模式，用來遞歸所有通知進行增強
• 還有觀察者模式，主要用在事件監聽機制，比如上下文初始化之前，之后等時機，比如dubbo中service就是在finishrefresh中的事件通知中進行服務暴露的

Spring的aop是怎么實現的（主要考的是實現細節，需要看源碼或流程圖鞏固下）

• 首先aop觸發的時機是在bean實例化并且初始化后的beanpostprocess中完成的，其中會執行proxybeanpostprocessor的postprocessafterinitialization，在里面會對bean進行代理增強
• 主要流程是先會從beandefinition中找到所有加了aspect注解的類，然后會將類中的各種增強切面封裝為advice,然后和切點pointcut封裝為advisor對象
• 接下來就是匹配bean和切點，通過cglib字節碼增強生成代理類完成切面功能

生產中用過線程池（主要考的是7個參數以及分別設置成多少合理）

• 生產中用了自定義線程池，幾個比較重要的初始化參數比如核心線程數、最大線程數、最大線程過期時間以及時間單位、還有阻塞隊列、如果有個性化需求可以自定義threadfactory,比如自定義線程名稱等，最后還有個拒絕策略，默認用的是超過最大線程之后丟棄新任務并拋出異常，此外還有丟棄最舊任務策略、丟棄新任務不拋異常策略、還有讓業務線程來跑任務策略，當然也能自定義拒絕策略。
• 我們的業務場景是消費mq數據，因為后續處理耗時比消費mq可能要慢，所以這里采用的是業務線程來跑任務，這樣做的好處就是一旦后續處理不過來，可以自動降低mq消費速度，因為這個時候消費mq的線程已經用來跑任務了。

使用線程池有哪些好處

• 可以避免頻繁的創建和銷毀線程的流程，降低cpu開銷
• 可以控制線程的并發數，避免無休止的創建線程導致內存溢出等問題
• 可以起到統一管理線程的作用，提前做好規劃

mybatis中的mapper接口為什么沒有實現類也能使用（主要問的是factorybean的使用，可以延伸到sqlsession的緩存失效問題）

• 首先mapper接口是有實現類的，只不過是mybatis框架幫我們生的代理類，mybatis和spring整合后通過mapperScan先掃描了所有的mapper，然后丟到beanFactory里，給他的類型設置成了mapperFactoryBean,也就是一個工廠bean,通過getObject生成mapper接口的代理類。
• 其中會通過一個sqlsessiontemplate的模版session，從中生成sqlSession代理對象，在執行mapper方法時還會從threadlocal中判斷是否有sqlsession緩存，如果沒有的話就會新生成一個sqlsession。
• 這也是為什么mybatis和spring整合后如果方法沒加事務會導致mybatis一級緩存失效的原因，因為一級緩存的生命周期是sqlsession，如果沒加事務，那就每次新生成sqlsession，自然一級緩存也就失效了。

spring和springboot有什么區別（主要考的是springboot的特性-自動裝配，最好說出springboot的啟動流程）

• Spring是一個基礎框架，主要提供ioc和aop功能，幫助我們管理實例的生命周期以及初始化工作，同時也提供了大量的擴展點
• springboot是基于spring的一個框架，主要作用是提供了自動裝配功能，免去了spring的一些配置，采用約定大于配置的理念來實現的。
• 那么自動裝配是怎么實現的呢
• 首先是把啟動配置類當作參數傳入springapplication.run方法，也就是加了springbootapplication注解的類，因為這個注解包含了幾個很重要的注解，比如componentscan,enableAutoConfiguration等等，接下來在初始化applicationcontext上下文時會內置加載幾個很重要的postprocessor，比如autowiredAnnotationBeanpostprocessor、commonAnnotationBeanpostprocesso、configurationClassPostprocessor。
• 其中最重要的就是configurationClassPostprocessor,他其實是一個factoryPostprocessor接口的實現類，也就是說他的生命周期方法在beandefinition生成前后執行，因此他承擔了幾個很重要的注解引入的類的加載，比如componentscan注解，enableAutoConfiguration注解，其中enableAutoConfiguration注解就是實現自動裝配的關鍵點，這個注解import了一個autoConfigurationimportSelector類，這個類會通過spi的機制，也就是通過springFactoriesLoader去加載mete-inf目錄下的spring.factories文件，然后去加載key為enableAutoConfiguration的所有value對象并解析為beandefinition,后續流程就是和以前讀取xml配置文件后的流程一致了
• 主要步驟就是bean的實例化，再進行屬性依賴注入，再進行beanpostprocessor的before方法，再進行自定義初始化方法，也就是afterpropertiesset方法和init方法，最后進行beanpostprocessor的after方法，aop的主要入口也在這里。

spring循環依賴

• 首先Spring為我們解決了絕大部分場景下的循環依賴，比如a類有屬性b,b類有屬性a這種，但是如果ab都是通過構造方法注入的話spring是解決不了的。
• 因為spring解決循環依賴主要的做法是采用三級緩存，也就是當a類在實例化后會將a的objectFactory加入到3級緩存，接下來ioc注入b,這時發現b還沒有實例化，又會進行b的實例化并加入3級緩存，接下來b又開始注入a,這個時候就能從3級緩存中拿到a的半成品，這個時候a只是剛完成實例化，這樣b就能完成整個bean的創建及初始化，完成后b后再回到a的整個bean的初始化，這樣就解決了循環依賴，這也是為什么不支持構造方法之間的相互依賴。
• 按理說二級緩存就能解決循環依賴問題，為啥需要三級緩存
• 因為還要考慮到支持aop，在三級緩存中放的是a的objectFactory，如果只用2級緩存，那么意味著這個時候必須先把a生成代理類后放入2級緩存，再注入到b,這就與spring設計的bean初始化的流程違背了，因為spring設計的代理生成是在bean完成實例化并且完成初始化方法之后進行的，而循環依賴只是一種特殊情況，所以不得已在注入時先對a生成了代理類。

zk驚群效應怎么解決

• 一般我們實現分布式鎖時可能遇見這種情況，也就是當資源釋放時，將會喚醒所有等待資源的線程，但最終也只有一個線程能獲取資源，非常容易造成網絡沖擊以及資源消耗。
• 所以一般都會在實現分布式鎖時都只會監聽前一個節點的狀態，這樣也就相當于每次資源釋放時只會喚醒一個下一個節點，避免了全部喚醒。

項目中用了哪些設計模式

• 常見的如模版模式，一般會先寫好主要的業務流程，然后再填充
• 代理模式，也就是借助spring的aop來實現的一些切面，另外有通過factorybean的方式代理生成rpc調用
• 策略模式，比較常見的可以借助Spring ioc在注入屬性時注入Map類型，這樣可以把同接口的不同邏輯的實現類全部注入，然后再給實例名和業務建立一個映射關系，后面就可以通過參數來確定調用哪個策略了。策略不多時比較好用，我們生產遇到過十幾個策略，結果非常難維護，新來的人根本不知道走的哪個策略，

kafka的消息流轉過程

• 首先kafka的消息可以批量寫入，然后消息是以topic作為區分隊列的，然后每個topic可以分為多個分區，每個分區相當于一個文件，默認情況是將消息輪詢的發到不同的分區，然后消費者可以以分組的形式去重復消費同一個topic,同一個group下的消費者可以一個消費者對應多個分區，但是一個分區在同一個group下只能由一個消費者消費。
• 另外kafka中采用偏移量的概念來確定消息是否消費，默認情況是采用自動提交，5秒鐘消費者提交一次偏移量到一個指定的topic，證明這一段偏移量的數據已消費完成，也可以采用同步提交或者異步提交的方式

redis底層數據結構優化

• 首先string這種類型在底層采用了sds數據類型來保存，他相比于c中的string來說多記錄了字符串的長度而且預先分配了額外空間，所以在修改或者讀取時都有時間上的優勢，提高了讀寫速度。
• 另外像hash這種數據結構redis在擴容時做了優化，不是一次性完成擴容，這樣在key很多的場景下對性能影響較大，而是采用漸進式擴容，也就是新建一個hash，將新數據放入新hash，查詢的時候可能需要查詢2次。
• 還有就是在有序集合的底層采用了跳表來加快查找速度，跳表就是有多層的鏈表結構，每次從頂層開始找，依次向后向下開始找，然后插入的時候會隨機將插入值升級到上一級，所以從概率的角度來看跳表的每一層鏈表都是下一層的一半，雖然需要冗余一些數據，但是性能也就跟平衡二叉樹差不多了，而且實現和理解卻要簡單不少。
• 其中有序集合zset中元素個數小于閾值且元素長度小于閾值的時候用的是ziplist,否則用的是hash+跳表實現
• 還有對整數類型的集合進行了不同長度類型的區分，節省了內存
• 底層還用了壓縮列表的數據結構，他保存了每個元素的長度，可以理解成讓數組中每個元素按實際長度存儲，主要用在list和hash上，可以節省內存

redis的zset如果要先按分數排序，同分數按時間靠前的排序怎么做

• 因為zset類型會關聯一個score字段，可以考慮拆分分數，把高位作為分數，低位作為時間戳，而且是比如用2099年的時間戳-當前時間戳，這樣就是時間越靠前差值越大就排在前面，
• 其中有個問題，因為分數超過16位整數精度會丟失，所以時間戳不能太長，用秒級10位應該夠用了，并且要和分數綜合考慮下高位和地位的分割。

單例模式有哪幾種，哪些是線程安全的

• 單例模式主要有懶漢式和餓漢式，餓漢式就是在類加載后就完成初始化了，懶漢式則要等到使用時才進行初始化
• 餓漢式是線程安全的，懶漢式如果采用內部靜態類來實現也是線程安全的，由jdk的語言特性來確保加載完成前其他線程處于阻塞，或者雙重鎖檢查并且加上volatile來禁止初始化時指令重排序也可以做到線程安全，最后枚舉也能實現線程安全的單例模式。

講一講線程安全（volatile,threadlocal,cas,lock,aqs等）

• 一般從代碼角度來講，應盡量避免在單例中使用成員屬性，容易導致數據異常，非要使用的話可以考慮加volatile關鍵字來保證其可見性，但是并不能保證其并發修改安全
• 此外如果是線程獨有的數據可以考慮使用threadlocal來維護線程私有的屬性，因為每個線程中都包含了一個map對象，key就是threadlocald對象，value就是業務數據。所以threadlocal能保證線程安全，但是他也容易造成內存泄漏，所以我們在使用完成后應該及時手動remove其中的數據。
• 如果說確實存在需要爭搶的資源，如果是簡單的數值類型也可以考慮使用atomicInteger等原子類數據，他主要通過cas操作來保證一定成功，主要思想就是每次修改時都會傳入修改后的值和修改前的值，先比較修改前的值和內存中的值是否一致，一致則修改，否則取出新的值重新計算，整個過程沒有加鎖但是也耗費cpu性能，所以使用場景有限
• 一般生產中用的最多的還是使用鎖來保證線程安全，主要有synchronized和lock

synchronized與lock理解

• synchronized是jdk的語言特性，封裝了加鎖釋放鎖的細節，使用起來簡單，而且因為是語言特性所以如果后期優化還能享受這塊的福利，但是也存在不靈活性，比如一旦沒搶到鎖就只能等待。
• lock實現的鎖就比較靈活了，有trylock這種嘗試獲取鎖，沒拿到鎖還可以做一些其他業務邏輯，另外還支持過期時間以及可中斷鎖，此外還支持公平鎖，讀寫鎖等，并且是基于aqs實現的，性能也不錯
• 可能會追問aqs了
• aqs的數據結構主要是一個雙向鏈表，然后空表頭，后面掛的節點就是一個個線程，為了防止驚群效應，這里設計的是每個節點僅監聽上一個節點的狀態位，并且持有資源的線程釋放鎖后只會喚醒下一個節點。如果是非公平鎖那么就是在加入隊列之前會先去嘗試拿鎖，這樣效率更高，因為cas操作的開銷遠遠低于喚醒線程

juc工具包用了哪些

• 常見的比如原子類atomicInteger等
• 還有讀寫鎖、可重入鎖等
• 還有一些工具類比如countdownlatch、信號量、cyclebarrier
• countdownlatch可以用來實現阻塞通知，而且是一次性的
• 信號量主要用來做流控的，但是要注意他不會對令牌數做限制，也就是可以放入比初始化更多的令牌
• cyclebarrier可以用來做合并計算的場景，可以重復使用
• 此外還有線程池（上面有了線程池就不再復述了）

mysql的引擎，索引分類

• mysql目前用的版本5.7存儲引擎默認為innodb，還有myisam、memory等等，innodb不僅支持事務還支持行鎖，所以一般用的都是這個。
• innodb的數據結構使用的是b+樹，特點是每個節點可以保存很多索引，默認是4kb大小，所以樹的高度比較低，另外數據僅放在葉子結點，所以每次查找速度相比于b樹結構來說比較穩定。
• 其中索引還分為聚簇索引和非聚簇索引，聚簇索引指的就是以主鍵作為索引，或者唯一索引，如果你不建唯一索引還會自動生成隱式唯一主鍵，然后每一個主鍵對應的行數據都放在葉子結點，因此通過走主鍵索引查詢效率比較高
• 此外還有非聚簇索引，一般指普通索引，這種葉子結點存放的是主鍵索引對應的值，需要先通過普通索引找到主鍵的值，再通過聚簇索引查到對應的行數據，因此效率比聚簇索引低，當然比全表掃描塊

索引失效

• 所以一般開發中都要注意避免索引失效，常見的有like關鍵字需要以明確信息開頭，不能開頭用通配符，另外where條件中用or可能導致失效，可以考慮用union或者in來代替，再比如索引字段的類型不能改變，比如字符串類型字段不能用數字類型查，另外值也不能進行加減乘除等類似操作，還有范圍條件查詢最好放最后，否則后面的索引可能會失效

mysql事務

• mysql事務一般說的指當用innodb引擎下的事務，一般分為四種隔離級別
• 讀未提交：這種是隔離級別最低的，意思是a事務能讀到b未提交的事務，可能造成臟讀、幻讀、不可重復讀問題，一般生產不使用
• 還有讀已提交：意思是a事務可以讀到b事務已提交的數據，但依然存在幻讀和不可重復讀
• 另外還有可重復讀：意思是a事務第一次查詢后，后續都是快照讀，因此可以解決不可重復讀，但是仍然存在幻讀的可能，所以一般當我們需要在一個事物內先查詢后修改數據時一般都會采select for update這種當前讀模式鎖住指定的行數據，另外mysql默認就是這個隔離級別。
• 最后一種就是串行化，不會發生上述情況，但是性能也很低，生產幾乎不會使用。

數據分庫分表

• 通常需要根據業務情況來進行合適的水平拆分或者垂直拆分
• 常用的比如可以根據日期來分表、根據租戶來分表
• 另外比如將訂單表垂直拆分為主表和附表

mycat使用（待補充）

mysql的char和varchar的區別

• char都是定長的字符串，就是在建表時就確定了這個字段的字節長度，假設10個字節長度，只存入了6個，則會在左邊補位，所以空間占用都是連續不會發生變化，因此性能較好，
• 一般使用場景是長度固定或者長度變化范圍很小的字段，或者簡單字符類似枚舉值，還有像很短的長度這些場景比較合適，
• varchar是變長的字符串，除了會存儲字段本身外還會存儲字段的長度，假設建表時設置10個字節長度，但是只存入了5個字節，那么實際使用的是6個字節，因為還需要額外一個字節來表示長度。這種比較省空間，
• 一般使用場景為該字段最大長度遠大于平均長度，或者更新比較少也就是很少產生空間碎片，再比如存放了類似utf-8這種變長復雜的字符集

統計文檔每個字符出現的次數并排序

• hash+優先隊列，自定義排序規則
• hash+桶排序
• hash計數，entryset放入list再對value排序

dubbo中用的協議，協議特點

• dubbo支持很多通訊協議，比如dubbo協議、rmi協議、hessian協議、webservice、http、restful等等，最新版本也支持了grpc協議
• 目前常用的還是dubbo協議，因為他是基于tcp之上的協議，比較精簡，而且使用的是nio模型，因此特別適用于多個消費者少量服務者，并且報文較小的場景，一般來說絕大部分場景都適用于這種。

dubbo中用的序列化，序列化特點

• dubbo本身支持hessian2、json、xml、jdk序列化
• 其中默認走dubbo協議，默認hessian2序列化
• hessian2序列化主要有跨平臺、二進制、體積小的有點
• 此外也可以使用像protobuf、thrift等

redis紅鎖

• 這個是redis官方提出的一個概念，主要指的是幾個獨立的redis節點，當要進行上鎖時，必須超過半數的節點均獲取鎖成功才算成功，他是依次向節點獲取鎖并記錄獲取時間，并計入過期時間內
• 紅鎖主要用來解決redis主從切換時，主從之間數據異步同步導致重復上鎖的場景問題。

zuul和gateway區別

• zuul是spring cloud早期集成的一個網關組件，他是基于servlet容器實現的，采用bio模型，提供了動態路由、安全認證、性能檢測等功能，主要是通過filter來實現的，另外也支持集成hystix實現服務降級等功能
• gateway是spring團隊基于netty框架開發的，采用的是nio模型，因此性能比較高，由于是依賴spring-webflux開發的，所以也只適用于springcloud環境中，此外本身支持限流、斷言、過濾、以及websocket協議

分布式id有哪些方式實現

• 常見的有uuid、redis自增、數據庫自增id、雪花算法、號段模式

雪花算法有什么缺點

• 雪花算法的原理就是把一個長整型數字根據位劃分為幾塊，每塊表示不同含義，通常包括時間戳、機器碼、序列號等，這樣就能確保在分布式場景下生成不同并且是遞增的id
• 但是雪花算法強依賴系統時鐘，一旦發生時鐘回撥可能導致id重復，可以考慮等待時間追回或者記錄下最后一個id,然后遞增序列號等，具體根據實際場景來處理，

網關限流方式有哪些

• 網關限流通常采用兩種方式
• 令牌桶，就是在固定時間內生成一定的令牌，每筆請求消耗一個令牌，超過了則拒絕請求
• 漏桶，指的是固定桶容量，每筆請求占一個位置，超過容量則拒絕，并且放行的速度是恒定的

redis鎖續期

• 鎖續期指的是當使用redis鎖時，通常都會給鎖設置有效期，防止異常情況鎖無法釋放，但是也存在有效期到了之后仍然沒有完成業務邏輯，還不能釋放鎖。所以此時需要進行鎖續期。
• 通常我們使用redisson封裝好的lock來實現redis分布式鎖，他提供了鎖續期功能，主要是采用看門狗機制，即當獲取到鎖之后會隔10s檢測鎖是否持有，如果仍然持有則延長鎖時間。

synchronized鎖升級過程

• synchronized在jdk1.8中已經擺脫了性能低下的標簽，因為他采用了鎖升級的機制，也就是不同場景使用不同的鎖機制，
• 比如當一個鎖總是一個線程獲取，這時為偏向鎖，會在mark word進行標記，此時相當于無鎖化
• 當有第二個線程來獲取鎖時會檢測到標記為偏向鎖，此時會等到安全時期暫停第一個線程并將鎖升級到輕量級鎖
• 接著第二個線程會判斷當前鎖是否釋放，如果第一個已經釋放了則第二個通過cas獲取鎖，如果鎖已經存在了則膨脹為重量級鎖
• 將第二個線程加入等待隊列并park,等待上個節點做unpark

當有事情需要其他組協助時該怎么溝通才能完成（套話）

• 拉群，加上領導，然后群里確定時間，無法確定時間的則確定什么時候能確定時間
• 如遇到裝死的則召開會議，并輸出會議紀要
• 與對方領導溝通

jump原因(套話)

• 技術棧
• 待遇

學習途徑（套話）

• 書籍：相對來說比較權威而且全面，但是緩慢且容易過時
• 個大博客，類似csdn、博客園、掘金、github、簡書等，適合了解新鮮知識及入門，但深度相對較淺且容易良莠不齊
• 官網：最權威，適合深入學習
• 視頻：相對來說容易上手和理解，但速度較慢且視頻質量參差不齊

還有些套路的，只列標題

linux常用命令

netty運行流程

• netty是基于nio的reactor反應堆模型的高性能通訊框架
• 由于代碼完善基本使用是一個套路，準備2個線程池，一個用來專門處理accepter事件，一個用來處理讀寫io事件，再按照業務編排不同的子handler,如編解碼、心跳、日志、業務等，一般會在業務handler中使用業務線程池避免阻塞這個eventloop上其他的讀寫事件。

io模型

tcp三次握手

粘包拆包

ssl流程

網絡七層模型

常見/了解的協議

二叉查找樹結構及前中后序遞歸遍歷及非遞歸遍歷

dfs算法

冒泡、插入、快排算法

hash/鏈表數據結構

equal和hashcode作用及原理

spring系列常用注解及作用