Java後端技術面試彙總(第一套)

面試彙總，整理一波，doc文檔可點擊【 此處下載】

一、基礎篇

1.一、Java基礎

• 面向對象的特徵：繼承、封裝和多態
• final, finally, finalize 的區別
• Exception、Error、運行時異常與通常異常有何異同
• 請寫出5種常見到的runtime exception

常見的幾種以下： NullPointerException - 空指針引用異常 ClassCastException - 類型強制轉換異常。 IllegalArgumentException - 傳遞非法參數異常。 ArithmeticException - 算術運算異常 ArrayStoreException - 向數組中存放與聲明類型不兼容對象異常 IndexOutOfBoundsException - 下標越界異常 NegativeArraySizeException - 建立一個大小爲負數的數組錯誤異常 NumberFormatException - 數字格式異常 SecurityException - 安全異常 UnsupportedOperationException - 不支持的操做異常

• int 和 Integer 有什麼區別，Integer的值緩存範圍

-128到127

• 包裝類，裝箱和拆箱
• String、StringBuilder、StringBuffer
• 重載和重寫的區別
• 抽象類和接口有什麼區別
• 說說反射的用途及實現
• 說說自定義註解的場景及實現
• HTTP請求的GET與POST方式的區別
• Session與Cookie區別
• 列出本身經常使用的JDK包

java.lang： 這個是系統的基礎類，好比String等都是這裏面的，這個package是惟一一個能夠不用import就可使用的Package java.io: 這裏面是全部輸入輸出有關的類，好比文件操做等 java.net: 這裏面是與網絡有關的類，好比URL,URLConnection等。 java.util : 這個是系統輔助類，特別是集合類Collection,List,Map等。 java.sql: 這個是數據庫操做的類，Connection, Statememt，ResultSet等

• MVC設計思想
• equals與==的區別
• hashCode和equals方法的區別與聯繫
• 什麼是Java序列化和反序列化，如何實現Java序列化？或者請解釋Serializable 接口的做用
• Object類中常見的方法，爲何wait notify會放在Object裏邊？

這是個設計相關的問題。
回答這些問題要說明爲何把這些方法放在Object類裏是有意義的，還有不把它放在Thread類裏的緣由。
一個很明顯的緣由是JAVA提供的鎖是對象級而不是線程級的，每一個對象都有鎖，經過線程得到。若是線程須要等待某些鎖那麼調用對象中的wait()方法就有意義了。若是wait()方法定義在Thread類中，線程正在等待的是哪一個鎖就不明顯了。簡單的說，因爲wait，notify和notifyAll都是鎖級別的操做，因此把他們定義在Object類中由於鎖屬於對象。

