簡歷:第二章:技術亮點備戰

2021-03-09 12:01:14

個人覺得需要花費一個月時間精心準備,想要拿高薪就必須噁心自己。

面試回答通用套路:先介紹是什麼,執行原理是什麼樣的,然後舉例說明便於理解,最後結合案例分析優缺點,提出解決方案

 

熟練掌握常用的java集合以及多執行緒並行環境下集合類出現的並行修改異常。比如,寫時複製,CAS,ABA,Volatilte等。

HashMap是Map的一個實現類,它是以鍵值對儲存資料的,Key-Value都是Map.Entry中的屬性。當我們向HashMap中存放一個元素(k1,v1),先根據k1的hashCode方法來決定在陣列中存放的位置。如果這個位置沒有其它元素,將(k1,v1)直接放入一個Node型別的陣列中,當元素加到12的時候,底層會進行擴容,擴容為原來的2倍。如果該位置已經有其它元素(k2,v2),那就呼叫k1的equals方法和k2進行比較二個元素是否相同,如果結果為true,說明二個元素是一樣的,用v1替換v2,如果返回值為false,二個元素不一樣,就用連結串列的形式將(k1,v1)存放。不過當連結串列中的資料較多時,查詢的效率會下降,所以在JDK1.8版本後做了一個升級,HashMap儲存資料結構連結串列長度超過8且陣列長度大於64時資料結構,會將連結串列替換成紅黑樹才會樹化時,會將連結串列替換成紅黑樹,來提高查詢效率。因為對於搜尋,插入,刪除操作多的情況下,使用紅黑樹的效率要高一些。因為紅黑樹是一種特殊的二叉查詢樹,二叉查詢樹所有節點的左子樹都小於該節點,所有節點的右子樹都大於該節點,就可以通過大小比較關係來進行快速的檢索。在紅黑樹上插入或者刪除一個節點之後,紅黑樹就發生了變化,但它不再是一顆紅黑樹時,可以通過左旋和右旋,保證每次插入最多隻需要三次旋轉就能達到平衡,因為紅黑樹強制約束了從根到葉子的最長的路徑不多於最短的路徑的兩倍長,插入、刪除和查詢某個值的最壞情況時間都要求與樹的高度成比例,這個在高度上的理論上限允許紅黑樹在最壞情況下都是高效的。

HashMap實際使用過程中會出現一些執行緒安全問題,在JDK1.7中,當並行執行擴容操作時會造成環形鏈和資料丟失的情況,開多個執行緒不斷進行put操作,rehash的時候,舊連結串列遷移新連結串列的時候,如果在新表的陣列索引位置相同,則連結串列元素會倒置(就是因為頭插) 所以最後的結果打亂了插入的順序,就可能發生環形鏈和資料丟失的問題,引起死迴圈,導致CPU利用率接近100%。在jdk1.8中對HashMap進行了優化,發生hash碰撞,不再採用頭插法方式,而是直接插入連結串列尾部,因此不會出現環形連結串列的情況,但是在多執行緒環境下,會發生資料覆蓋的情況,如果沒有hash碰撞的時候,它會直接插入元素。如果執行緒A和執行緒B同時進行put操作,剛好這兩條不同的資料hash值一樣,並且該位置資料為null,執行緒A進入後還未進行資料插入時掛起,而執行緒B正常執行,從而正常插入資料,然後執行緒A獲取CPU時間片,此時執行緒A不用再進行hash判斷了,執行緒A會把執行緒B插入的資料給覆蓋,導致資料發生覆蓋的情況,發生執行緒不安全。

除此之外還有故障現象:java.util.ConcurrentModificationException並行修改異常。導致原因:並行爭取修改導致,一個執行緒正在寫,一個執行緒過來爭搶,導致執行緒寫的過程被其他執行緒打斷,導致資料不一致。

第一種解決方案使用HashTable:

