前言
在講這道題之前，我想先聊聊「技術面試究竟是在考什麼」這個問題。
技術面試究竟在考什麼
在人人都知道刷題的今天，面試官也都知道大家會刷題準備面試，程式碼大家都會寫，那面試為什麼還在考這些題？那為什麼有些人程式碼寫出來了還掛了？
大家知道美國的大廠面試 80%是在考演算法，這其實是最近 5-10 年以谷歌、雅虎為首才興起的；國內大廠對於演算法的考察雖然沒有這麼狂熱，但也越來越重視了。
那麼演算法面試真的只是在考演算法嗎？顯然不是。本質上考的是思考問題的方式，分析、解決問題的能力，以及和同事溝通交流的能力，看你能否主動推進去解決問題。
答題思路
套路就是：
- clarify 問題
- 分析思路、時空複雜度、分析哪裡可以優化、如何優化
- 寫程式碼
- run test cases
雖說是套路，但何嘗不是一個高效的工作方式？
那拿到一個問題，首先應該是去 clarify 這個問題，因為工作就是如此，不像在刷題網站做題什麼都給你定義好了，面試官通常都不會一次性給你所有條件，而是需要你思考之後去問他。那通過這個環節，面試官就知道了你遇到問題是怎麼去思考的，你考慮的是否全面，怎麼去和別人溝通的，今後和你一起工作的狀態是怎樣的。
就像我們平時工作時，需要和 product manager 不斷的 clarify 需求，特別是沒定義清楚的部分，反反覆覆的討論，也是磨刀不誤砍柴工。那這個過程，在我司可能就要 1-2 周，不會很著急的就開始，否則努力錯了方向就是南轅北轍，得不償失。那麼面試時也是一樣，程式碼都寫完了面試官說這不是我想問的，那時候已經沒時間了，買單的是我們自己。
第二點分析思路就是重中之重了，也是本文的核心，會以 LRU Cache 這到經典題為例，展示我是如何思考、分析的。
第三點寫程式碼，沒什麼好說的，終究是需要落到實處的。
第四點跑測試，很多同學可能會忘，所以如果你能主動提出 run test cases，過幾個例子檢驗一下，是很好的。
- 一來是給自己一個修正的機會，因為有很多 bug 是你跑兩個例子就能發現的，那即使有點 bug 你沒發現，只要你做完了這一步，面試官當場也沒發現的話，那面試結束後面試官雖然會拍照留念，但也不會閒的無聊再自己打到電腦上跑的；
- 二來是展示你的這種意識，跑測試的意識，這種意識是很重要的。
有些人說每道題我都做出來了，為什麼還是掛了？那照著這四點對比一下，看看是哪個環節出了問題。
常考不衰的原因
另外這道題為什麼各大公司都喜歡考呢？
一是因為它能夠多方面、多維度的考察 candidate：這道題考察的是基本功，考對資料結構理解使用，考能不能寫出 readable 的程式碼。一場 45 分鐘-60 分鐘的面試，如何摸清楚 candidate 的真實水平，也是不容易的啊。
二是因為這道題可難可易，可以簡單到像 Leetcode 上那樣把 API 什麼的都已經定義好了，也可以難到把 System Design 的內容都包含進來，聊一下 Redis 中的近似 LRU 演算法。
所以 follow up 就可以無限的深入下去，如果面試官想問的你都能回答的頭頭是道，那 strong hire 自然跑不掉。那有些同學只會到第一層或者第二層，面試是優中選優的過程，其他同學會的比你多，溝通交流能力又好，自然就是別人拿 offer 了。
那今天就以這道題為例，在這裡淺談一下我的思考過程，為大家拋磚引玉，歡迎在留言區分享你的想法。
LRU Cache
LRU 是什麼
LRU = Least Recently Used 最近最少使用
它是一種快取逐出策略 cache eviction policies
LRU 演算法是假設最近最少使用的那些資訊，將來被使用的概率也不大，所以在容量有限的情況下，就可以把這些不常用的資訊踢出去，騰地方。
比如有熱點新聞時，所有人都在搜尋這個資訊，那剛被一個人搜過的資訊接下來被其他人搜尋的概率也大，就比前兩天的一個過時的新聞被搜尋的概率大，所以我們把很久沒有用過的資訊踢出去，也就是 Least Recently Used 的資訊被踢出去。
舉個例子：我們的記憶體容量為 5，現在有 1-5 五個數。
我們現在想加入一個新的數：6
可是容量已經滿了，所以需要踢出去一個。
那按照什麼規則踢出去，就有了這個快取逐出策略。比如：
-
FIFO (First In First Out)這個就是普通的先進先出。 -
LFU (Least Frequently Used)這個是計算每個資訊的訪問次數，踢走訪問次數最少的那個；如果訪問次數一樣，就踢走好久沒用過的那個。這個演算法其實很高效，但是耗資源，所以一般不用。 -
LRU (Least Recently Used)這是目前最常用了。
LRU 的規則是把很長時間沒有用過的踢出去，那它的隱含假設就是，認為最近用到的資訊以後用到的概率會更大。
那我們這個例子中就是把最老的 1 踢出去，變成：
不斷迭代...
Cache 是什麼？
簡單理解就是：把一些可以重複使用的資訊存起來，以便之後需要時可以快速拿到。
那至於它存在哪裡就不一定了，最常見的是存在記憶體裡，也就是 memory cache，但也可以不存在記憶體裡。
使用場景就更多了，比如 Spring 中有 @Cacheable 等支援 Cache 的一系列註解。上個月我在工作中就用到了這個 annotation，當然是我司包裝過的，大大減少了 call 某伺服器的次數，解決了一個效能上的問題。
再比如，在進行資料庫查詢的時候，不想每次請求都去 call 資料庫，那我們就在記憶體裡存一些常用的資料，來提高訪問效能。
這種設計思想其實是遵循了著名的“二八定律”。在讀寫資料庫時，每次的 I/O 過程消耗很大，但其實 80% 的 request 都是在用那 20% 的資料，所以把這 20% 的資料放在記憶體裡，就能夠極大的提高整體的效率。
總之，Cache 的目的是存一些可以複用的資訊，方便將來的請求快速獲得。
LRU Cache
那我們知道了 LRU，瞭解了 Cache，合起來就是 LRU Cache 了：
當 Cache 儲存滿了的時候，使用 LRU 演算法把老傢伙清理出去。
思路詳解
說了這麼多，Let's get to the meat of the problem!
這道經典題大家都知道是要用 HashMap + Doubly Linked List，或者說用 Java 中現成的 LinkedHashMap，但是，為什麼？你是怎麼想到用這兩個資料結構的？面試的時候不講清楚這個，不說清楚思考過程，程式碼寫對了也沒用。
和在工作中的設計思路類似，沒有人會告訴我們要用什麼資料結構，一般的思路是先想有哪些 operations，然後根據這些操作，再去看哪些資料結構合適。
分析 Operations
那我們來分析一下對於這個 LRU Cache 需要有哪些操作：
- 首先最基本的操作就是能夠從裡面讀資訊，不然之後快速獲取是咋來的；
- 那還得能加入新的資訊，新的資訊進來就是 most recently used 了；
- 在加新資訊之前，還得看看有沒有空位，如果沒有空間了，得先把老的踢出去，那就需要能夠找到那個老傢伙並且刪除它；
- 那如果加入的新資訊是快取裡已經有的，那意思就是 key 已經有了，要更新 value，那就只需要調整一下這條資訊的 priority，它已經從那次被寵幸晉升為貴妃了～
找尋資料結構
那第一個操作很明顯，我們需要一個能夠快速查詢的資料結構，非 HashMap 莫屬，還不瞭解 HashMap 原理和設計規則的在公眾號內發訊息「HashMap」，送你一篇爆款文章；
可是後面的操作 HashMap 就不頂用了呀。。。
來來來，我們來數一遍基本的資料結構：
Array, LinkedList, Stack, Queue, Tree, BST, Heap, HashMap
在做這種資料結構的題目時，就這樣把所有的資料結構列出來，一個個來分析，有時候不是因為這個資料結構不行，而是因為其他的資料結構更好。怎麼叫更好？忘了我們的衡量標準嘛！時空複雜度，趕緊複習遞迴那篇文章，公眾號內回覆「遞迴」即可獲得。
那我們的分析如下：
Array, Stack, Queue 這三種本質上都是 Array 實現的（當然 Stack, Queue 也可以用 LinkedList 來實現。。），一會插入新的，一會刪除老的，一會調整下順序，array 不是不能做，就是得 O(n) 啊，用不起。
BST 同理，時間複雜度是 O(logn).
Heap 即便可以，也是 O(logn).
LinkedList，有點可以哦，按照從老到新的順序，排排站，刪除、插入、移動，都可以是 O(1) 的誒！但是刪除時我還需要一個 previous pointer 才能刪掉，所以我需要一個 Doubly LinkedList.
那麼我們的資料結構敲定為： HashMap + Doubly LinkedList
定義清楚資料結構的內容
選好了資料結構之後，還需要定義清楚每個資料結構具體儲存的是是什麼，這兩個資料結構是如何聯絡的，這才是核心問題。
我們先想個場景，在搜尋引擎裡，你輸入問題 Questions，谷歌給你返回答案 Answer。
那我們就先假設這兩個資料結構存的都是 <Q, A>，然後來看這些操作，如果都很順利，那沒問題，如果有問題，我們再調整。
那現在我們的 HashMap 和 LinkedList 長這樣：
然後我們回頭來看這四種操作：
操作 1，沒問題，直接從 HashMap 裡讀取 Answer 即可，O(1)；
操作 2，新加入一組 Q&A，兩個資料結構都得加，那先要判斷一下當前的快取裡有沒有這個 Q，那我們用 HashMap 判斷，
- 如果沒有這個 Q，加進來，都沒問題；
- 如果已經有這個 Q，HashMap 這裡要更新一下 Answer，然後我們還要把 LinkedList 的那個 node 移動到最後或者最前，因為它變成了最新被使用的了嘛。
可是，怎麼找 LinkedList 的這個 node 呢？一個個 traverse 去找並不是我們想要的，因為要 O(n) 的時間嘛，我們想用 O(1) 的時間操作。
那也就是說這樣記錄是不行的，還需要記錄 LinkedList 中每個 ListNode 的位置，這就是本題關鍵所在。
那自然是在 HashMap 裡記錄 ListNode 的位置這個資訊了，也就是存一下每個 ListNode 的 reference。
想想其實也是，HashMap 裡沒有必要記錄 Answer，Answer 只需要在 LinkedList 裡記錄就可以了。
之後我們更新、移動每個 node 時，它的 reference 也不需要變，所以 HashMap 也不用改動，動的只是 previous, next pointer.
那再一想，其實 LinkedList 裡也沒必要記錄 Question，反正 HashMap 裡有。
這兩個資料結構是相互配合來用的，不需要記錄一樣的資訊。
更新後的資料結構如下：
這樣，我們才分析出來用什麼資料結構，每個資料結構裡存的是什麼，物理意義是什麼。
那其實，Java 中的 LinkedHashMap 已經做了很好的實現。但是，即便面試時可以使用它，也是這麼一步步推匯出來的，而不是一看到題目就知道用它，那一看就是背答案啊。
有同學問我，如果面試官問我這題做沒做過，該怎麼回答？
答：實話實說。
真誠在面試、工作中都是很重要的，所以實話實說就好了。但如果面試官沒問，就不必說。。。
其實面試官是不 care 你做沒做過這道題的，因為大家都刷題，基本都做過，問這個問題沒有意義。只要你能把問題分析清楚，講清楚邏輯，做過了又怎樣？很多做過了題的人是講不清楚的。。。
總結
那我們再總結一下那四點操作：
第一個操作，也就是 get() API，沒啥好說的；
二三四，是 put() API，有點小麻煩：
畫圖的時候邊講邊寫，每一步都從 high level 到 detail 再到程式碼，把程式碼模組化。
- 比如“Welcome”是要把這個新的資訊加入到 HashMap 和 LinkedList 裡，那我會用一個單獨的 add() method 來寫這塊內容，那在下面的程式碼裡我取名為 appendHead()，更精準；
- “踢走老的”這裡我也是用一個單獨的 remove() method 來寫的。
當年我把這圖畫出來，面試官就沒讓我寫程式碼了，直接下一題了...
那如果面試官還讓你寫，就寫唄。。。
class LRUCache {
// HashMap: <key = Question, value = ListNode>
// LinkedList: <Answer>
public static class Node {
int key;
int val;
Node next;
Node prev;
public Node(int key, int val) {
this.key = key;
this.val = val;
}
}
Map<Integer, Node> map = new HashMap<>();
private Node head;
private Node tail;
private int cap;
public LRUCache(int capacity) {
cap = capacity;
}
public int get(int key) {
Node node = map.get(key);
if(node == null) {
return -1;
} else {
int res = node.val;
remove(node);
appendHead(node);
return res;
}
}
public void put(int key, int value) {
// 先 check 有沒有這個 key
Node node = map.get(key);
if(node != null) {
node.val = value;
// 把這個node放在最前面去
remove(node);
appendHead(node);
} else {
node = new Node(key, value);
if(map.size() < cap) {
appendHead(node);
map.put(key, node);
} else {
// 踢走老的
map.remove(tail.key);
remove(tail);
appendHead(node);
map.put(key, node);
}
}
}
private void appendHead(Node node) {
if(head == null) {
head = tail = node;
} else {
node.next = head;
head.prev = node;
head = node;
}
}
private void remove(Node node) {
// 這裡我寫的可能不是最 elegant 的，但是是很 readable 的
if(head == tail) {
head = tail = null;
} else {
if(head == node) {
head = head.next;
node.next = null;
} else if (tail == node) {
tail = tail.prev;
tail.next = null;
node.prev = null;
} else {
node.prev.next = node.next;
node.next.prev = node.prev;
node.prev = null;
node.next = null;
}
}
}
}
/**
* Your LRUCache object will be instantiated and called as such:
* LRUCache obj = new LRUCache(capacity);
* int param_1 = obj.get(key);
* obj.put(key,value);
*/總結
那再回到面試上來，為什麼很多面試是以演算法考察為主的？這樣的面試道理何在？演算法題面試真的能衡量一個人的工作能力嗎？（當然了，對於有些工作經驗的人還會考察系統設計方面的內容。）
這是我一直在思考的問題，工作之後愈發覺得，這樣的面試真的是有效的。
因為我們需要的是能夠去解決未知的問題的能力，知識可能會被遺忘，但是思考問題的方式方法是一直跟隨著我們的，也是我們需要不斷提高的。那麼在基本功紮實的前提下，有正確的方法和思路做指引，nothing is impossible.