不管是開發、測試、運維，每個技術人員心裡都有一個成為技術大牛的夢，畢竟“夢想總是要有的，萬一實現了呢”！
正是對技術夢的追求，促使我們不斷地努力和提升自己。
今天分享Java重點面試知識 ：
多線程（線程狀態、線程併發，Synchronized與Lock的區別和底層原理，常用的鎖及其使用場景和原理，
volatile和ThreadLocal解決了什麼問題，CAS在Java中的實現
線程池原理和實現，阻塞隊列和線程安全隊列，
線程間通信: synchronized + wait、notify/notifyAll， Lock + Condition 的多路複用， CountDownLatch、CyclicBarrier和Semaphore的作用和用法，使用場景）
JVM內存管理機制和垃圾回收機制（內存模型、GC策略、算法、分代回收GC類型，Full GC、Minor GC作用範圍和觸發條件）
JVM內存調優（內存調整的6個參數，瞭解是怎麼回事，一般做項目過程中使用較多） 設計模式（熟悉常見設計模式的應用場景，會畫類圖，常用：代理，2個工廠，策略，單例，觀察者，適配器，組合與裝飾）
JAVA集合類框架（理解框架圖、HashMap、ArrayList、HashSet等的關係和區別，其中HashMap的存儲機制幾乎每次都有問）
HashMap的原理，底層數據結構，rehash的過程，指針碰撞問題HashMap的線程安全問題，為什麼會產生這樣的線程安全問題ConcurrentHashMap的數據結構，底層原理，put和get是否線程安全
JAVA的異常處理機制（異常的分類、常見的異常有哪些、Try catch finally的使用）
JVM運行機制（理解JVM是如何運行的，理解類加載機制和類的初始化順序）
Java 的NIO 3個主要概念 Channel、Buffer、Selector，為何提高了性能？加分項：熟悉
Netty
Linux基礎（面試筆試中對linux也有一定的要求，建議最好搭建一個linux虛擬機，並練習常用的命令）
框架
Spring
Spring IOC原理，Bean的生成和生命週期(工廠模式 + 反射生成 + 單例)，Spring用到的設計模式
Spring AOP原理和應用(動態代理與cglib代理，使用場景和代理的本質區別)
Spring如何處理高併發？高併發下，如何保證性能？
單例模式 + ThreadLocal
單例模式大大節省了對象的創建和銷燬，有利於性能提高，ThreadLocal用來保證線程安全性 Spring單例模式下，用ThreadLocal來切換不同線程直接的參數，用ThreadLocal是為了保證線程安全，實際上，ThreadLocal的key就是當前線程的Thread實例
單例模式下，Spring把每個線程可能存在線程安全問題的參數值放進了ThreadLocal，雖然是一個實例，但在不同線程下的數據是相互隔離的，
因為運行時創建和銷燬的bean大大減少了，所以大多數場景下，這種方式對內存資源的消耗較少，並且併發越高，優勢越明顯
特別注意：
Spring MVC的Controller不是線程安全的！！！
Spring MVC 是基於方法的攔截，粒度更細，而Spring的Controller默認是Singleton的，
即：每個request請求，系統都會用同一個Controller去處理
Spring MVC和Servlet都是方法級別的線程安全，如果單例的Controller或Servlet中存在實例變量，都是線程不安全的，而Struts2確實是線程安全的
優點：不用每次創建Controller，減少了對象創建和銷燬
缺點：Controller是單例的，Controller裡面的變量線程不安全
解決方案：
1.在Controller中使用ThreadLocal變量，把不安全的變量封裝進ThreadLocal，使用ThreadLocal來保存類變量，將類變量保存在線程的變量域中，讓不同的請求隔離開來
2.聲明Controller為原型 scope="prototype",每個請求都創建新的Controller
3.Controller中不使用實例變量
Spring 事務管理的使用和原理？事務的傳播屬性
聲明式事務管理，在Service之上或Service的方法之上，添加 @Transactional註解
@Transactional如何工作？
Spring在啟動時，會去解析生成相關的Bean，這是會查看擁有相關注解的類和方法，並且為這些類和方法生成代理，並根據 @Transactional的相關參數進行相關配置注入，這樣就在代理中把相關的事務處理掉了(開啟正常提交事務，異常回滾事務)真正的數據庫層，事務提交和回滾是通過binlog和redo log實現的
Spring如何解決對象的循環依賴引用？
( 只支持Singleton作用域的， setter方式的循環依賴！不支持構造器方式和prototype的循環依賴)
原理：
創建Bean A時，先通過無參構造器創建一個A實例，此時屬性都是空的，但對象引用已經創建創建出來，然後把Bean A的引用提前暴露出來，
然後setter B屬性時，創建B對象，此時同樣通過無參構造器，構造一個B對象的引用，並將B對象引用暴露出來。
接著B執行setter方法，去池中找到A(因為此時，A已經暴露出來，有指向該對象的引用了)，這樣依賴B就構造完成，也初始化完成，然後A接著初始化完成，循環依賴就這麼解決了！
總結：先創建對象引用，再通過setter()方式，給屬性賦值，層層創建對象 ！！！
Bean A初始化時，先對其依賴B進行初始化，同時，通過默認無參構造器，生成自己的引用，而不調用其setter()方法，
當B對象創建時，如果還依賴C，則也通過無參構造器，生成B的引用，
C對象創建時，如果引用了A，則去對象池中查到A的引用，然後調用setter()方式，注入A，完成C對象的創建
C創建完成後，B使用setter()方式，注入C，完成B對象創建
B對象場景完成後，A使用setter()方式，注入B，完成A對象創建
最終，完成setter()方式的循環依賴！
數據庫
InnoDB和MyISAM區別和選擇
1.InnoDB不支持FULLTEXT類型的索引。
2.InnoDB 中不保存表的具體行數，也就是說，執行select count() from table時，InnoDB要掃描一遍整個表來計算有多少行，但是MyISAM只要簡單的讀出保存好的行數即可。注意的是，當count()語句包含 where條件時，兩種表的操作是一樣的。
3.對於AUTO_INCREMENT類型的字段，InnoDB中必須包含只有該字段的索引，但是在MyISAM表中，可以和其他字段一起建立聯合索引。
4.DELETE FROM table時，InnoDB不會重新建立表，而是一行一行的刪除。
5.LOAD TABLE FROM MASTER操作對InnoDB是不起作用的，解決方法是首先把InnoDB表改成MyISAM表，導入數據後再改成InnoDB表，但是對於使用的額外的InnoDB特性（例如外鍵）的表不適用。
另外，InnoDB表的行鎖也不是絕對的，如果在執行一個SQL語句時MySQL不能確定要掃描的範圍，InnoDB表同樣會鎖全表，例如 ： update table set num=1 where name like “%aaa%”
任何一種表都不是萬能的，只用恰當的針對業務類型來選擇合適的表類型，才能最大的發揮MySQL的性能優勢。
悲觀鎖和樂觀鎖的含義：
悲觀鎖：真正的鎖，只允許一個線程操作同一條記錄， 樂觀鎖：一種衝突檢測機制，一般通過版本號或時間戳方式實現，對性能影響較小
索引使用及其索引原理(索引底層實現：B+樹)
Query查詢優化
1.explain sql查看執行效率，定位優化對象的性能瓶頸
2.永遠用小結果驅動大的結果集
3.儘可能在索引中完成排序
4.只取出自己需要的column，而不是*
5.使用最有效的過濾條件
6.用表連接代替子查詢
7.當只要一行數據時，使用limit 1
8.為搜索字段建立索引
9.千萬不要ORDER BY RAND()，避免select *
10.儘可能使用NOT NULL
11.開啟查詢緩存，併為查詢緩存優化查詢語句
eg:
<code>select username from user where add_time >= now()/<code>
注意：
1.這樣的語句不會使用查詢緩存，
2.像NOW()和RAND()或是其它的諸如此類的SQL函數都不會開啟查詢緩存，因為這些函數的返回是會不定的易變的。所以，你所需要的就是用一個變量來代替MySQL的函數，從而開啟緩存
3.修改, 對now()進行處理，只取年月日 yyyy-MM-dd，變為一個不衣變的值
Redis的5種數據結構和使用場景 Redis的持久化機制 Redis中Hash類型的底層2種實現區別(壓縮表: 省內存 和 跳躍表：查詢更快) Redis作為分佈式消息隊列使用，性能和注意點
數據結構和算法
常見的排序算法就不說了，需要理解其原理和會寫代碼，還有時間空間複雜度也要知道
隊列、棧：需要理解其存取結構，並能在某些場景下使用
二叉樹：樹的遍歷、樹的深度、按層次輸出、平衡二叉樹、逆序打印樹等
鏈表：逆序、合併兩有序的鏈表、判斷鏈表是否又環、鏈表倒數第K個元素等
字符串：KMP算法、動態規劃（這個是重點，需要好好理解動態規劃，常見的題有：求解最長迴文子串、求解最長公共子串等）
海量數據處理：現在好多大公司都會問海量數據的處理，所以需要掌握常見的處理方法，比如Bit-map、分而治之、hash映射等
常用算法
冒泡排序 快速排序 插入排序 希爾排序 歸併排序 堆排序 桶排序
動態規劃
最長公共子串 最長迴文子串 數組的最大k個值 數字的最大連續子數組之和
左旋轉字符串
字符串匹配算法:KMP算法 二分查找
鏈表
單鏈表逆序 兩個有序單鏈表合併 兩個單鏈表是否相交 相交處的節點 單鏈表倒數第K個數 單鏈表排序
棧和隊列
設計包含min函數的棧 兩個隊列實現棧 兩個棧實現隊列 一個數組實現棧和隊列
樹
前序、中序、後續遍歷 求二叉樹的深度 按層次遍歷二叉樹 判斷二叉樹是否為完全二叉樹 判斷二叉樹是否鏡面對稱 判斷兩顆樹是否相等
設計模式6大原則
單一職責原則(SRP)
定義：就一個類而言，應該僅有一個引起它變化的原因。
從這句定義我們很難理解它的含義，通俗講就是我們不要讓一個類承擔過多的職責。
如果一個類承擔的職責過多，就等於把這些職責耦合在一起，一個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。
這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到破壞。
比如我經常看到一些Android開發在Activity中寫Bean文件，網絡數據處理，如果有列表的話Adapter 也寫在Activity中，問他們為什麼除了好找也沒啥理由了，把他們拆分到其他類豈不是更好找，如果Activity過於臃腫行數過多，顯然不是好事，如果我們要修改Bean文件，網絡處理和Adapter都需要上這個Activity來修改，就會導致引起這個Activity變化的原因太多，我們在版本維護時也會比較頭疼。
也就嚴重違背了定義“就一個類而言，應該僅有一個引起它變化的原因”。
當然如果想爭論的話，這個模式是可以引起很多爭論的，但請記住一點，你寫代碼不只是為了你也是為了其他人。
開放封閉原則(ASD)
定義：類、模塊、函數等等等應該是可以拓展的，但是不可修改。
開放封閉有兩個含義，一個是對於拓展是開放的，另一個是對於修改是封閉的。
對於開發來說需求肯定是要變化的，但是新需求一來，我們就要把類重新改一遍這顯然是令人頭疼的，所以我們設計程序時面對需求的改變要儘可能的保證相對的穩定，儘量用新代碼實現拓展來修改需求，而不是通過修改原有的代碼來實現。
假設我們要實現一個列表，一開始只有查詢的功能，如果產品又要增加添加功能，過幾天又要增加刪除功能，大多數人的做法是寫個方法然後通過傳入不同的值來控制方法來實現不同的功能，但是如果又要新增功能我們還得修改我們的方法。
用開發封閉原則解決就是增加一個抽象的功能類，讓增加和刪除和查詢的作為這個抽象功能類的子類，這樣如果我們再添加功能，你會發現我們不需要修改原有的類，只需要添加一個功能類的子類實現功能類的方法就可以了。
3.里氏替換原則(LSP)
定義：所有引用基類（父類）的地方必須能透明地使用其子類的對象
里氏代換原則告訴我們，在軟件中將一個基類對象替換成它的子類對象，程序將不會產生任何錯誤和異常，反過來則不成立，如果一個軟件實體使用的是一個子類對象的話，那麼它不一定能夠使用基類對象。
里氏代換原則是實現開閉原則的重要方式之一，由於使用基類對象的地方都可以使用子類對象，因此在程序中儘量使用基類類型來對對象進行定義，而在運行時再確定其子類類型，用子類對象來替換父類對象。
在使用里氏代換原則時需要注意如下幾個問題：
子類的所有方法必須在父類中聲明，或子類必須實現父類中聲明的所有方法。
根據里氏代換原則，為了保證系統的擴展性，在程序中通常使用父類來進行定義，如果一個方法只存在子類中，在父類中不提供相應的聲明，則無法在以父類定義的對象中使用該方法。
我們在運用里氏代換原則時，儘量把父類設計為抽象類或者接口，讓子類繼承父類或實現父接口，並實現在父類中聲明的方法
運行時，子類實例替換父類實例，我們可以很方便地擴展系統的功能，同時無須修改原有子類的代碼，增加新的功能可以通過增加一個新的子類來實現。
里氏代換原則是開閉原則的具體實現手段之一。
Java語言中，在編譯階段，Java編譯器會檢查一個程序是否符合里氏代換原則，這是一個與實現無關的、純語法意義上的檢查，但Java編譯器的檢查是有侷限的。
4.依賴倒置原則(DIP)
定義：高層模塊不應該依賴低層模塊，兩個都應該依賴於抽象。抽象不應該依賴於細節，細節應該依賴於抽象。
在Java中，抽象就是指接口或者抽象類，兩者都是不能直接被實例化的；
細節就是實現類，實現接口或者繼承抽象類而產生的就是細節，也就是可以加上一個關鍵字new產生的對象。
高層模塊就是調用端，低層模塊就是具體實現類。
依賴倒置原則在Java中的表現就是：
模塊間通過抽象發生，實現類之間不發生直接依賴關係，其依賴關係是通過接口或者抽象類產生的。
如果類與類直接依賴細節，那麼就會直接耦合，那麼當修改時，就會同時修改依賴者代碼，這樣限制了可擴展性。
5.迪米特原則(LOD)
定義：一個軟件實體應當儘可能少地與其他實體發生相互作用。
也稱為最少知識原則。如果一個系統符合迪米特法則，那麼當其中某一個模塊發生修改時，就會盡量少地影響其他模塊，擴展會相對容易，這是對軟件實體之間通信的限制，迪米特法則要求限制軟件實體之間通信的寬度和深度。
迪米特法則可降低系統的耦合度，使類與類之間保持鬆散的耦合關係。
迪米特法則要求我們在設計系統時，應該儘量減少對象之間的交互，如果兩個對象之間不必彼此直接通信，那麼這兩個對象就不應當發生任何直接的相互作用，如果其中的一個對象需要調用另一個對象的某一個方法的話，可以通過第三者轉發這個調用。
簡言之，就是通過引入一個合理的第三者來降低現有對象之間的耦合度。
在將迪米特法則運用到系統設計中時，要注意下面的幾點：
在類的劃分上，應當儘量創建松耦合的類，類之間的耦合度越低，就越有利於複用，一個處在松耦合中的類一旦被修改，不會對關聯的類造成太大波及；
在類的結構設計上，每一個類都應當儘量降低其成員變量和成員函數的訪問權限；在類的設計上，只要有可能，一個類型應當設計成不變類；
在對其他類的引用上，一個對象對其他對象的引用應當降到最低。
6.接口隔離原則(ISP)
定義：一個類對另一個類的依賴應該建立在最小的接口上。 建立單一接口，不要建立龐大臃腫的接口，儘量細化接口，接口中的方法儘量少。
也就是說，我們要為各個類建立專用的接口，而不要試圖去建立一個很龐大的接口供所有依賴它的類去調用。
採用接口隔離原則對接口進行約束時，要注意以下幾點：
接口儘量小，但是要有限度。對接口進行細化可以提高程序設計靈活性，但是如果過小，則會造成接口數量過多，使設計複雜化。所以一定要適度。
為依賴接口的類定製服務，只暴露給調用的類它需要的方法，它不需要的方法則隱藏起來。只有專注地為一個模塊提供定製服務，才能建立最小的依賴關係。
提高內聚，減少對外交互。使接口用最少的方法去完成最多的事情。
concurrent包的實現基礎：
由於java的CAS同時具有 volatile 讀和volatile寫的內存語義，因此Java線程之間的通信現在有了下面四種方式：
A線程寫volatile變量，隨後B線程讀這個volatile變量。
A線程寫volatile變量，隨後B線程用CAS更新這個volatile變量。
A線程用CAS更新一個volatile變量，隨後B線程用CAS更新這個volatile變量。
A線程用CAS更新一個volatile變量，隨後B線程讀這個volatile變量。
Java的CAS會使用現代處理器上提供的高效機器級別原子指令，這些原子指令以原子方式對內存執行讀-改-寫操作，這是在多處理器中實現同步的關鍵（從本質上來說，能夠支持原子性讀-改-寫指令的計算機器，是順序計算圖靈機的異步等價機器，因此任何現代的多處理器都會去支持某種能對內存執行原子性讀-改-寫操作的原子指令）。
同時，volatile變量的讀/寫和CAS可以實現線程之間的通信。
把這些特性整合在一起，就形成了整個concurrent包得以實現的基石。
如果我們仔細分析concurrent包的源代碼實現，會發現一個通用化的實現模式：
首先，聲明共享變量為volatile；
然後，使用CAS的原子條件更新來實現線程之間的同步；
同時，配合以volatile的讀/寫和CAS所具有的volatile讀和寫的內存語義來實現線程之間的通信。
AQS，非阻塞數據結構和原子變量類（java.util.concurrent.atomic包中的類），這些concurrent包中的基礎類都是使用這種模式來實現的，而concurrent包中的高層類又是依賴於這些基礎類來實現的。
以上就是2020年最鮮出爐 一線互聯網公司Java高級面試題總結（含解析），下面展示了部分資料，希望也能幫助到大家，對編程感興趣的朋友，如果能幫到你請點贊、點贊、點贊：
整理的 pdf 文檔：
源碼分析專題部分課程：
獲取方式
點贊，收藏並轉發文章後點擊小編頭像或暱稱，關注後私信回覆：【11】 即可
舉手之勞，非常感謝！！！
閱讀更多 java架構師小旭 的文章