HashTable是執行緒安全的,只不過實現代價卻太大了,簡單粗暴,get/put所有相關操作都是synchronized的,這相當於給整個雜湊表加了一把大鎖。多執行緒存取時候,只要有一個執行緒存取或操作該物件,那其他執行緒只能阻塞,相當於將所有的操作序列化,在競爭激烈的並行場景中效能就會非常差。

第二種解決方案使用工具類,執行緒同步:Map<String,String> hashMap = Collections.synchronizedMap(new HashMap<>());

和Hashtable一樣,實現上在操作HashMap時自動新增了synchronized來實現執行緒同步,都對整個map進行同步,在效能以及安全性方面不如ConcurrentHashMap。

第三種解決方案使用寫時複製:CopyOnWrite:往一個容器裡面加元素的時候,不直接往當前容器新增,而是先將當前容器的元素複製出來放到一個新的容器中,然後新的元素新增元素,新增完之後,再將原來容器的參照指向新的容器,這樣就可以對它進行並行的毒,不需要加鎖,因為當前容器不新增任何元素。利用了讀寫分離的思想,讀和寫是不同的容器。

會有記憶體佔用問題,在複製的時候只是複製容器裡的參照,只是在寫的時候會建立新物件新增到新容器裡,而舊容器的物件還在使用,所以有兩份物件記憶體。

會有資料一致性問題,CopyOnWrite容器只能保證資料的最終一致性,不能保證資料的實時一致性。

第四種解決方案:使用ConcurrentHashMap:

為了應對hashmap在並行環境下不安全問題可以使用,ConcurrentHashMap大量的利用了volatile,CAS等技術來減少鎖競爭對於效能的影響。在JDK1.7版本中ConcurrentHashMap避免了對全域性加鎖,改成了區域性加鎖(分段鎖),分段鎖技術,將資料分成一段一段的儲存,然後給每一段資料配一把鎖,當一個執行緒佔用鎖存取其中一個段資料的時候,其他段的資料也能被其他執行緒存取,能夠實現真正的並行存取。不過這種結構的帶來的副作用是Hash的過程要比普通的HashMap要長。

所以在JDK1.8版本中CurrentHashMap內部中的value使用volatile修飾,保證並行的可見性以及禁止指令重排,只不過volatile不保證原子性,使用為了確保原子性,採用CAS(比較交換)這種樂觀鎖來解決。CAS 操作包含三個運算元 —— 記憶體位置(V)、預期原值(A)和新值(B)。如果記憶體地址裡面的值和A的值是一樣的,那麼就將記憶體裡面的值更新成B。CAS是通過無限迴圈來獲取資料的,若果在第一輪迴圈中,a執行緒獲取地址裡面的值被b執行緒修改了,那麼a執行緒需要自旋,到下次迴圈才有可能機會執行。

volatile有三個特性:可見性,不保證原子性,禁止指令重排。

可見性:執行緒1從主記憶體中拿資料1到自己的執行緒工作空間進行操作(假設是加1)這個時候資料1已經改為資料2了,將資料2寫回主記憶體時通知其他執行緒(執行緒2,執行緒3),主記憶體中的資料1已改為資料2了,讓其他執行緒重新拿新的資料(資料2)。

不保證原子性:執行緒1從主記憶體中拿了一個值為1的資料到自己的工作空間裡面進行加1的操作,值變為2,寫回主記憶體,然後還沒有來得及通知其他執行緒,執行緒1就被執行緒2搶佔了,CPU分配,執行緒1被掛起,執行緒2還是拿著原來主記憶體中的資料值為1進行加1,值變成2,寫回主記憶體,將主記憶體值為2的替換成2,這時執行緒1的通知到了,執行緒2重新去主記憶體拿值為2的資料。

禁止指令重排:首先指令重排是程式執行的時候不總是從上往下執行的,就像高考答題,可以先做容易的題目再做難的,這時做題的順序就不是從上往下了。禁止指令重排就杜絕了這種情況。

 

熟練掌握執行緒池底層實現原理並可根據實際業務場景設定合理的執行緒數以及拒絕策略。

