HDBS之應用代碼優化

1、目錄結構樹

• 整體概述
• 代碼檢測工具sonar
• HDBS代碼優化
• 總結開發注意點

2、整體概述

　　進入如今這家公司個人第一個任務就是對HDBS進行代碼質量優化。HDBS可能你們不是很瞭解，如今給你們簡單介紹下：HDBS是HadoopBaseService的簡稱，Hadoop有了解過大數據的朋友相信並不陌生，BaseService天然也就是基礎服務的意思；因此HDBS這個服務主要是基礎服務的配置，同時Hadoop則表示數據量的大。如下是我暫時瞭解的應用架構圖方便各位理解，畢竟纔來這個公司一個星期可能畫的不是很完整不過整體就是這麼回事：

2、代碼檢測工具  

• 前提描述

　　這篇文章側重講HDBS代碼存在的質量問題，至於怎麼用、怎麼搭建sonar代碼異常檢測平臺後續再講。

• SonarQube簡介

　　SonarQube系統是一個代碼質量檢測工具，主要用於檢測代碼的編寫質量，好比：覆蓋率、是否包含空指針異常、異常是否正確處理、map的遍歷優化、是否包含無用代碼塊佔據cpu資源等。 由如下四個組件組成（https://docs.sonarqube.org/display/SONAR/Architecture+and+Integration）

1.    一個sonarqube服務器 包含三個子進程（web服務（界面管理），搜索服務 計算引擎服務（寫入數據庫））
2.  一個sonarqube數據庫 配置sonarqube服務
3.   多個sonarqube插件 位於解壓目錄 extensions\plugins目錄
4. 一個或者多個sonarqube scanners 用於分析特定的項目

• 使用SonarQube(簡稱SQ)工做流程

 　　開發者使用開發工具（eclipse,ide）上傳代碼到SCM(源代碼管理器)    系統自動同步代碼到某個位置 sonarqube scanners 掃描該代碼檢查質量 將分析結果 將分析結果推送到SQServer 存儲在SQ數據庫 用戶可使用eclipse插件sonarlint來同步sonarqube服務器配置（java和js版本等）能夠實時在線分析。

 

 3、HDBS代碼優化

• 代碼優化的重要性

　　經過sonar代碼檢測平臺針對性地解決代碼中相關問題。在大項目中代碼質量尤其重要，雖然這些代碼問題並非錯誤，在正常的數據狀況下是不會發生問題的，可是也有不少狀況是數據不正常的時候；一個小小的bug可能致使成千上萬的訂單做廢，性能的優化也很重要由於性能的優化可使得QPS顯著上升，代碼問題最爲嚴重的就可能致使整個實例掛掉(JVM異常退出)。因此代碼質量的提高是重中之重。

• 如何優化

　　因爲HDBS是經由不一樣的開發人員之手整體代碼質量參差不其，雖然公司有一套開發手冊可是執行起來彷佛比較難；可是事實告訴咱們：開發中要儘量第按照公司開發手冊，若是沒有就要按照通用的開發規範進行開發，好比遵循阿里的開發規範，畢竟大公司走過的路躺過的坑仍是比較多的咱們要學會站在巨人的肩膀上往上爬。做爲程序員開發效率實際上是第一位，在實際開發中咱們要學會使用工具來取得開發的最大效率，好比：這裏咱們採用sonar來管理代碼質量問題、能夠用SourceTree來管理git代碼等；合理使用對應的工具能夠達到開發效率的最大化，畢竟公司要的是一個可以有產出的人，若是你一天可以解決的問題而別人須要兩天那麼你就能獲得上司的賞識。

4、總結開發注意點

• HDBS代碼中發現的問題（部分）

1. 異常沒有正確處理。好比：直接在代碼中使用e.printStackTrace代碼打印異常；這是有一個問題就是：這些代碼在本地啓動遇到異常後是能夠正常打印異常信息，可是當應用部署到Linux服務器的時候卻可能不會打印，這若是在線上生產環境發生問題須要盤查的時候就尷尬了，由於你可能根本找不到異常的信息也就是說系統壓根就沒有記錄任何異常信息。
   解決方法：LOGGER.error（"xx異常:{}"，e）
