複習 2 個月拿下大廠 Offer，Java 面試指南帶你通關跳槽季

去年的這個時候，筆者經過兩個月的複習拿到了阿里巴巴的 Offer，有一些運氣，也有一些心得，藉着跳槽季來臨特此分享出來。本文既是複習思路，亦可當作學習思路。

我大體把 Java 的複習分爲以下幾個方向。

JVM

JVM 是每個開發人員必備的技能，推薦看國內比較經典的 JVM 書籍，裏面包含 JVM 的內存接口、類的加載機制等基礎知識，是否是以爲這些在面試中似曾相識？因此對於 JVM 方面的知識鞏固與其在網上看一些零零碎碎的文章不如啃一下《深刻理解 Java 虛擬機：JVM 高級特性與最佳實踐(第 2 版)》這本書，固然若是你的英文好則強烈推薦看 Oracle 最新發布的 JAVA 虛擬機規範。

在啃書的時候切記不能圖快，你對知識的積累不是經過看書的數量來決定，而是看書的深度。因此在看每一章節的時候看到不懂的要配合網上的文章理解，而且須要看幾篇文章理解，由於一篇文章極可能是錯誤的。

排序算法和 Java 集合、工具類

這一個分類是每個人必須掌握並熟練使用的，那麼爲何我把它們放在一塊兒呢？

由於工具和集合類都源於算法，在準備算法複習以前你要理解，爲何要必考算法——正是由於排序算法和咱們編程息息相關。舉兩個「栗子」：

你能夠看一下Collections 中的MergeSort和sort 方法，你會發現 MergeSort 就是歸併排序的實現，而 sort 方法結合了歸併排序和插入排序，這樣使得 sort 方法最差 O(NlogN) 最好能夠達到 O(N) 的效果。那麼只有你本身理解了排序方法的實現，才能更好地使用 Java 中的集合類。

第二個「栗子」，你們都聽聞過 TopN 問題吧，常常在面試中遇到請寫一下 TopN 的實現，說到算法它就是一個大頂堆，說到 Java 它是一個 PriorityQueue 的實現，那麼你理解了 TopN 問題，知道其時間複雜度、優缺點，是否是就能夠熟練運用 Java 的工具類寫更高效的程序了？

之因此排序算法和 Java 集合&工具類同樣重要是由於它們和咱們天天的編程息息相關。面試官老是問排序算法也不是在爲難你，而是在考察你的編程功底。因此你須要對着排序算法和基本的算法配合 Java 的集合類、工具類仔細研究一番，這樣才能更深刻地理解他們的關聯關係。

多線程和併發包

多線程和併發包，重要性就不贅述了，直接說一下學習方法。你首先要理解多線程不只僅是 Thread 和 Runnable 那麼簡單，整個併發包下面的工具都是在爲多線程服務。對於多線程的學習切不可看幾篇面試文章，或者幾個關鍵字 CountDownLatch，Lock 巴拉巴拉就覺得理解了多線程的精髓，筆者這裏整理了一個大圖：

你須要針對這個大圖或者本身梳理一個大圖，對裏面的類各個擊破，包括它們的使用場景、優缺點。固然你須要配合源碼看，源碼就是大圖裏面的每個源碼，和上面的 JVM 同樣，不要着急立刻看完，而是看懂每個地方是爲何。看得差很少你就會發現，其實它和 Java 集合類、工具類密不可分，那麼天然把它列爲重要知識點的緣由不言而喻。

Redis、MySQL、ElasticSearch

存儲相關都是咱們平時經常使用的工具，Redis、MySQL、ElasticSearch。知識點分爲兩方面，一方面是你平時使用過程當中積累的經驗，另外一方面是你對其的深刻理解。因此這裏的建議就是經過書籍來鞏固技術知識， 《Redis設計與實現 (數據庫技術叢書)》、《高性能 MySQL》、《ElasticSearch 權威指南》這三本書不必定是該領域最好的書籍，可是若是你吃透了，對於你對知識的理解和程序的設計一定有很大幫助。書裏面的內容太多，仍是舉兩個「栗子」。