執行緒池就是控制執行的執行緒數量,處理過程中將任務放到佇列,然後線上程建立後啟動這些任務,如果執行緒數量超出了最大數量就排隊等候,等其他執行緒執行完畢再從佇列中取出任務執行。

執行緒池相當於銀行網點,常駐核心數相當於今日當值視窗,執行緒池能夠同時執行的最大執行緒數相當於銀行所有的視窗,任務佇列相當於銀行的候客區,當今日當值視窗滿了,多出來的客戶去候客區等待,當候客區滿了,銀行加開視窗,候客區先來的客戶去加班視窗,當銀行所有的視窗滿了,其他客戶在候客區等待,同時拒絕其他客戶進入銀行。當使用者少了,加班的視窗等待時間(相當於多餘執行緒存活的時間)(等待時間的單位相當於unit引數)假設超過一個小時還是沒有人來,就取消加班的視窗。

底層在建立執行緒池的時候有七個引數:核心執行緒數,同時執行的最大執行緒數,多餘執行緒存活時間,單位時間秒,任務佇列,預設執行緒工廠,拒絕策略

corePoolSize:核心執行緒數,如何合理的設定核心執行緒數?

對於CPU密集型任務,由於CPU密集型任務的性質,導致CPU的使用率很高,如果執行緒池中的核心執行緒數量過多,會增加上下文切換的次數,帶來額外的開銷。因此,考慮到CPU密集型任務因為某些原因而暫停,這個時候有額外的執行緒能確保CPU這個時刻不會浪費,還可以增加一個CPU上下文切換。一般情況下:執行緒池的核心執行緒數量等於CPU核心數+1。例如需要大量的計算,視訊渲染啊,模擬啊之類的。這個時候CPU就卯足了勁在執行,這個時候切換執行緒,反而浪費了切換的時間,效率不高。打個比方,你的大腦是CPU,你本來就在一本心思地寫作業,多執行緒這時候就是要你寫會作業,然後立刻敲一會程式碼,然後在P個圖,然後在看個視訊,然後再切換回作業。emmmm,過程中你還需要切換(收起來作業,拿出電腦,開啟VS…)那你的作業怕是要寫到掛科。這個時候你就該一門心思地寫作業。

對於I/O密集型任務,由於I/O密集型任務CPU使用率並不是很高,可以讓CPU在等待I/O操作的時去處理別的任務,充分利用CPU。一般情況下:執行緒的核心執行緒數等於2*CPU核心數。例如你需要陪小姐姐或者小哥哥聊天,還需要下載一個VS,還需要看部落格。打個比方,小姐姐給你發訊息了,回一下她,然後呢?她給你回訊息肯定需要時間,這個時候你就可以搜尋VS的網站,先下安裝包,然後一看,哎呦,她還沒給你回訊息,然後看會自己的部落格。小姐姐終於回你了,你回一下她,接著看我的部落格,這就是類似於IO密集型。你可以在不同的「不燒腦」的工作之間切換,來達到更高的效率。而不是小姐姐不回我的資訊,我就乾等,啥都不幹,就等,這個效率可想而知,也許,小姐姐根本就不會回覆你。

對於混合型任務,由於包含2種型別的任務,故混合型任務的執行緒數與執行緒時間有關。在某種特定的情況下還可以將任務分為I/O密集型任務和CPU密集型任務,分別讓不同的執行緒池去處理。一般情況下:執行緒池的核心執行緒數=(執行緒等待時間/執行緒CPU時間+1)*CPU核心數;

並行高、業務執行時間長,解決這種型別任務的關鍵不在於執行緒池而在於整體架構的設計,看看這些業務裡面某些資料是否能做快取是第一步,我們的專案使用的時redis作為快取(這類非關係型資料庫還是挺好的)。增加伺服器是第二步(一般政府專案的首先,因為不用對專案技術做大改動,求一個穩,但前提是資金充足),至於執行緒池的設定,設定參考 2 。最後,業務執行時間長的問題,也可能需要分析一下,看看能不能使用中介軟體(任務時間過長的可以考慮拆分邏輯放入佇列等操作)對任務進行拆分和解耦。

