HDBS之應用程式碼優化
一、目錄結構樹
- 總體概述
- 程式碼檢測工具sonar
- HDBS程式碼優化
- 總結開發注意點
二、總體概述
進入現在這家公司我的第一個任務就是對HDBS進行程式碼質量優化。HDBS可能大家不是很瞭解，現在給大家簡單介紹下：HDBS是HadoopBaseService的簡稱，Hadoop有了解過大資料的朋友相信並不陌生，BaseService自然也就是基礎服務的意思；所以HDBS這個服務主要是基礎服務的配置，同時Hadoop則表示資料量的大。以下是我暫時瞭解的應用架構圖方便各位理解，畢竟才來這個公司一個星期可能畫的不是很完整不過總體就是這麼回事：
二、程式碼檢測工具
-
前提描述
這篇文章側重講HDBS程式碼存在的質量問題，至於怎麼用、怎麼搭建sonar程式碼異常檢測平臺後續再講。
-
SonarQube簡介
SonarQube系統是一個程式碼質量檢測工具，主要用於檢測程式碼的編寫質量，比如：覆蓋率、是否包含空指標異常、異常是否正確處理、map的遍歷優化、是否包含無用程式碼塊佔據cpu資源等。 由以下四個元件組成（https://docs.sonarqube.org/display/SONAR/Architecture+and+Integration）
- 一個sonarqube伺服器 包含三個子程序（web服務（介面管理），搜尋服務 計算引擎服務（寫入資料庫））
- 一個sonarqube資料庫 配置sonarqube服務
- 多個sonarqube外掛 位於解壓目錄 extensions\plugins目錄
- 一個或者多個sonarqube scanners 用於分析特定的專案
- 使用SonarQube(簡稱SQ)工作流程
開發者使用開發工具（eclipse,ide）上傳程式碼到SCM(原始碼管理器) 系統自動同步程式碼到某個位置 sonarqube scanners 掃描該程式碼檢查質量 將分析結果 將分析結果推送到SQServer 儲存在SQ資料庫 使用者可以使用eclipse外掛sonarlint來同步sonarqube伺服器配置（java和js版本等）可以實時線上分析。
三、HDBS程式碼優化
- 程式碼優化的重要性
通過sonar程式碼檢測平臺針對性地解決程式碼中相關問題。在大專案中程式碼質量尤為重要，雖然這些程式碼問題並不是錯誤，在正常的資料情況下是不會發生問題的，但是也有很多情況是資料不正常的時候；一個小小的bug可能導致成千上萬的訂單作廢，效能的優化也很重要因為效能的優化可以使得QPS顯著上升，程式碼問題最為嚴重的就可能導致整個例項掛掉(JVM異常退出)。所以程式碼質量的提升是重中之重。
- 如何優化
由於HDBS是經由不同的開發人員之手總體程式碼質量參差不其，雖然公司有一套開發手冊但是執行起來似乎比較難；但是事實告訴我們：開發中要儘可能第按照公司開發手冊，如果沒有就要按照通用的開發規範進行開發，比如遵循阿里的開發規範，畢竟大公司走過的路躺過的坑還是比較多的我們要學會站在巨人的肩膀上往上爬。作為程式員開發效率其實是第一位，在實際開發中我們要學會使用工具來取得開發的最大效率，比如：這裡我們採用sonar來管理程式碼質量問題、可以用SourceTree來管理git程式碼等；合理使用對應的工具可以達到開發效率的最大化，畢竟公司要的是一個能夠有產出的人，如果你一天能夠解決的問題而別人需要兩天那麼你就能得到上司的賞識。
四、總結開發注意點
- HDBS程式碼中發現的問題（部分）
- 異常沒有正確處理。比如：直接在程式碼中使用e.printStackTrace程式碼列印異常；這是有一個問題就是：這些程式碼在本地啟動遇到異常後是可以正常列印異常資訊，但是當應用部署到Linux伺服器的時候卻可能不會列印，這如果在線上生產環境發生問題需要盤查的時候就尷尬了，因為你可能根本找不到異常的資訊也就是說系統壓根就沒有記錄任何異常資訊。
解決方法 ：LOGGER.error（"xx異常:{}"，e） - 可能發生NullPointerException。比如：前面的程式碼定義了 Map<Object,Object> map=null; 但後面在沒有判斷obj是否為null的情況下進行map.size()的操作；這也是我們需要注意的地方，這種程式碼邏輯一般我們是不會進行異常處理的，異常處理要遵循：能夠不需要異常處理就不要用異常處理不能把異常處理當做工具來使用。這種情況下如果沒判斷為null就進行操作就會發生執行時異常當前執行緒就會意外終止。
解決方法 ：先判斷是否為null - Map的遍歷方式優化。在開發中我見過很多人是這樣遍歷Map的：先得到keySet()檢視，然後遍歷keys，通過get(key)的方式來獲取對應的value。這種遍歷效能其實是很差的，因為我們在遍歷keys的時候需要花費一定的時間，在get(key)的時候又會花費一定的時間；我們都知道Map的get()是要計算hashCode然後通過hashCode計算陣列的下標，如果有hash衝突又會遍歷連結串列，這種遍歷方式顯然是低效的，cpu資源是寶貴的這種方式會嚴重佔用cpu並且時間花費的要長得多。
解決方法 ：通過entrySet()獲取key、value檢視，一次遍歷就可以獲取對應的value，而不需要通過get()；不過你也可以用迭代遍歷，這都是可以的。 - 日誌列印不規範。比如：LOGGER.info(“請求引數：”+params.toString); 日誌是盤查問題的關鍵資訊，所以在一個系統中無處不在，一個執行緒可能產生的log數量就是成百上千行，如果每條日誌都這麼列印的話會嚴重影響整個應用的效能。因為字串拼接的效能是很差的，相信我們都對String不陌生，像這種String c=a+b的方式效能有多好自己也清楚。
解決方法 ：LOGGER.info(“請求引數：{}”，params.toString) - 沒有考慮執行緒安全問題。如：在多執行緒系統應用HashMap；執行緒安全的概念簡單來講就是：同一個程式碼塊在單執行緒和多執行緒的執行情況下的結果是一樣的，否則執行緒非安全。如果在多執行緒系統應用了HashMap可能導致多個執行緒之間資料混淆或者是嚴重佔用系統資源，佔用系統資源即為發生了迴圈連結串列的問題，具體為什麼產生迴圈連結串列這裡就不多加闡述了；同時String、StringBuffer、StringBuilder也類似。
解決方法 ：用HashTable或者ConCurrentHashMap替換HashMap - 無效程式碼。比如：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。
解決方法 ：去除無效程式碼 - 合理使用同步鎖。比如：全域性定義了一個private static final DateFormat df=new SimpleDateFormat(“yyyy-MM-dd HH:MM:ss”)變數; 在該類中使用到df物件的時候都應用了同步鎖；如果線上程並大量大的時候同步鎖會嚴重佔用系統資源的開銷，因為獲得鎖與釋放鎖的過程都是需要佔用資源的同時也會帶來併發量的下降，所以在能不用同步鎖解決問題的時候儘可能不使用鎖，萬不得已的時候就可以使用。
解決方法 ：去除同步鎖，在方法中定義區域性變數：DateFormat df=new SimpleDateFormat(“yyyy-MM-dd HH:MM:ss”)
Linux公社的RSS地址： ofollow,noindex" target="_blank">https://www.linuxidc.com/rssFeed.aspx
本文永久更新連結地址： https://www.linuxidc.com/Linux/2018-09/154206.htm