其一，使用 Redis 切不可只用他當作 Key-Value 緩存數據庫。筆者瞭解到它的 5 種基本類型中一種類型叫作 Sorted Set。Sorted Set 裏 items 內容大於 64 的時候同時使用了 Hash 和 SkipList 兩種設計實現。這也會爲了排序和查找性能作的優化。添加和刪除都須要修改 SkipList，因此複雜度爲 O(log(n))。 可是若是僅僅是查找元素的話能夠直接使用 Hash，其複雜度爲 O(1) ，其餘的 range 操做複雜度通常爲 O(log(n))，固然若是是小於 64 的時候，由於是採用了 ziplist 的設計，其時間複雜度爲 O(n)。這樣之後查詢和更新閱讀都變得簡單，那是否是能夠用其實現 TopN 的需求呢？這樣相似的需求就不須要你查數據，再在內存裏面計算和操做了。好比咱們簡單的周排行，月排行均可以考慮使用這個數據結構實現，固然這並不必定是最好的解決方案，而是提供了一種解題思路。

此外，PriorityQueue 是優先隊列咱們上文已經瞭解，那麼 ElasticSearch 的 Query 也是用優先隊列分別在每個分片上面獲取，而後再合併優先隊列你瞭解嗎？這個「栗子」告訴咱們其實算法是相通的，你理解一個即可以觸類旁通舉一反三。

框架

一談框架就想起來 Spring，一說 Spring 就想起來 IOC、AOP。由於你們都在用這個框架，因此對於框架也不須要看一些其餘的，直接就深刻了解一下 Spring 就能夠了。經過上面的敘述你已經瞭解了小編的思路，看什麼都要看他的實現原理，因此直接推薦你一本書《Spring 技術內幕》而後對着本身現有的 Spring 項目 Debug，從請求的流轉梳理知識點。Spring 出來這麼久你們對基本的知識已經瞭然於胸，重要的是看其解決問題的思路和原理，栗子又來了。

好比須要實如今 Bean 剛剛初始化的時候作一些操做，是否是須要使用InitializingBean？那麼具體怎麼使用，它的原理是什麼，Spring Bean 的生命週期是什麼樣子？經過具體的使用場景逐步展開說明，這樣複習效果會更好一些，而後再逐步思考每個知識點裏面涉及的更多知識點，好比 AOP 裏面的 Proxy 都是基於什麼原理實現，有什麼優缺點。

分佈式

這是一個老生常談的話題，也是這幾年比較火的話題，提及分佈式就必定和 Dubbo 有關係，可是不能僅僅就理解到 Dubbo。

首先咱們須要思考它解決的問題，爲何要引入 Dubbo 這個概念。隨着業務的發展、用戶量的增加，系統數量增多，調用依賴關係也變得複雜，爲了確保系統高可用、高併發的要求，系統的架構也從單體時代慢慢遷移至服務 SOA 時代，Dubbo 應運而生，它做爲 RPC 的出現使得咱們搭建微服務項目變得簡單，可是咱們不只僅要思考 Dubbo帶來的框架支撐。

同時須要思考服務的冪等、分佈式事務、服務之間的 Trace 定位、分佈式日誌、數據對帳、重試機制等，與此同時考慮 MQ 對系統的解耦和壓力的分擔、數據庫分佈式部署和分庫分表、限流、熔斷等機制。因此最終總結是不只僅要看 Dubbo 的使用、原理，同時還要思考上下游和一些系統設計的問題，這塊相對的知識點較多，能夠針對上面拋出來的點各個擊破。

設計模式

設計模式不少，可是經常使用的就幾種，這個地方能夠分兩個方面準備：

1. 學以至用，設計模式不是背出來的，而是用出來的。平時多注意思考當前項目的設計，是否能夠套用設計模式，固然必須先理解每個設計模式存在的意義；

2. 在現有框架中思考設計模式的體現，上面已經講過框架怎麼學習，以 Spring 爲例，它裏面用了超過 9 種設計模式，你都知道用到哪裏了嗎？若是不知道，試着把它們找出來，同時思考爲何這麼設計，所有找到之後，基本的設計模式的用法和原理你也就都理解了。

喜歡可加關注，加喜歡哦！