maximumPoolsize:同時執行的最大執行緒數

keepAliveTime:多餘執行緒存活時間,當前執行緒池數量超過核心執行緒數時,當前空閒時間達到多餘執行緒存活時間的值的時候,多餘空閒執行緒會被銷燬到只剩核心執行緒數為止

unit:多餘執行緒存活時間的單位

workQueue:任務佇列,被提交但尚未被執行的任務

threadFactory:生成執行緒池的執行緒工廠

handler:拒絕策略,當佇列滿了並且工作執行緒數量大於執行緒池的最大執行緒數時,提供拒絕策略。

第一種拒絕策略:AbortPolicy:超出最大執行緒數,直接丟擲RejectedExecutionException異常阻止系統正常執行。可以感知到任務被拒絕了,於是你便可以根據業務邏輯選擇重試或者放棄提交等策略。

第二種拒絕策略:該策略既不會拋棄任務,也不會丟擲異常,而是將某些任務回退到呼叫者,相當於當執行緒池無能力處理當前任務時,會將這個任務的執行權交予提交任務的執行緒來執行,也就是誰提交誰負責,從而降低新任務的流量。(誰呼叫了你,到達最大執行緒數時,你回去找呼叫你的人,然後聽從呼叫你的人安排)(超出的我們能辦的給你辦,不能辦的給你回退 )這樣的話提交的任務就不會被丟棄而造成業務損失,如果任務比較耗時,那麼這段時間內提交任務的執行緒也會處於忙碌狀態而無法繼續提交任務,這樣也就減緩了任務的提交速度,這相當於一個負反饋,也有利於執行緒池中的執行緒來消化任務。這種策略算是最完善的相對於其他三個。

第三拒絕策略:DiscardOldestPolicy:拋棄佇列中等待最久的任務,也就是它丟棄的是佇列中的頭節點,然後把當前任務加入佇列中嘗試再次提交當前任務

第四種拒絕策略:DiscardPolicy:直接丟棄任務,不予任何處理也不拋異常,當任務提交時直接將剛提交的任務丟棄,而且不會給與任何提示通知。

在實際使用的時候,選擇執行緒池的時候儘量不用JDK提供的三種常見的建立方式,因為它的底層佇列是Linked這個接近於無界,非常大,這樣會堆積大量的請求,從而導致OOM,阿里巴巴開發手冊推薦我們使用ThreadPoolExecutor去建立執行緒池。

熟練掌握JUC並行包,比如:迴圈柵欄,訊號燈,倒計時器等,aba,cas,aqs,unsafe,volatile,sync,常見的各種lock,oom如何定位問題,cpu過高如何定位,top,jps,jstack,jmap,mesi協定

CountDownLatch倒計時器:讓一些執行緒阻塞直到另一些執行緒完成一系統操作後才被喚醒。一個 CountDownLatch 用給定的計數初始化。await() 方法阻塞,直到由於countDown() 方法的呼叫而導致當前計數達到零,之後所有等待執行緒被釋放,並且任何後續的 await() 呼叫立即返回。 這是一個一次性的現象 - 計數無法重置。

舉個例子:我們的API介面響應時間被要求在200ms以內,但是如果一個介面內部依賴多個三方/外部服務,那序列呼叫介面的響應時間必然很久,所以可使用內部服務並行呼叫進行優化。

假設介面內部依賴了10個外部服務,建立CountDownLatch範例,計數數量為10,有10個執行緒來完成任務,等待在CountDownLatch上的執行緒執行完才能繼續執行那個響應時間較快的介面。latch.countDown();方法作用是通知CountDownLatch有一個執行緒已經準備完畢,倒計數器可以減一了。latch.await()方法要求主執行緒等待所有10個檢查任務全部準備好才一起並行執行。

一種典型的場景就是火箭發射。在火箭發射前,為了保證萬無一失,往往還要進行各項裝置、儀器的檢測。只有等到所有的檢查完畢後,引擎才能點火。那麼在檢測環節當然是多個檢測項可以同時進行的