2. 可能發生NullPointerException。好比：前面的代碼定義了 Map<Object,Object> map=null; 但後面在沒有判斷obj是否爲null的狀況下進行map.size()的操做；這也是咱們須要注意的地方，這種代碼邏輯通常咱們是不會進行異常處理的，異常處理要遵循：可以不須要異常處理就不要用異常處理不能把異常處理當作工具來使用。這種狀況下若是沒判斷爲null就進行操做就會發生運行時異常當前線程就會意外終止。
   解決方法：先判斷是否爲null
3. Map的遍歷方式優化。在開發中我見過不少人是這樣遍歷Map的：先獲得keySet()視圖，而後遍歷keys，經過get(key)的方式來獲取對應的value。這種遍歷性能實際上是不好的，由於咱們在遍歷keys的時候須要花費必定的時間，在get(key)的時候又會花費必定的時間；咱們都知道Map的get()是要計算hashCode而後經過hashCode計算數組的下標，若是有hash衝突又會遍歷鏈表，這種遍歷方式顯然是低效的，cpu資源是寶貴的這種方式會嚴重佔用cpu而且時間花費的要長得多。
   解決方法：經過entrySet()獲取key、value視圖，一次遍歷就能夠獲取對應的value，而不須要經過get()；不過你也能夠用迭代遍歷，這都是能夠的。
4. 日誌打印不規範。好比：LOGGER.info(「請求參數：」+params.toString); 日誌是盤查問題的關鍵信息，因此在一個系統中無處不在，一個線程可能產生的log數量就是成百上千行，若是每條日誌都這麼打印的話會嚴重影響整個應用的性能。由於字符串拼接的性能是不好的，相信咱們都對String不陌生，像這種String c=a+b的方式性能有多好本身也清楚。
   解決方法：LOGGER.info(「請求參數：{}」，params.toString)
5. 沒有考慮線程安全問題。如：在多線程系統應用HashMap；線程安全的概念簡單來說就是：同一個代碼塊在單線程和多線程的執行狀況下的結果是同樣的，不然線程非安全。若是在多線程系統應用了HashMap可能致使多個線程之間數據混淆或者是嚴重佔用系統資源，佔用系統資源即爲發生了循環鏈表的問題，具體爲何產生循環鏈表這裏就很少加闡述了；同時String、StringBuffer、StringBuilder也相似。
   解決方法：用HashTable或者ConCurrentHashMap替換HashMap
6. 無效代碼。好比：Date date=new Date()，在判斷date是不是空的時候用if( date!=null && !"".equal(date))；咱們都知道date是Date類型永遠也不多是String類型，可是在寫代碼的時候咱們卻又一個習慣喜歡加上"".equal(date)來判斷，固然這麼寫是不會有錯的，雖然Date不是Strng可是因爲 is-a的原則他們的父類都是Object，而equal是Object的方法因此那樣判斷天然也沒有錯。這裏講的不僅僅是Date這個類型，若是是非String類型都這樣；還有就是當咱們使用List<String> list=new ArrayList<>的方式的時候，後續用list這個對象的時候不須要判斷是否爲null，由於new出來的對象在沒有被JVM回收以前引用的對象永遠是非null。
   解決方法：去除無效代碼
7. 合理使用同步鎖。好比：全局定義了一個private static final DateFormat df=new SimpleDateFormat(「yyyy-MM-dd HH:MM:ss」)變量; 在該類中使用到df對象的時候都應用了同步鎖；若是在線程並大量大的時候同步鎖會嚴重佔用系統資源的開銷，由於得到鎖與釋放鎖的過程都是須要佔用資源的同時也會帶來併發量的降低，因此在能不用同步鎖解決問題的時候儘量不使用鎖，萬不得已的時候就可使用。
   解決方法：去除同步鎖，在方法中定義局部變量：DateFormat df=new SimpleDateFormat(「yyyy-MM-dd HH:MM:ss」)