• Java的平臺無關性如何體現出來的
• JDK和JRE的區別
• Java 8有哪些新特性(What's New in JDK 8)

Java8 新增了很是多的特性：
    1. Lambda 表達式 − Lambda容許把函數做爲一個方法的參數（函數做爲參數傳遞進方法中。 2. 方法引用 − 方法引用提供了很是有用的語法，能夠直接引用已有Java類或對象（實例）的方法或構造器。與lambda聯合使用，方法引用可使語言的構造更緊湊簡潔，減小冗餘代碼。 3. 默認方法 − 默認方法就是一個在接口裏面有了一個實現的方法。 4. 新工具 − 新的編譯工具，如：Nashorn引擎 jjs、 類依賴分析器jdeps。 5. Stream API −新添加的Stream API（java.util.stream） 把真正的函數式編程風格引入到Java中。 6. Date Time API − 增強對日期與時間的處理。 7. Optional 類 − Optional 類已經成爲 Java 8 類庫的一部分，用來解決空指針異常。 8. Nashorn, JavaScript 引擎 − Java 8提供了一個新的Nashorn javascript引擎，它容許咱們在JVM上運行特定的javascript應用。

1.二、Java常見集合

• List 和 Set 區別
• Set和hashCode以及equals方法的聯繫
• List 和 Map 區別
• Arraylist 與 LinkedList 區別
• ArrayList 與 Vector 區別
• HashMap 和 Hashtable 的區別
• HashSet 和 HashMap 區別
• HashMap 和 ConcurrentHashMap 的區別
• HashMap 的工做原理及代碼實現，何時用到紅黑樹
• 多線程狀況下HashMap死循環的問題
• HashMap出現Hash DOS攻擊的問題
• ConcurrentHashMap 的工做原理及代碼實現，如何統計全部的元素個數
• 手寫簡單的HashMap
• 看過那些Java集合類的源碼

1.三、進程和線程

• 線程和進程的概念、並行和併發的概念
Erlang 之父 Joe Armstrong 用一張5歲小孩都能看懂的圖解釋了併發與並行的區別

併發是兩個隊列交替使用一臺咖啡機，並行是兩個隊列同時使用兩臺咖啡機，若是串行，一個隊列使用一臺咖啡機，那麼哪怕前面那我的便祕了去廁所呆半天，後面的人也只能死等着他回來才能去接咖啡，這效率無疑是最低的。
併發是否是一個線程，並行是多個線程？
答：併發和並行均可以是不少個線程，就看這些線程能不能同時被（多個）cpu執行，若是能夠就說明是並行，而併發是多個線程被（一個）cpu 輪流切換着執行。
• 建立線程的方式及實現
• 進程間通訊的方式

常見的通訊方式：
1. 管道pipe：管道是一種半雙工的通訊方式，數據只能單向流動，並且只能在具備親緣關係的進程間使用。進程的親緣關係一般是指父子進程關係。 2. 命名管道FIFO：有名管道也是半雙工的通訊方式，可是它容許無親緣關係進程間的通訊。 4. 消息隊列MessageQueue：消息隊列是由消息的鏈表，存放在內核中並由消息隊列標識符標識。消息隊列克服了信號傳遞信息少、管道只能承載無格式字節流以及緩衝區大小受限等缺點。 5. 共享存儲SharedMemory：共享內存就是映射一段能被其餘進程所訪問的內存，這段共享內存由一個進程建立，但多個進程均可以訪問。共享內存是最快的 IPC 方式，它是針對其餘進程間通訊方式運行效率低而專門設計的。它每每與其餘通訊機制，如信號兩，配合使用，來實現進程間的同步和通訊。 6. 信號量Semaphore：信號量是一個計數器，能夠用來控制多個進程對共享資源的訪問。它常做爲一種鎖機制，防止某進程正在訪問共享資源時，其餘進程也訪問該資源。所以，主要做爲進程間以及同一進程內不一樣線程之間的同步手段。 7. 套接字Socket：套解口也是一種進程間通訊機制，與其餘通訊機制不一樣的是，它可用於不一樣及其間的進程通訊。 8. 信號 ( sinal ) ： 信號是一種比較複雜的通訊方式，用於通知接收進程某個事件已經發生。

• 說說 CountDownLatch、CyclicBarrier 原理和區別
• 說說 Semaphore 原理
• 說說 Exchanger 原理
• ThreadLocal 原理分析，ThreadLocal爲何會出現OOM，出現的深層次原理

線程池的一個線程使用完ThreadLocal對象以後，不再用，因爲線程池中的線程不會退出，線程池中的線程的存在，同時ThreadLocal變量也會存在，佔用內存！形成OOM溢出！

ThreadLocal的實現是這樣的：每一個Thread 維護一個 ThreadLocalMap 映射表，這個映射表的 key 是 ThreadLocal實例自己，value 是真正須要存儲的 Object。 也就是說 ThreadLocal 自己並不存儲值，它只是做爲一個 key 來讓線程從 ThreadLocalMap 獲取 value。值得注意的是圖中的虛線，表示 ThreadLocalMap 是使用 ThreadLocal 的弱引用做爲 Key 的，弱引用的對象在 GC 時會被回收。 ThreadLocalMap使用ThreadLocal的弱引用做爲key，若是一個ThreadLocal沒有外部強引用來引用它，那麼系統 GC 的時候，這個ThreadLocal勢必會被回收，這樣一來，ThreadLocalMap中就會出現key爲null的Entry，就沒有辦法訪問這些key爲null的Entry的value，若是當前線程再遲遲不結束的話，這些key爲null的Entry的value就會一直存在一條強引用鏈：Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value永遠沒法回收，形成內存泄漏。 總的來講就是，ThreadLocal裏面使用了一個存在弱引用的map, map的類型是ThreadLocal.ThreadLocalMap. Map中的key爲一個threadlocal實例。這個Map的確使用了弱引用，不過弱引用只是針對key。每一個key都弱引用指向threadlocal。 當把threadlocal實例置爲null之後，沒有任何強引用指向threadlocal實例，因此threadlocal將會被gc回收。 可是，咱們的value卻不能回收，而這塊value永遠不會被訪問到了，因此存在着內存泄露。 參考:https://blog.csdn.net/bntx2jsqfehy7/article/details/78315161

• 講講線程池的實現原理

java線程池的實現原理說白了就是一個線程集合workerSet和一個阻塞隊列workQueue。當用戶向線程池提交一個任務(也就是線程)時，線程池會先將任務放入workQueue中。workerSet中的線程會不斷的從workQueue中獲取線程而後執行。當workQueue中沒有任務的時候，worker就會阻塞，直到隊列中有任務了就取出來繼續執行。
線程池的幾個主要參數的做用

    public ThreadPoolExecutor(int corePoolSize,
                              int maximumPoolSize,
                              long keepAliveTime,
                              TimeUnit unit,
                              BlockingQueue<Runnable> workQueue,
                              ThreadFactory threadFactory,
                              RejectedExecutionHandler handler) 

corePoolSize: 規定線程池有幾個線程(worker)在運行。(the number of threads to keep in the pool, even if they are idle, unless {@code allowCoreThreadTimeOut} is set) maximumPoolSize: 當workQueue滿了,不能添加任務的時候，這個參數纔會生效。規定線程池最多隻能有多少個線程(worker)在執行。(the maximum number of threads to allow in the pool) keepAliveTime: 超出corePoolSize大小的那些線程的生存時間,這些線程若是長時間沒有執行任務而且超過了keepAliveTime設定的時間，就會消亡。(when the number of threads is greater than the core, this is the maximum time that excess idle threads will wait for new tasks before terminating.) unit: 生存時間對於的單位(the time unit for the {@code keepAliveTime} argument) workQueue: 存聽任務的隊列(the queue to use for holding tasks before they are executed. This queue will hold only the {@code Runnable} tasks submitted by the {@code execute} method.) threadFactory: 建立線程的工廠(the factory to use when the executor creates a new thread) handler: 當workQueue已經滿了，而且線程池線程數已經達到maximumPoolSize，將執行拒絕策略。(the handler to use when execution is blocked because the thread bounds and queue capacities are reached) 任務提交後的流程分析 用戶經過submit提交一個任務。線程池會執行以下流程: 1. 判斷當前運行的worker數量是否超過corePoolSize,若是不超過corePoolSize。就建立一個worker直接執行該任務。—— 線程池最開始是沒有worker在運行的 2. 若是正在運行的worker數量超過或者等於corePoolSize,那麼就將該任務加入到workQueue隊列中去。 3. 若是workQueue隊列滿了,也就是offer方法返回false的話，就檢查當前運行的worker數量是否小於maximumPoolSize,若是小於就建立一個worker直接執行該任務。 4. 若是當前運行的worker數量是否大於等於maximumPoolSize，那麼就執行RejectedExecutionHandler來拒絕這個任務的提交。 

• 線程池的幾種實現方式
• 線程的生命週期，狀態是如何轉移的
• 可參考：《Java多線程編程核心技術》

1.四、鎖機制

• 說說線程安全問題，什麼是線程安全，如何保證線程安全

與鎖相似的是同步方法或者同步代碼塊。使用非靜態同步方法時，鎖住的是當前實例；使用靜態同步方法時，鎖住的是該類的Class對象；使用靜態代碼塊時，鎖住的是synchronized關鍵字後面括號內的對象

• 重入鎖的概念，重入鎖爲何能夠防止死鎖

可重入鎖，指的是以線程爲單位，當一個線程獲取對象鎖以後，這個線程能夠再次獲取本對象上的鎖，而其餘的線程是不能夠的。

synchronized 和 ReentrantLock 都是可重入鎖。 可重入鎖的意義之一在於防止死鎖。 實現原理實現是經過爲每一個鎖關聯一個請求計數器和一個佔有它的線程。當計數爲0時，認爲鎖是未被佔有的；線程請求一個未被佔有的鎖時，JVM將記錄鎖的佔有者，而且將請求計數器置爲1 。 若是同一個線程再次請求這個鎖，計數器將遞增； 每次佔用線程退出同步塊，計數器值將遞減。直到計數器爲0,鎖被釋放。

• 產生死鎖的四個條件（互斥、請求與保持、不剝奪、循環等待）
• 如何檢查死鎖（經過jConsole檢查死鎖）
• volatile 實現原理（禁止指令重排、刷新內存）
• synchronized 實現原理（對象監視器）

• synchronized 與 lock 的區別

二者區別：

1.首先synchronized是java內置關鍵字，在jvm層面，Lock是個java類； 2.synchronized沒法判斷是否獲取鎖的狀態，Lock能夠判斷是否獲取到鎖； 3.synchronized會自動釋放鎖(a 線程執行完同步代碼會釋放鎖 ；b 線程執行過程當中發生異常會釋放鎖)，Lock需在finally中手工釋放鎖（unlock()方法釋放鎖），不然容易形成線程死鎖； 4.用synchronized關鍵字的兩個線程1和線程2，若是當前線程1得到鎖，線程2線程等待。若是線程1阻塞，線程2則會一直等待下去，而Lock鎖就不必定會等待下去，若是嘗試獲取不到鎖，線程能夠不用一直等待就結束了； 5.synchronized的鎖可重入、不可中斷、非公平，而Lock鎖可重入、可判斷、可公平（二者皆可） 6.Lock鎖適合大量同步的代碼的同步問題，synchronized鎖適合代碼少許的同步問題。

• AQS同步隊列
• CAS無鎖的概念、樂觀鎖和悲觀鎖
• 常見的原子操做類
• 什麼是ABA問題，出現ABA問題JDK是如何解決的
• 樂觀鎖的業務場景及實現方式
• Java 8並法包下常見的併發類
• 偏向鎖、輕量級鎖、重量級鎖、自旋鎖的概念

偏向鎖
偏向鎖是Java 6以後加入的新鎖，它是一種針對加鎖操做的優化手段，通過研究發現，在大多數狀況下，鎖不只不存在多線程競爭，並且老是由同一線程屢次得到，所以爲了減小同一線程獲取鎖(會涉及到一些CAS操做,耗時)的代價而引入偏向鎖。偏向鎖的核心思想是，若是一個線程得到了鎖，那麼鎖就進入偏向模式，此時Mark Word 的結構也變爲偏向鎖結構，當這個線程再次請求鎖時，無需再作任何同步操做，即獲取鎖的過程，這樣就省去了大量有關鎖申請的操做，從而也就提供程序的性能。因此，對於沒有鎖競爭的場合，偏向鎖有很好的優化效果，畢竟極有可能連續屢次是同一個線程申請相同的鎖。可是對於鎖競爭比較激烈的場合，偏向鎖就失效了，由於這樣場合極有可能每次申請鎖的線程都是不相同的，所以這種場合下不該該使用偏向鎖，不然會得不償失，須要注意的是，偏向鎖失敗後，並不會當即膨脹爲重量級鎖，而是先升級爲輕量級鎖。 輕量級鎖 假若偏向鎖失敗，虛擬機並不會當即升級爲重量級鎖，它還會嘗試使用一種稱爲輕量級鎖的優化手段(1.6以後加入的)，此時Mark Word 的結構也變爲輕量級鎖的結構。輕量級鎖可以提高程序性能的依據是「對絕大部分的鎖，在整個同步週期內都不存在競爭」，注意這是經驗數據。須要瞭解的是，輕量級鎖所適應的場景是線程交替執行同步塊的場合，若是存在同一時間訪問同一鎖的場合，就會致使輕量級鎖膨脹爲重量級鎖。 重量級鎖 內置鎖在Java中被抽象爲監視器鎖（monitor）。在JDK 1.6以前，監視器鎖能夠認爲直接對應底層操做系統中的互斥量（mutex）。這種同步方式的成本很是高，包括系統調用引發的內核態與用戶態切換、線程阻塞形成的線程切換等。所以，後來稱這種鎖爲「重量級鎖」 自旋鎖 輕量級鎖失敗後，虛擬機爲了不線程真實地在操做系統層面掛起，還會進行一項稱爲自旋鎖的優化手段。這是基於在大多數狀況下，線程持有鎖的時間都不會太長，若是直接掛起操做系統層面的線程可能會得不償失，畢竟操做系統實現線程之間的切換時須要從用戶態轉換到核心態，這個狀態之間的轉換須要相對比較長的時間，時間成本相對較高，所以自旋鎖會假設在不久未來，當前的線程能夠得到鎖，所以虛擬機會讓當前想要獲取鎖的線程作幾個空循環(這也是稱爲自旋的緣由)，通常不會過久，多是50個循環或100循環，在通過若干次循環後，若是獲得鎖，就順利進入臨界區。若是還不能得到鎖，那就會將線程在操做系統層面掛起，這就是自旋鎖的優化方式，這種方式確實也是能夠提高效率的。最後沒辦法也就只能升級爲重量級鎖了。 

• 可參考：《Java多線程編程核心技術》

1.五、JVM

• JVM運行時內存區域劃分
• 內存溢出OOM和堆棧溢出SOE的示例及緣由、如何排查與解決
• 如何判斷對象是否能夠回收或存活
• 常見的GC回收算法及其含義
• 常見的JVM性能監控和故障處理工具類：jps、jstat、jmap、jinfo、jconsole等
• JVM如何設置參數
• JVM性能調優
• 類加載器、雙親委派模型、一個類的生命週期、類是如何加載到JVM中的
• 類加載的過程：加載、驗證、準備、解析、初始化
• 強引用、軟引用、弱引用、虛引用
• Java內存模型JMM

1.六、設計模式

• 常見的設計模式
• 設計模式的的六大原則及其含義
• 常見的單例模式以及各類實現方式的優缺點，哪種最好，手寫常見的單例模式
• 設計模式在實際場景中的應用
• Spring中用到了哪些設計模式
• MyBatis中用到了哪些設計模式
• 你項目中有使用哪些設計模式
• 說說經常使用開源框架中設計模式使用分析
• 動態代理很重要！！！

1.七、數據結構

• 樹（二叉查找樹、平衡二叉樹、紅黑樹、B樹、B+樹）
• 深度有限算法、廣度優先算法
• 克魯斯卡爾算法、普林母算法、迪克拉斯算法
• 什麼是一致性Hash及其原理、Hash環問題

https://blog.csdn.net/bntX2jSQfEHy7/article/details/79549368 一致性Hash算法是對2^32取模,將服務節點對2^32取模放入hash環上，而後將數據key使用相同的函數Hash計算出哈希值，並肯定此數據在環上的位置，今後位置沿環順時針「行走」，第一臺遇到的服務器就是其應該定位到的服務器！ 問題： 一致性Hash算法在服務節點太少時，容易由於節點分部不均勻而形成數據傾斜（被緩存的對象大部分集中緩存在某一臺服務器上）問題。 解決方法： 爲了解決數據傾斜問題，一致性Hash算法引入了虛擬節點機制，即對每個服務節點計算多個哈希，每一個計算結果位置都放置一個此服務節點，稱爲虛擬節點。具體作法能夠在服務器IP或主機名的後面增長編號來實現。同時數據定位算法不變，只是多了一步虛擬節點到實際節點的映射。

• 常見的排序算法和查找算法：快排、折半查找、堆排序等

1.八、網絡/IO基礎

• BIO、NIO、AIO的概念
• 什麼是長鏈接和短鏈接
• Http1.0和2.0相比有什麼區別，可參考《Http 2.0》
• Https的基本概念
• 三次握手和四次揮手、爲何揮手須要四次

爲何要四次揮手呢 TCP協議是一種面向鏈接的、可靠的、基於字節流的運輸層通訊協議。TCP是全雙工模式，這就意味着，當 Client 發出FIN報文段時，只是表示 Client 已經沒有數據要發送了， Client 告訴 Server，它的數據已經所有發送完畢了；可是，這個時候 Client 仍是能夠接受來自 Server 的數據；當 Server 返回ACK報文段時，表示它已經知道 Client 沒有數據發送了， 可是 Server 仍是能夠發送數據到 Client 的；當 Server 也發送了FIN報文段時，這個時候就表示 Server 也沒有數據要發送了，就會告訴 Client ，我也沒有數據要發送了， 以後彼此就會愉快的中斷此次TCP鏈接。若是要正確的理解四次分手的原理，就須要瞭解四次分手過程當中的狀態變化。

• 從瀏覽器中輸入URL到頁面加載的發生了什麼？可參考《從輸入URL到頁面加載發生了什麼》

二、數據存儲和消息隊列

2.一、數據庫

• MySQL 索引使用的注意事項
• DDL、DML、DCL分別指什麼
• explain命令
• left join，right join，inner join
• 數據庫事物ACID（原子性、一致性、隔離性、持久性）

Atomicity 原子性 Consistency 一致性 Isolation 隔離性 Durability 持久性

• 事物的隔離級別（讀未提交、讀以提交、可重複讀、可序列化讀）
• 髒讀、幻讀、不可重複讀
• 數據庫的幾大範式
• 數據庫常見的命令
• 說說分庫與分表設計
• 分庫與分錶帶來的分佈式困境與應對之策（如何解決分佈式下的分庫分表，全局表？）
• 說說 SQL 優化之道
• MySQL遇到的死鎖問題、如何排查與解決
• 存儲引擎的 InnoDB與MyISAM區別，優缺點，使用場景
• 索引類別（B+樹索引、全文索引、哈希索引）、索引的原理
• 什麼是自適應哈希索引（AHI）
• 爲何要用 B+tree做爲MySQL索引的數據結構
• 彙集索引與非彙集索引的區別
• 遇到過索引失效的狀況沒，何時可能會出現，如何解決
• limit 20000 加載很慢怎麼解決
• 如何選擇合適的分佈式主鍵方案
• 選擇合適的數據存儲方案
• 常見的幾種分佈式ID的設計方案
• 常見的數據庫優化方案，在你的項目中數據庫如何進行優化的

2.二、Redis

• Redis 有哪些數據類型，可參考《Redis常見的5種不一樣的數據類型詳解》
• Redis 內部結構
• Redis 使用場景
• Redis 持久化機制，可參考《使用快照和AOF將Redis數據持久化到硬盤中》
• Redis 集羣方案與實現
• Redis 爲何是單線程的？

一、徹底基於內存，絕大部分請求是純粹的內存操做，很是快速。數據存在內存中，相似於HashMap，HashMap的優點就是查找和操做的時間複雜度都是O(1)；

二、數據結構簡單，對數據操做也簡單，Redis中的數據結構是專門進行設計的；

三、採用單線程，避免了沒必要要的上下文切換和競爭條件，也不存在多進程或者多線程致使的切換而消耗 CPU，不用去考慮各類鎖的問題，不存在加鎖釋放鎖操做，沒有由於可能出現死鎖而致使的性能消耗；

四、使用多路I/O複用模型，非阻塞IO；

五、使用底層模型不一樣，它們之間底層實現方式以及與客戶端之間通訊的應用協議不同，Redis直接本身構建了VM 機制 ，由於通常的系統調用系統函數的話，會浪費必定的時間去移動和請求；

• 緩存雪崩、緩存穿透、緩存預熱、緩存更新、緩存降級

緩存雪崩：全部緩存在同一時間內失效，全部本來應該訪問緩存的請求都去查詢數據庫了，而對數據庫CPU和內存形成巨大壓力，嚴重的會形成數據庫宕機。從而造成一系列連鎖反應，形成整個系統崩潰。簡單方案就時講緩存失效時間分散開，好比咱們能夠在原有的失效時間基礎上增長一個隨機值，好比1-5分鐘隨機，這樣每個緩存的過時時間的重複率就會下降，就很難引起集體失效的事件。

緩存穿透是指用戶查詢數據，在數據庫沒有，天然在緩存中也不會有。這樣就致使用戶查詢的時候，在緩存中找不到，每次都要去數據庫再查詢一遍，而後返回空（至關於進行了兩次無用的查詢）。這樣請求就繞過緩存直接查數據庫，這也是常常提的緩存命中率問題。有不少種方法能夠有效地解決緩存穿透問題，最多見的則是採用布隆過濾器，將全部可能存在的數據哈希到一個足夠大的bitmap中，一個必定不存在的數據會被這個bitmap攔截掉，從而避免了對底層存儲系統的查詢壓力。

緩存預熱就是系統上線後，將相關的緩存數據直接加載到緩存系統。這樣就能夠避免在用戶請求的時候，先查詢數據庫，而後再將數據緩存的問題！用戶直接查詢事先被預熱的緩存數據！
解決思路：
一、直接寫個緩存刷新頁面，上線時手工操做下；
二、數據量不大，能夠在項目啓動的時候自動進行加載；
三、定時刷新緩存；

• 使用緩存的合理性問題
• Redis常見的回收策略

volatile-lru：從已設置過時時間的數據集（server.db[i].expires）中挑選最近最少使用的數據淘汰 volatile-ttl：從已設置過時時間的數據集（server.db[i].expires）中挑選將要過時的數據淘汰 volatile-random：從已設置過時時間的數據集（server.db[i].expires）中任意選擇數據淘汰 allkeys-lru：從數據集（server.db[i].dict）中挑選最近最少使用的數據淘汰 allkeys-random：從數據集（server.db[i].dict）中任意選擇數據淘汰 no-enviction（驅逐）：禁止驅逐數據

2.三、消息隊列

• 消息隊列的使用場景
• 消息的重發補償解決思路
• 消息的冪等性解決思路
• 消息的堆積解決思路
• 本身如何實現消息隊列
• 如何保證消息的有序性

三、開源框架和容器

3.一、SSM/Servlet

• Servlet的生命週期
• 轉發與重定向的區別
• BeanFactory 和 ApplicationContext 有什麼區別
• Spring Bean 的生命週期
• Spring IOC 如何實現
• Spring中Bean的做用域，默認的是哪個
• 說說 Spring AOP、Spring AOP 實現原理
• 動態代理（CGLib 與 JDK）、優缺點、性能對比、如何選擇
• Spring 事務實現方式、事務的傳播機制、默認的事務類別
• Spring 事務底層原理
• Spring事務失效（事務嵌套），JDK動態代理給Spring事務埋下的坑，可參考《JDK動態代理給Spring事務埋下的坑！》
• 如何自定義註解實現功能
• Spring MVC 運行流程
• Spring MVC 啓動流程
• Spring 的單例實現原理
• Spring 框架中用到了哪些設計模式
• Spring 其餘產品（Srping Boot、Spring Cloud、Spring Secuirity、Spring Data、Spring AMQP 等）
• 有沒有用到Spring Boot，Spring Boot的認識、原理
• MyBatis的原理

https://www.cnblogs.com/luoxn28/p/6417892.html https://blog.csdn.net/u014297148/article/details/78696096

• 可參考《爲何會有Spring》
• 可參考《爲何會有Spring AOP》

3.二、Netty

• 爲何選擇 Netty
• 說說業務中，Netty 的使用場景
• 原生的 NIO 在 JDK 1.7 版本存在 epoll bug
• 什麼是TCP 粘包/拆包

TCP粘包：socket讀取時，讀到了實際意義上的兩個或多個數據包的內容，同時將其做爲一個數據包進行處理。 TCP拆包：socket讀取時，沒有完整地讀取一個數據包，只讀取一部分。

• TCP粘包/拆包的解決辦法

1.數據段定長處理，位數不足的空位補齊。
2.消息頭+消息體，消息頭中通常會包含消息體的長度，消息類型等信息，消息體爲實際數據體。
3.特殊字符（如：回車符）做爲消息數據的結尾，以實現消息數據的分段。
4.複雜的應用層協議，這種方式使用的相對較少，耦合了網絡層與應用層。

• Netty 線程模型
• 說說 Netty 的零拷貝
• Netty 內部執行流程
• Netty 重連實現

3.三、Tomcat

• Tomcat的基礎架構（Server、Service、Connector、Container）
• Tomcat如何加載Servlet的
• Pipeline-Valve機制
• 可參考：《四張圖帶你瞭解Tomcat系統架構！》

四、分佈式

4.一、Nginx

• 請解釋什麼是C10K問題或者知道什麼是C10K問題嗎？
• Nginx簡介，可參考《Nginx簡介》
• 正向代理和反向代理.
• Nginx幾種常見的負載均衡策略
• Nginx服務器上的Master和Worker進程分別是什麼
• 使用「反向代理服務器」的優勢是什麼?

4.二、分佈式其餘

• 談談業務中使用分佈式的場景
• Session 分佈式方案
• Session 分佈式處理
• 分佈式鎖的應用場景、分佈式鎖的產生緣由、基本概念
• 分佈是鎖的常看法決方案
• 分佈式事務的常看法決方案
• 集羣與負載均衡的算法與實現
• 說說分庫與分表設計，可參考《數據庫分庫分表策略的具體實現方案》
• 分庫與分錶帶來的分佈式困境與應對之策

4.三、Dubbo

• 什麼是Dubbo，可參考《Dubbo入門》
• 什麼是RPC、如何實現RPC、RPC 的實現原理，可參考《基於HTTP的RPC實現》
• Dubbo中的SPI是什麼概念
• Dubbo的基本原理、執行流程

五、微服務

5.一、微服務

• 先後端分離是如何作的？
• 微服務哪些框架
• Spring Could的常見組件有哪些？可參考《Spring Cloud概述》
• 領域驅動有了解嗎？什麼是領域驅動模型？充血模型、貧血模型
• JWT有了解嗎，什麼是JWT，可參考《先後端分離利器之JWT》
• 你怎麼理解 RESTful
• 說說如何設計一個良好的 API
• 如何理解 RESTful API 的冪等性
• 如何保證接口的冪等性
• 說說 CAP 定理、BASE 理論

BASE是Basically Available（基本可用）、Soft state（軟狀態）和Eventually consistent（最終一致性）三個短語的簡寫，BASE是對CAP中一致性和可用性權衡的結果，其來源於對大規模互聯網系統分佈式實踐的結論，是基於CAP定理逐步演化而來的，其核心思想是即便沒法作到強一致性（Strong consistency），但每一個應用均可以根據自身的業務特色，採用適當的方式來使系統達到最終一致性（Eventual consistency）。接下來咱們着重對BASE中的三要素進行詳細講解。 基本可用 基本可用是指分佈式系統在出現不可預知故障的時候，容許損失部分可用性——但請注意，這毫不等價於系統不可用，如下兩個就是「基本可用」的典型例子。 響應時間上的損失：正常狀況下，一個在線搜索引擎須要0.5秒內返回給用戶相應的查詢結果，但因爲出現異常（好比系統部分機房發生斷電或斷網故障），查詢結果的響應時間增長到了1~2秒。 功能上的損失：正常狀況下，在一個電子商務網站上進行購物，消費者幾乎可以順利地完成每一筆訂單，可是在一些節日大促購物高峯的時候，因爲消費者的購物行爲激增，爲了保護購物系統的穩定性，部分消費者可能會被引導到一個降級頁面。 弱狀態也稱爲軟狀態，和硬狀態相對，是指容許系統中的數據存在中間狀態，並認爲該中間狀態的存在不會影響系統的總體可用性，即容許系統在不一樣節點的數據副本之間進行數據聽不的過程存在延時。 最終一致性 最終一致性強調的是系統中全部的數據副本，在通過一段時間的同步後，最終可以達到一個一致的狀態。所以，最終一致性的本質是須要系統保證最終數據可以達到一致，而不須要實時保證系統數據的強一致性 亞馬遜首席技術官Werner Vogels在於2008年發表的一篇文章中對最終一致性進行了很是詳細的介紹。他認爲最終一致性時一種特殊的弱一致性：系統可以保證在沒有其餘新的更新操做的狀況下，數據最終必定可以達到一致的狀態，所以全部客戶端對系統的數據訪問都可以胡渠道最新的值。同時，在沒有發生故障的前提下，數據達到一致狀態的時間延遲，取決於網絡延遲，系統負載和數據複製方案設計等因素。 在實際工程實踐中，最終一致性存在如下五類主要變種。 因果一致性： 因果一致性是指，若是進程A在更新完某個數據項後通知了進程B，那麼進程B以後對該數據項的訪問都應該可以獲取到進程A更新後的最新值，而且若是進程B要對該數據項進行更新操做的話，務必基於進程A更新後的最新值，即不能發生丟失更新狀況。與此同時，與進程A無因果關係的進程C的數據訪問則沒有這樣的限制。 讀己之所寫： 讀己之所寫是指，進程A更新一個數據項以後，它本身老是可以訪問到更新過的最新值，而不會看到舊值。也就是說，對於單個數據獲取者而言，其讀取到的數據必定不會比本身上次寫入的值舊。所以，讀己之所寫也能夠看做是一種特殊的因果一致性。 會話一致性： 會話一致性將對系統數據的訪問過程框定在了一個會話當中：系統能保證在同一個有效的會話中實現「讀己之所寫」的一致性，也就是說，執行更新操做以後，客戶端可以在同一個會話中始終讀取到該數據項的最新值。 單調讀一致性： 單調讀一致性是指若是一個進程從系統中讀取出一個數據項的某個值後，那麼系統對於該進程後續的任何數據訪問都不該該返回更舊的值。 單調寫一致性： 單調寫一致性是指，一個系統須要可以保證來自同一個進程的寫操做被順序地執行。 以上就是最終一致性的五類常見的變種，在時間系統實踐中，能夠將其中的若干個變種互相結合起來，以構建一個具備最終一致性的分佈式系統。事實上，能夠將其中的若干個變種相互結合起來，以構建一個具備最終一致性特性的分佈式系統。事實上，最終一致性並非只有那些大型分佈式系統才設計的特性，許多現代的關係型數據庫都採用了最終一致性模型。在現代關係型數據庫中，大多都會採用同步和異步方式來實現主備數據複製技術。在同步方式中，數據的複製國恥鞥一般是更新事務的一部分，所以在事務完成後，主備數據庫的數據就會達到一致。而在異步方式中，備庫的更新每每存在延時，這取決於事務日誌在主備數據庫之間傳輸的時間長短，若是傳輸時間過長或者甚至在日誌傳輸過程當中出現異常致使沒法及時將事務應用到備庫上，那麼狠顯然，從備庫中讀取的的數據將是舊的，所以就出現了不一致的狀況。固然，不管是採用屢次重試仍是認爲數據訂正，關係型數據庫仍是能搞保證最終數據達到一致——這就是系統提供最終一致性保證的經典案例。 總的來講，BASE理論面向的是大型高可用可擴展的分佈式系統，和傳統事務的ACID特性使相反的，它徹底不一樣於ACID的強一致性模型，而是提出經過犧牲強一致性來得到可用性，並容許數據在一段時間內是不一致的，但最終達到一致狀態。但同時，在實際的分佈式場景中，不一樣業務單元和組件對數據一致性的要求是不一樣的，所以在具體的分佈式系統架構設計過程當中，ACID特性與BASE理論每每又會結合在一塊兒使用。

• 怎麼考慮數據一致性問題
• 說說最終一致性的實現方案
• 微服務的優缺點，可參考《微服務批判》
• 微服務與 SOA 的區別
• 如何拆分服務、水平分割、垂直分割
• 如何應對微服務的鏈式調用異常
• 如何快速追蹤與定位問題
• 如何保證微服務的安全、認證

5.二、安全問題

• 如何防範常見的Web攻擊、如何方式SQL注入
• 服務端通訊安全攻防
• HTTPS原理剖析、降級攻擊、HTTP與HTTPS的對比

5.三、性能優化

• 性能指標有哪些
• 如何發現性能瓶頸
• 性能調優的常見手段
• 說說你在項目中如何進行性能調優

六、其餘

6.一、設計能力

• 說說你在項目中使用過的UML圖
• 你如何考慮組件化、服務化、系統拆分
• 秒殺場景如何設計
• 可參考：《秒殺系統的技術挑戰、應對策略以及架構設計總結一二！》

6.二、業務工程

• 說說你的開發流程、如何進行自動化部署的
• 你和團隊是如何溝通的
• 你如何進行代碼評審
• 說說你對技術與業務的理解
• 說說你在項目中遇到感受最難Bug，是如何解決的
• 介紹一下工做中的一個你認爲最有價值的項目，以及在這個過程當中的角色、解決的問題、你以爲大家項目還有哪些不足的地方

6.三、軟實力

• 說說你的優缺點、亮點• 說說你最近在看什麼書、什麼博客、在研究什麼新技術、再看那些開源項目的源代碼• 說說你以爲最有意義的技術書籍• 工做之餘作什麼事情、平時是如何學習的，怎樣提高本身的能力• 說說我的發展方向方面的思考• 說說你認爲的服務端開發工程師應該具有哪些能力• 說說你認爲的架構師是什麼樣的，架構師主要作什麼• 如何看待加班的問題