Semaphore訊號燈:多個共用資源互斥使用,控制執行緒並行數量,多個執行緒搶多個資源。

1、Semaphore號誌作為一種流控手段,可以對特定資源的允許同時存取的運算元量進行控制,例如池化技術(連線池)中的並行數,有界阻塞容器的容量等。

2、Semaphore中包含初始化時固定個數的許可,在進行操作的時候,需要先acquire獲取到許可,才可以繼續執行任務,如果獲取失敗,則進入阻塞;處理完成之後需要release釋放許可。

3、acquire與release之間的關係:在實現中不包含真正的許可物件,並且Semaphore也不會將許可與執行緒關聯起來,因此在一個執行緒中獲得的許可可以在另一個執行緒中釋放。可以將acquire操作視為是消費一個許可,而release操作是建立一個許可,Semaphore並不受限於它在建立時的初始許可數量。也就是說acquire與release並沒有強制的一對一關係,release一次就相當於新增一個許可,許可的數量可能會由於沒有與acquire操作一對一而導致超出初始化時設定的許可個數。 舉例,有六臺車搶三個停車位。

CyclicBarrier迴圈柵欄:當多個執行緒一起執行任務是,一個執行緒沒有完成任務,其他執行緒都必須進入等待狀態,等待這個執行緒完成任務後,才能再執行其他任務。強調相互等待,一個執行緒不完成,其他執行緒全部等待。

建立CyclicBarrier時,它預設的構造方法是 CyclicBarrier(int parties),其參數列示屏障攔截的執行緒數量。呼叫await方法的執行緒告訴CyclicBarrier自己已經到達同步點,然後當前執行緒被阻塞。

例如:一個公司去團建,需要大家全部集合完畢後,才能出發,有一個人員不到,全員都得等待。它的作用就是會讓所有執行緒都等待完成後才會繼續下一步行動。

CAS:https://liaozhiwei.blog.csdn.net/article/details/97611037

volatile:https://liaozhiwei.blog.csdn.net/article/details/97611028

從ReentrantLock的實現看AQS的原理及應用:https://tech.meituan.com/2019/12/05/aqs-theory-and-apply.html

unsafe:https://www.jianshu.com/p/db8dce09232d

synchronized 關鍵字:https://www.cnblogs.com/admol/p/13994297.html

各種鎖:https://liaozhiwei.blog.csdn.net/article/details/106908803

oom如何定位問題:https://www.cnblogs.com/lujiango/p/9650927.html

top,jps,jstack,jmap:https://liaozhiwei.blog.csdn.net/article/details/107030159

cpu過高如何定位:https://jishuin.proginn.com/p/763bfbd282b6

MESI協定:https://www.cnblogs.com/itqczzz/p/12670782.html

熟悉掌握Redis資料結構的使用場景,熟悉Redis快取高並行的使用場景。比如,單執行緒模型,aof,rdb,rewrite,主從,cluster,哪些型別,擊穿、穿透、雪崩、資料一致性,一致性hash,布隆過濾器的原理,底層資料結構sds和跳錶

內容太多,分章節了,順便偷個懶參照一下其他大佬的文章,這些文章算是我精挑細選的,你想要成為高階開發,這些東西必須要吃到肚子裡還能講出來才行,當然還不止這些哈。

Redis五巨量資料結構應用場景落地:https://liaozhiwei.blog.csdn.net/article/details/114301491

Redis的五巨量資料型別底層實現原理:https://www.cnblogs.com/ysocean/p/9102811.html

Redis的單執行緒和高效能:https://liaozhiwei.blog.csdn.net/article/details/113930507

Redis持久化機制與安全機制:https://liaozhiwei.blog.csdn.net/article/details/113932050

Redis快取延時雙刪保證和MySQL的資料一致性:https://blog.csdn.net/qq_33589510/article/details/109531954

快取穿透、快取擊穿、快取雪崩:https://www.cnblogs.com/ysocean/p/12452023.html

過期刪除策略和記憶體淘汰策略:https://www.cnblogs.com/ysocean/p/12422635.html

