作為業(yè)務開發(fā)，我們會用到各種框架、中間件和底層系統(tǒng)，比如 Spring、RPC 框架、消息中間件、Redis 等等。在這些基礎框架中，一般都揉和了很多基礎數(shù)據(jù)結構和算法的設計思想。比如，我們常用的 Key-Value 數(shù)據(jù)庫 Redis 中，里面的有序集合是用什么數(shù)據(jù)結構來實現(xiàn)的呢？為什么要用跳表來實現(xiàn)呢？為什么不用二叉樹呢？

在平時的工作中，數(shù)據(jù)結構和算法的應用到處可見。我來舉一個你非常熟悉的例子：如何實時統(tǒng)計 業(yè)務接口 99%的 響應時間？

你可能最先想到，每次查詢時，從小到大排序所有的響應時間，如果總共有 1200 個數(shù)據(jù)，那第1188個數(shù)據(jù)就是 99% 的響應時間。很顯然，每次用這個方法查詢的話都要排序，效率是非常低的。但是，如果你知道“堆”這個數(shù)據(jù)結構，用兩個堆可以非常高效地解決這個問題。

對編程還有追求？不想被行業(yè)淘汰？那就不要只會寫湊合能用的代碼！
何為編程能力強？是代碼的可讀性好、健壯？還是擴展性好？我覺得沒法列，也列不全。但是，在我看來，性能好壞起碼是其中一個非常重要的評判標準。但是，如果你連代碼的時間復雜度、空間復雜度都不知道怎么分析，怎么寫出高性能的代碼呢？

如果你在一家成熟的公司，或者 BAT 這樣的大公司，面對的是千萬級甚至億級的用戶，開發(fā)的是 TB、PB 級別數(shù)據(jù)的處理系統(tǒng)。性能幾乎是開發(fā)過程中時刻都要考慮的問題。一個簡單的ArrayList、Linked List 的選擇問題，就可能會產(chǎn)生成千上萬倍的性能差別。這個時候，數(shù)據(jù)結構和算法的意義就完全凸顯出來了。