這篇文章結合自身的工作經驗，站在面試官和麪試者的不同角度上來說明兩種現象：
- 爲山九刃，功虧一簣：差之毫釐的遺憾
- 雲銷雨霽，彩徹區明：柳暗花明的興奮
有些問題回答上來不加分，But沒有答上來or回答錯誤,Good bye…
也有些問題答不出來或者答錯沒有任何影響，但是答出來讓面試官刮目相看…
送面試官一句話：
凡是不願意看不到別人長處的人，總是一眼就看到別人不如自己之處。
送面試者一句話：
生命中最難的階段不是沒有人懂你，而是你不懂你自己。
1. 時空互換
在學習數據結構的時候，我們都會討論 時間複雜度 和 空間複雜度。縱觀所有算法，無不圍繞着時間和空間去優化，無不在這兩方面進行權衡妥協。
面試過程中，若遇到算法題並嘗試對其進行優化時，可以從這方面入手。一般情況下，我們都是犧牲空間來贏得時間。但在嵌入式編程或者存儲空間有限的情況下，則會適當的犧牲時間來換取空間上的優化。
比如：遞歸優化(斐波那契數列… 爬樓梯問題…)
2. 面試中關於爲什麼這樣的設計的問題？
Whatever is reasonable is true,and whatever is true is reasonable. 存在即合理
這種問題主要從效率 和 安全 兩個方面去闡述:
- String 爲什麼要設計成不可變的？
- String 爲什麼要重寫hashCode()?
- 爲什麼要設計線程池？
- …
3.(線程)安全與速度的抉擇？
魚和熊掌二者不可得兼。
目前這類問題在面試環節主要體現在以下兩個方面：
- StringBuilder 和 StringBuffer 的選擇.
- HashMap 和 HashTable 的選擇.
IOW，在不涉及線程安全問題，線程安全 在速度上要稍遜於 非線程安全的。 （PS：可以類比 多經過一道防盜門 去理解）
4. 運算優化
我們在閱讀源碼的過程中，會發現其中有很多的移位操作。這裏強調一點，可以 將乘除優化爲左右移位操作。(PS:隨着JVM越來越智能，已經幫我們自動處理啦)
5. 底層實現的特性
| 實現方式 | 特點 |
|---|---|
| 數組實現 | 查詢速度快，插入，刪除效率低 |
| 鏈表實現 | 查詢速度慢，插入，刪除效率高 |
| 樹實現 | 揚長避短 |
Java 一般涉及的都是ArrayList,LinkedList…etc
這種基本問題若回答錯誤，絕對是Bye…柳暗花明的可能性也不復存在…
6. 關於數字問題
對於閱讀過源碼且有心的人來說，很容易發現Java在數字選擇上有一點的規律：
- 質數(7,11,31)
- 有利於運算優化的數(7 = 2<< 3 -1, 31 = 2<<5 -1 )
- 2的N次方( 2^ N = 2 << N)
常見場景：
- 線程池有幾個參數？ 7
- Object類有幾個方法？ 7
- String的hashCode()如何實現？記住31即可
- HashTable的初始容量？ 11
- HashMap的初始容量？ 2 << 4 -1 = 16
- HashMap的鏈表進行樹化的閾值? 8 = 2^3
…
總結
面試是雙向選擇的過程。有時候面試下來自我感覺良好，唯獨少了一份OFFER…可以參考以上內容，是不是犯了"不可饒恕"的錯誤。
鄭重聲明：
就算不知道上面的內容，也是可以找到一份工作的…