哨兵(Sentinel)模式詳解:https://www.cnblogs.com/ysocean/p/12290364.html

熱點快取處理方案:https://www.cnblogs.com/thinkqin/articles/11955856.html

Redis布隆過濾器:https://www.cnblogs.com/ysocean/p/12594982.html

深入理解MySQL底層索引資料結構,B+ tree索引特點以及資料庫事務的隔離級別,鎖,主從

MySQL索引 B+樹 資料庫事務隔離級別: https://www.jianshu.com/p/a591b11c1b46

MySQL索引背後的資料結構及演演算法原理: http://blog.codinglabs.org/articles/theory-of-mysql-index.html

MySQL鎖:https://blog.csdn.net/qq_40378034/article/details/90904573

MySQL主備、主從、讀寫分離:https://blog.csdn.net/qq_40378034/article/details/91125768

深入理解JVM底層原理,JMM記憶體模型,垃圾回收機制,GC演演算法,熟悉JVM各種垃圾回收器的使用以及核心引數調優,類載入過程,雙親委派,逃逸分析

JVM記憶體模型,演演算法,垃圾回收器,調優:https://liaozhiwei.blog.csdn.net/article/details/106630556

類載入過程:https://liaozhiwei.blog.csdn.net/article/details/107920767

逃逸分析:https://blog.csdn.net/hollis_chuang/article/details/80922794

Java物件結構與鎖實現原理及MarkWord詳解:https://blog.csdn.net/scdn_cp/article/details/86491792

熟悉常見訊息中介軟體的使用,解決過各種訊息通訊場景的疑難問題。比如,重複消費,順序訊息,事務訊息,高可用,訊息丟失,擠壓場景,整個訊息傳送消費的流程

mq如何保證高可用,解決重複消費、資料丟失問題和順序性問題:https://www.jianshu.com/p/c833de561335

分散式事務:https://www.cnblogs.com/mayundalao/p/11798502.html

訊息專題:https://www.cnblogs.com/jack1995/category/1469110.html

在專案中解決過各種分散式場景的技術難題,比如分散式鎖,分散式事務。搶紅包,高並行下單等常規的場景設計

分散式常見問題:https://www.cnblogs.com/xuwc/p/9139164.html

分散式鎖,session,事務:https://www.yuque.com/baiqi-giihx/ldopha/hr6362

熟練掌握spring,spring mvc,mybatis,spring boot等開源框架,bean的生命週期,如何解決迴圈依賴,父子容器,還有boot的啟動流程,事務實現原理,動態代理原理

解決spring迴圈依賴:https://blog.csdn.net/qq_36381855/article/details/79752689

bean的生命週期:https://liaozhiwei.blog.csdn.net/article/details/84391519

父子容器:http://www.tianshouzhi.com/api/tutorials/spring

Springboot啟動流程:https://www.cnblogs.com/trgl/p/7353782.html

事務實現原理:https://www.zhihu.com/question/428589024/answer/1556584930

動態代理原理:https://www.cnblogs.com/gonjan-blog/p/6685611.html

深入理解spring could,zookeeper,dubbo等開源框架的底層架構。設計框架,負載均衡,spi機制,選舉演演算法

SpringCould:

https://blog.csdn.net/forezp/article/details/70148833

https://blog.csdn.net/qq_41701956/article/details/83829539

zookeeper:

https://blog.csdn.net/u011414200/article/details/50248099?utm_medium=distribute.pc_relevant.none-task-blog-baidujs_title-9&spm=1001.2101.3001.4242

https://liaozhiwei.blog.csdn.net/article/details/107029848

dubbo:

spi:https://blog.csdn.net/lzb348110175/article/details/98484451

負載均衡:https://www.jianshu.com/p/c08197641500

選舉演演算法:https://www.cnblogs.com/sweet6/p/10574574.html

熟練掌握Linux常用命令,生產環境伺服器變慢診斷,線上排查,效能評估。

故障排查:https://liaozhiwei.blog.csdn.net/article/details/107005583

