是時候覺悟了！一篇文章讓你明白數據結構與算法分析有多重要

不得不說，如今不少大廠，好比Google、Facebook、BAT，面試的時候都喜歡考算法、讓人現場寫

代碼。常常有人說，程序員35歲以後很容易陷入瓶頸，被行業淘汰，我以爲緣由其實就在此。寫代碼

的時候，歷來都不考慮非功能性的需求，只是完成功能，湊合能用就好；作事情的時候，也歷來沒有

長遠規劃，只把眼前事情作好就知足。雖然技術不錯，但每次去面試都會「跪」在算法上，非常惋惜。

那你有沒有真正地想過，爲何這些大公司都喜歡考算法呢？緣由就是越是厲害的公司，越是注重考

察數據結構與算法這類基礎知識。相比短時間能力，他們更看中你的長期潛力。固然，也有不少人說， 本身實際工做中根本用不到數據結構和算法。因此，就算不懂這塊知識，只要Java API、開發框架用

得熟練，照樣能夠把代碼寫得「飛」起來，可是你可知道大廠面對的是千萬級甚至億級的用戶，開發的

是TB、PB級別數據的處理系統。性能幾乎是開發過程當中時刻都要考慮的問題。一個簡單的

ArrayList、Linked List的選擇問題，就可能會產生成千上萬倍的性能差異。這個時候，數據結構和算

法的意義就徹底凸顯出來了。同時，你可能也會說，我在小公司工做，用戶量不多，須要處理的數據

量也不多，開發中不須要考慮那麼多性能的問題，完成功能就能夠，用什麼數據結構和算法，差異根

本不大。可是一點你真的想「十年如一日」地作同樣的作個普普統統的程序員嗎？平平凡凡度過一輩子？

其實，我以爲，數據結構和算法這個東西，若是你不去學，可能真的這輩子都用不到，也感覺不到它

的好。可是一旦掌握，你就會經常被它的強大威力所折服。以前你可能須要費很大勁兒來優化的代

碼，須要花不少心思來設計的架構，用了數據結構和算法以後，很容易就能夠解決了。若是不知道這

些類庫背後的原理，不懂得時間、空間複雜度分析，你如何能用好、用對它們？存儲某個業務數據的

時候，你如何知道應該用ArrayList，仍是Linked List呢？調用了某個函數以後，你又該如何評估代碼

的性能和資源的消耗呢？做爲業務開發，咱們會用到各類框架、中間件和底層系統，好比Spring、

RPC框架、消息中間件、Redis等等。在這些基礎框架中，通常都揉和了不少基礎數據結構和算法的

設計思想。好比，咱們經常使用的Key-Value數據庫Redis中，裏面的有序集合是用什麼數據結構來實現的

呢？爲何要用跳錶來實現呢？爲何不用二叉樹呢？

若是你能弄明白這些底層原理，你就能更好地使用它們。即使出現問題，也很容易就能定位。所以，

掌握數據結構和算法，無論對於閱讀框架源碼，仍是理解其背後的設計思想，都是很是有用的。在平

時的工做中，數據結構和算法的應用處處可見。我來舉一個你很是熟悉的例子：如何實時地統計業務

接口的99%響應時間？

你可能最早想到，每次查詢時，從小到大排序全部的響應時間，若是總共有1200個數據，那第1188

個數據就是99%的響應時間。很顯然，每次用這個方法查詢的話都要排序，效率是很是低的。可是，

若是你知道「堆」這個數據結構，用兩個堆能夠很是高效地解決這個問題。基礎架構研發工程師，寫出

如今互聯網上的技術文章、架構分享、開源項目滿天飛，照貓畫虎作一套基礎框架並不難。我就拿

RPC框架舉例。不一樣的公司、不一樣的人作出的RPC框架，架構設計思路都差很少，最後實現的功能

也都差很少。可是有的人作出來的框架，Bug不少、性能通常、擴展性也很差，只能在本身公司僅有

的幾個項目裏面用一下。而有的人作的框架能夠開源到GitHub上給不少人用，甚至被Apache收錄。

爲何會有這麼大的差距呢？我以爲，高手之間的競爭其實就在細節。這些細節包括：你用的算法是

不是夠優化，數據存取的效率是否是夠高，內存是否是夠節省等等。這些累積起來，決定了一個框架

是否是優秀，請記住達到開源水平的框架纔是你的目標！因此，若是你還不懂數據結構和算法，沒聽

說過大O複雜度分析，不知道怎麼分析代碼的時間複雜度和空間複雜度，那確定說不過去了

文章最後的一段話，固然，我如今的閱歷還沒如此豐富寫出如此好的文章，文章摘自極客大牛王爭，

我只想告訴各位數據結構和算法真的很重要，必定要好好修修內功，才能越走越遠！！！

若是本文對你有一點點幫助，那麼請點個讚唄，謝謝~

最後，如有不足或者不正之處，歡迎指正批評，感激涕零！若是有疑問歡迎留言，絕對第一時間回覆！

歡迎各位關注個人公衆號，一塊兒探討技術，嚮往技術，追求技術，說好了來了就是盆友喔...