【面經】面試官：作過性能優化的工做嗎？你會從哪些方面入手作性能優化呢？

寫在前面

隨着互聯網的高速發展，互聯網行業已經從IT時代慢慢步入到DT時代。對於Java程序員的要求愈來愈高，只是單純的掌握CRUD以不足以勝任互聯網公司的相關職位，大量招聘崗位顯示：若是是面試中高級的Java崗，基本上都須要懂性能優化的相關知識。今天，咱們就一塊兒來聊聊一個經典的面試題：作過性能優化的工做嗎？你會從哪些方面入手作性能優化呢？

問題分析

標題中問出了兩個問題，一個是有沒有作過性能優化的工做，一個是從哪些方面入手作性能優化。對於第一個問題，咱們能夠直接回答有或者沒有。相信小夥伴們都但願本身作過性能優化的工做，若是是回答作過，那第二個問題，咱們又該如何回答呢？

首先，對於第二個問題來講，問的是會從哪些方面入手。這個問題就沒有固定答案了。你能夠按照你以往的經驗來回答這個問題，可是，在回答這個問題以前，須要先好好梳理下你的思路，將你要表達的說清楚。

接下來，咱們就一塊兒來聊聊第二個問題：你會從哪些方面入手作性能優化？

咱們能夠從性能優化的幾個方面來進行回答。下面，咱們就來聊聊性能優化能夠從哪些方面進行。

性能優化有哪些方面？

這裏，我結合平時工做中的總結，將性能優化總結爲下面這張圖。

也就是說，咱們能夠從數據聚合優化、資源衝突優化、算法優化、JVM優化、複用優化、計算優化和快速實現等方面來進行回答。接下來，咱們就針對每一個點進行說明。

數據聚合優化

數據聚合優化主要針對的是對於數據的整合和傳輸的優化。好比：咱們從數據庫中查詢出的數據，通過程序的聚合處理後再返回給客戶端，而不用客戶端調用屢次接口來分別獲取數據。

再好比：咱們在項目中使用的Nginx，通常都會開啓GZIP壓縮，使傳輸的數據更加緊湊，同時，使傳輸的數據量更小。

細心的小夥伴會發現，咱們對於數據聚合的優化，主要是使傳輸的數據量更小。因此，咱們在使用SQL語句查詢數據庫中的數據時，儘可能查詢那些須要的字段，對於不須要的字段就直接忽略不查詢了，避免在SQL語句中出現select *

資源衝突優化

在咱們平時的工做中，尤爲是在高併發的場景下，常常會出現鎖衝突的問題，鎖衝突是資源衝突的一個典型場景。

關於鎖咱們能夠聯想到數據庫的行鎖、表鎖、Java中的synchronized和Lock等。若是對應到操做系統級別，則會有CPU命令級別的鎖，JVM指令級別的鎖，操做系統的內部鎖等。

這裏，小夥伴們須要注意一點：只有在併發的場景下，纔會出現資源衝突的問題。也就是說：在同一時刻，只能有一個請求獲取到請求資源，解決衝突的方式就是加鎖。

咱們須要在平時的工做過程當中避免鎖衝突的問題，優化如何優化加鎖方式，小夥伴們能夠參見《【高併發】面試官：講講高併發場景下如何優化加鎖方式？》一文。

算法優化

在一個大型的互聯網項目中，每每涉及到分佈式和微服務等技術，其中，也會使用到大量的數據結構和算法，對於算法的優化可以顯著的提升系統的性能。一個好的實現，相比於一個拙劣的實現來講，在系統性能的提高上存在着巨大的差別。

好比，做爲 List 的實現，LinkedList 和 ArrayList 在隨機訪問的性能上，差了好幾個數量級；又好比，CopyOnWriteList 採用寫時複製的方式，能夠顯著下降讀多寫少場景下的鎖衝突。而何時使用同步，何時是線程安全的，也對咱們的編碼能力有較高的要求。

因此，咱們須要在平時工做過程當中，多多積累數據結構和算法的相關知識。

JVM優化

JVM調優，不用說，這是每一個Java工程師必需要掌握的標準技能。全部的Java程序最終都是運行在JVM中的，對JVM進行優化也可以提高Java程序的性能。可是，須要注意的是：若是在優化JVM時，參數設置不當，可能會形成內存溢出等嚴重的問題。