Netty的話,零拷貝,bio,nio,aio,架構設計怎麼樣子的?

https://blog.csdn.net/qq_39311377/article/details/110699288

高頻面試題:https://www.cnblogs.com/iwenwen/category/1485041.html

 

原文地址【阿里P6面經】

Java集合比如說HashMap和ConcurrentHashMap我覺得,你最好在平時能去耐心讀一下原始碼,搜一搜相關的部落格,最好能知道每個引數為什麼設定成這麼大?有什麼好處?為什麼?你會發現不少東西,網上也有很多視訊可以去學。

JUC包,毫無疑問的,你得去學,哪怕你平時程式設計根本不去用,但是你得會,只得知道有這個東西,你至少得知道aba,cas,aqs,unsafe,volatile,sync,常見的各種lock,死鎖,執行緒池引數和如何合理的去設定,你必須明白自旋,阻塞,死鎖和它如何去定位,oom如何定位問題,cpu過高如何定位等基本的操作,你可以沒有生產偵錯經驗,但不代表你可以不會top,jps,jstack,jmap這些可能會問的東西。以及可能衍生的jmm模型和mesi協定等。

JVM毫無意外,大廠必須問,垃圾回收演演算法,垃圾收集器,jvm記憶體模型,每個區域用途,各種oom的種類,jvm調優經驗,沒有你也要做過,自己去設定啟動引數,知道常見引數的含義,類載入過程,雙親委派,什麼時候young gc,full gc,各種情況進入老年代的方式,你知道的越多越好,因為吹起來就越自信,舉個例子,逃逸分析是什麼?markword裡面有什麼?

Spring,最好能抽空看看原始碼,最起碼bean的生命週期,如何解決迴圈依賴,父子容器,還有boot的啟動流程,事務實現原理,動態代理原理等,你知道越多越好。

Dubbo,因為我用的是dubbo,而且我寫了,這個也是高頻,寫了必須問的,他的設計框架,負載均衡,spi機制,一般順勢會提到zk,選舉演演算法,分散式鎖等,一些常見的dubbo問題可以去搜,網上的基本都有。可能會順帶去問cloud的問題,生產沒用過不怕,你現在可以自己clone一個專案,最起碼,互聯娃,你得知道還有這個玩意兒,還有他整合了啥,比如rureka,hystrix,ribbon,feign,zuul這些常規的東西吧,他們做什麼的?

Redis,必須會的,我這方便還算懂得多點,可以和麵試官大戰幾個回合吧,應該不至於上來被打趴下,單執行緒模型,aof,rdb,rewrite,主從,cluster,哪些型別,不要再說常規的5個了,多說幾個讓你區別其他小哥,包含一些快取常見的問題擊穿、穿透、雪崩、資料一致性等,你必須會,不會基本沒戲,一致性hash,布隆過濾器的原理,為此我還去了解了geohash的原理以及google s2的原理,底層資料結構sds和跳錶等,你多學點,準沒錯。

Mysql,事務,鎖,索引,b+樹,主從這些你必須會

Mq ,我用的rocketmq,你得知道為什麼用,重複消費,順序訊息,事務訊息,高可用,訊息丟失,擠壓場景,整個訊息傳送消費的流程,讀過原始碼更佳,更好吹

Netty的話,零拷貝,bio,nio,aio,架構設計怎麼樣子的?用過看過更好

演演算法,建議去刷題,我運氣好,簡單的演演算法讓我碰到了,一些快排,堆排,二元樹相關的,連結串列反轉,成環,環節點,跳樓梯等常規的簡單演演算法建議刷刷,雙指標,dp,遞迴這些還是多找找感覺,巨量資料記憶體有限的場景的統計,有時間一些middle可以去試試,手寫紅黑樹你要是可以,那我估計演演算法你穩了。

網路,http,tcp,https,udp,7層網路協定等,最好結合自己理解,背,你都要背下來。

還有就是一些分散式事務實現,架構實現,比如搶紅包,高並行下單等常規的場景設計,你來設計,你怎麼去設計?多找一些大牛或者上網自己查,幫你看看有哪些漏洞,有那些解決方案?業界有哪些好的中介軟體?
 

基礎性備戰面試題:

HashMap底層原理,擴容機制,jdk8以後會使用紅黑樹優化?紅黑樹和二叉平衡樹的區別,紅黑樹和B樹,B+樹的區別,Mysql二大引擎索引底層實現,HashMap在多執行緒環境中為何出錯,ConcurrentHashMap底層實現,CAS,原子參照,ABA問題,volatile,如何解決HashMap出現的OOM問題?(WeakHashMap) 什麼是Spring IOC,Spring AOP?應用場景有哪些?資料庫事務隔離級別,MySQL預設的隔離級別、Spring如何實現事務、傳播行為,分散式事務實現,分散式事務的四種解決方案,CAP,BASE Spring Bean的作用域和生命週期,Spring常用註解 23種設計模式 公平鎖,非公平鎖,可重入鎖,遞迴鎖,自旋鎖,讀寫鎖,悲觀鎖,樂觀鎖,行鎖,表鎖,死鎖,分散式鎖,執行緒同步鎖,排它鎖,共用鎖,Synchronized,Lock等 冪等性實現,單點登入,金額篡改問題 JVM演演算法,堆溢位,棧溢位,JMM記憶體模型,垃圾回收機制,垃圾回收器,引數調優,雙親委派機制 執行緒池實現原理,七大核心引數,JUC並行包:訊號燈,迴圈柵欄,倒計時器,集合類常見並行修改異常 SpringCould元件說七八個 Dubbo底層執行原理,支援的協定,支援的負載均衡策略,Zookeeper底層原理, zookeeper的選舉機制,同步機制,mongo es的 分片,Spring MVC工作原理,Mybatis框架優點 Redis快取資料結構,資料同步問題(雙刪策略),快取雪崩,快取穿透,熱點快取重構,快取失效,哨兵機制,持久化,redis 淘汰機制 Sql優化,索引限制條件,儲存過程限制條件 訊息丟失,訊息重複消費,訊息順序性,大規模訊息積壓問題,幾種訊息佇列的區別 Linux常用命令,生產環境伺服器變慢診斷,線上排查,效能評估。多執行緒、spring 擴充套件,資料庫底層,各大網際網路元件,底層機制,xx問題,如何排查。

技術亮點:

  • 熟練掌握常用的java集合以及多執行緒並行環境下集合類出現的並行修改異常。比如,寫時複製,CAS,ABA,Volatilte等。
  • 熟練掌握執行緒池底層實現原理並可根據實際業務場景設定合理的執行緒數以及拒絕策略。
  • 熟練掌握JUC並行包,比如:迴圈柵欄,訊號燈,倒計時器等。
  • 熟悉掌握Redis資料結構的使用場景,熟悉Redis快取高並行的使用場景。比如,快取雪崩,快取穿透。
  • 深入理解MySQL底層索引資料結構,B+ tree索引特點以及資料庫事務的隔離級別。 深入理解JVM底層原理,JMM記憶體模型,垃圾回收機制,GC演演算法,熟悉JVM各種垃圾回收器的使用以及核心引數調優。
  • 熟悉常見訊息中介軟體的使用,解決過各種訊息通訊場景的疑難問題。比如,訊息丟失,訊息重複消費。
  • 在專案中解決過各種分散式場景的技術難題,比如分散式鎖,分散式事務。 熟練掌握spring,spring mvc,mybatis,spring boot等開源框架。 深入理解spring could,zookeeper,dubbo等開源框架的底層架構。 熟練掌握Linux常用命令,生產環境伺服器變慢診斷,線上排查,效能評估。
java小丑 CSDN認證部落格專家 Java
我是廖志偉,一名java開發工程師,CSDN部落格專家,多年一線研發經驗,曾就職多家網際網路公司,任Java開發工程師職位,參與多個千萬級並行網際網路產品研發,對大型分散式,高並行及微服務架構有非常深入研究。