目前被普遍使用的垃圾回收器是 G1，經過不多的參數配置，內存便可高效回收。CMS 垃圾回收器已經在 Java 14 中被移除，因爲它的 GC 時間不可控，有條件應該儘可能避免使用。

複用優化

複用優化，這個看名字就知道，說白了就是能夠重複利用。估計不少小夥伴都有這樣的經驗，在寫代碼的時候，能夠將不少重複的代碼抽象出來，作成公共的方法。這樣，就不用每次都去寫重複的邏輯代碼了。這是代碼層面的複用。

若是是數據層面的話，咱們可使用緩衝和緩存來複用數據。

這裏，小夥伴們須要注意一個知識點：緩衝主要針對的是寫操做，緩存主要針對的是讀操做。

另外一個複用優化的典型場景就是池化技術，好比：數據庫鏈接池、線程池等。

計算優化

對於計算優化來講，咱們能夠從如下幾個小的方面來闡述。

並行計算

不難理解，就是多個計算同時進行。這裏，又能夠將並行計算分爲：多機並行計算、多進程並行計算和多線程並行計算。

多機並行計算： 將一個大的計算任務，拆分紅N個小的計算任務，分發到不一樣的機器進行處理。典型的場景就是Hadoop的MapReduce極端。

多進程計算： 好比，Nginx採用的NIO模型，採用的是進程調度的策略，由Master進程調度Worker進程，Worker進行來處理具體的請求。

多線程計算： 對於多線程計算來講，也是咱們平時接觸最多的一種計算方式，咱們可使用多線程技術，將複雜的邏輯計算拆分紅一個個小的計算任務，分發到不一樣的線程中去執行。

同步變異步

同步和異步的區別就是：同步須要等待返回結果，異步不須要等待返回結果。若是咱們在業務程序中，不須要等待返回結果數據，則咱們能夠將同步調用優化爲異步調用，從而提高咱們系統的性能。

懶加載

最典型的場景就是Spring中的懶加載，只有第一次獲取bean的時候，纔會建立bean實例。

快速實現

對於快速實現來講，不只包含咱們須要利用相關的程序框架迅速開發出咱們想要的業務，也須要咱們在進行技術選型時，儘可能使用一些性能優良的組件。好比，在進行網絡開發時，儘可能選擇Netty，結合輕量級的數據傳輸，就不要使用WebService等技術了。

不少公司喜歡使用適配器模式，在一些現有的開源組件之上，再抽象一層本身的組件，這樣就可以作到切換底層組件的時候，對上層應用無感。

好了，今天咱們就到這兒吧，我是冰河，咱們下期見！！

重磅福利

微信搜一搜【冰河技術】微信公衆號，關注這個有深度的程序員，天天閱讀超硬核技術乾貨，公衆號內回覆【PDF】有我準備的一線大廠面試資料和我原創的超硬核PDF技術文檔，以及我爲你們精心準備的多套簡歷模板（不斷更新中），但願你們都能找到心儀的工做，學習是一條時而鬱鬱寡歡，時而開懷大笑的路，加油。若是你經過努力成功進入到了心儀的公司，必定不要懈怠放鬆，職場成長和新技術學習同樣，不進則退。若是有幸咱們江湖再見！

另外，我開源的各個PDF，後續我都會持續更新和維護，感謝你們長期以來對冰河的支持！！

寫在最後

若是你以爲冰河寫的還不錯，請微信搜索並關注「 冰河技術 」微信公衆號，跟冰河學習高併發、分佈式、微服務、大數據、互聯網和雲原生技術，「 冰河技術 」微信公衆號更新了大量技術專題，每一篇技術文章乾貨滿滿！很多讀者已經經過閱讀「 冰河技術 」微信公衆號文章，吊打面試官，成功跳槽到大廠；也有很多讀者實現了技術上的飛躍，成爲公司的技術骨幹！若是你也想像他們同樣提高本身的能力，實現技術能力的飛躍，進大廠，升職加薪，那就關注「 冰河技術 」微信公衆號吧，天天更新超硬核技術乾貨，讓你對如何提高技術能力再也不迷茫！