編寫高質量代碼:改善Java程序的151個建議(第10章:性能和效率，第11章:開源世界，第12章:思想爲源___建議132~151)

時間 2019-11-07

標籤編寫高質量代碼改善 java 程序建議性能效率開源世界思想欄目 Java 简体版

原文原文鏈接

第10章:性能和效率java

建議132：提高Java性能的基本方法程序員

建議133：若非必要，不要克隆對象數據庫

建議134：推薦使用「望聞問切」的方式診斷性能數組

建議135：必須定義性能衡量標準性能優化

建議136：槍打出頭鳥--解決首要系統性能問題網絡

建議137：調整JVM參數以提升性能架構

建議138：性能是個大「咕咚」併發

第11章：開源世界框架

建議139：大膽採用開源工具ide

建議140：推薦使用Guava擴展工具包

建議141：Apache工具包

建議142：推薦使用Joda日期擴展包

建議143：能夠選擇多種Collection擴展

第十二章：思想爲源

建議144：提倡良好的代碼風格

建議145：不要徹底依靠單元測試來發現問題

建議146：讓註釋正確、清晰、簡潔

建議147：讓接口的職責保持單一

建議148：加強類的可替換性

建議149：依賴抽象而不是實現

建議150：拋棄七條不良的編碼習慣

建議151：以技術員自律而不是工人

第10章:性能和效率

建議132：提高Java性能的基本方法

JAVA性能優化：35個小細節讓你提高java代碼的運行效率

建議133：若非必要，不要克隆對象

JVM對new進行了大量的性能優化，而clone方式只是一個冷僻的生成對象方式，並非主流，它主要用於構造函數比較複雜，對象屬性比較多，經過new關鍵字建立一個對象比較耗時間的時候。

建議134：推薦使用「望聞問切」的方式診斷性能

一、望

性能問題從表象上能夠分爲兩類：

① 較難重現的偶發性問題

② 可重現的性能問題

二、聞

在性能優化上的「聞」則是關注項目被動產生的信息，其中包括：項目組的技術能力（主要取決於技術經理的技術能力）、文化氛圍、羣體的習慣和習性，以及他們專一和擅長的領域等。
@若是項目組的技術能力很強，有資深的數據庫專家，有頂尖的架構師，也有首席程序員，那性能問題產生的根源就應該定位在無心識的代碼缺陷上。
@若是項目組的文化氛圍很糟糕，組員不交流，沒有固定的代碼規範，缺少總體的架構等，那性能問題的根源就可能存在於某個配置上，或者相互的接口調用上。
@若是項目組已經習慣了某一個框架，並且也習慣了框架的種種約束，那性能的根源就多是有人越過了框架的協約。

三、問

與技術人員和業務人員一塊兒探討問題，瞭解性能問題的歷史情況。

四、切

看設計，看代碼，看日誌，看系統環境，而後是思考分析，最後給出結論。

建議135：必須定義性能衡量標準

出現性能問題不可怕，可怕的是沒有目標。

一、核心業務的響應時間

二、重要業務的響應時間

性能衡量標準必須在必定的環境下，好比網絡、操做系統、硬件設備等肯定的狀況下才會有意義，而且還須要限定併發數、資源數（如10萬數據和1000萬的數據響應時間確定不一樣）等。

建議136：槍打出頭鳥--解決首要系統性能問題

解決性能問題時，不要把全部的問題都擺在眼前，這隻會「擾亂」你的思惟，集中精力，找到那個「出頭鳥」，解決它，在大部分狀況下，一批性能問題都會迎刃而解，並且咱們的用戶關注最多的可能就是系統20%的功能，可能咱們解決了這一部分，已經達到了用戶的預期目標，也就標誌着咱們的優化工做能夠結束了。

建議137：調整JVM參數以提升性能

一、調整堆內存大小

二、調整堆內存中各分區的比例

三、變動GC的垃圾回收策略

四、更換JVM

注意點：
metaSpace在jdk1.7以前被稱爲Permanent Space
並且嚴格意義上講metaSpace不屬於堆空間
見下圖：

關於部分調優項的介紹

建議138：性能是個大「咕咚」

一、沒有慢的系統，只有不知足業務的系統
二、沒有慢的系統，只有架構不良的系統
三、沒有慢的系統，只有懶惰的技術人員
四、沒有慢的系統，只有不肯意投入的系統

第11章：開源世界

建議139：大膽採用開源工具

在選擇開源工具和框架時要遵循必定的原則：

一、普適性原則

確保大部分項目成員對工具都比較熟悉

二、惟一性原則

相同的工具只選擇一個或一種，不要讓多種相同或類似職能的工具共存。
例如集合工具能夠在Apache Commons的collections包和Google Guava的Collections工具包中二選其一。

三、用比較有名的開源工具

四、精而專原則

好比雖然Spring框架提供了Utils工具包，但在通常狀況下不要使用它，由於它不專，Utils工具包只是Spring框架中的一個附加功能而已，要用就用Apache Commons的BeanUtils、Lang等工具包。

五、高熱度原則

一個開源項目的熱度越高，更新得就越頻繁，使用的人羣就越廣，Bug的曝光率就越快，修復效率也就越高。

建議140：推薦使用Guava擴展工具包

建議141：Apache工具包

建議142：推薦使用Joda日期擴展包

一、本地格式的日期時間

二、日期計算

三、時區時間

四、能夠與JDK的日期庫方便地進行轉換

建議143：能夠選擇多種Collection擴展

三個比較有個性的Collections擴展工具包：

一、fastutil

主要提供了兩種功能：一種是限定鍵值類型（Type Specific）的Map、List、Set等，另外一種是大容量的集合。

二、Trove

提供了一個快速、高效、低內存消耗的Collections集合，而且還提供了過濾和攔截的功能，同時還提供了基本類型的集合。

Trove的最大優點在於高性能上，在進行通常的增長、修改、刪除操做時，Trove的響應時間比JDK的集合少了一個數量級，比fastutil也會高不少，所以在高性能項目中藥考慮使用Trove。

三、lambdaj

lambdaj是一個純淨的集合操做工具，他不會提供任何的集合擴展，只會提供集合的操做，好比查詢、過濾、統一初始化等，特別是它的查詢操做，會提供求和、求平均值的方法：

List＜Integer＞ints=new ArrayList＜Integer＞();
//計算平均值
Lambda.avg（ints）;
//統計每一個元素出現的次數，返回的是一個Map
Lambda.count（ints）；
//按照年齡排序
List＜Person＞persons=new ArrayList＜Person＞();
Lambda.sort（persons, Lambda.on（Person.class）.getAge()));
//串聯全部元素的指定屬性，輸出爲：張三，李四，王五
Lambda.joinFrom（persons）.getName();
//過濾出年齡大於20歲的所用元素，輸出爲一個子列表
Lambda.select（persons, new BaseMatcher＜Person＞(){
@Override
public boolean matches（Object_person）{
Person p=（Person）_person；
return p.getAge（）＞20；
}
public void describeTo（Description desc）{
}
});
//查找出最大年齡
Lambda.maxFrom（persons）.getAge();
//抽取出全部姓名造成一個數組
Lambda.extract（persons, Lambda.on（Person.class）.getName()));

第十二章：思想爲源

建議144：提倡良好的代碼風格

一、整潔

二、統一

三、流行

四、便捷

建議145：不要徹底依靠單元測試來發現問題

一、單元測試不可能測試全部的場景（路徑）
單元測試必須測試的三種數據場景是：正常場景、邊界場景、異常場景。若是要進行完整的測試就必須創建三個不一樣的測試場景：正常數據場景，用來測試代碼的主邏輯；邊界數據場景，用來測試代碼（或數據）在邊界的狀況下邏輯是否正確；異常數據場景，用來測試出現異常非故障時可否按照預期運行。
一般在項目中，單元測試覆蓋率很難達到60%，由於不能100%覆蓋，這就致使了代碼測試的不完整性，隱藏的缺陷也就必然存在了。
二、代碼整合錯誤是不可避免的

三、部分代碼沒法測試

四、單元測試驗證的是編碼人員的假設

建議146：讓註釋正確、清晰、簡潔

提倡好的註釋：
一、法律版權信息
二、解釋意圖的註釋
說明爲何要這樣作，而不是怎麼作的，好比解決了哪一個Bug，方法過期的緣由是什麼。
三、警示性註釋
四、TODO註釋

建議147：讓接口的職責保持單一

單一職責有如下三個優勢：
一、類的複雜性下降
二、可讀性和可維護性提升
三、下降變動風險

建議148：加強類的可替換性

里氏替換原則：全部引用基類的地方必須能透明地使用其子類的對象。

建議149：依賴抽象而不是實現

依賴倒置原則（Dependence Inversion Principle，簡稱DIP）:
高層模塊不該該依賴低層模塊，二者都應該依賴其抽象。
抽象不該該依賴細節。
細節應該依賴抽象。

要作到遵循此原則要作到如下幾點：
（1）儘可能抽象
接口和抽象類都是屬於抽象的，有了抽象纔可能依賴倒置。
（2）表面類型必須是抽象的
好比定義集合，儘可能使用：
List＜String＞list=new ArrayList＜String＞（）；
（3）任何類都不該該從具體類派生
開發階段要作到這一點，但不是絕對的，尤爲是在維護時。
（4）儘可能不要覆寫基類的方法
（5）抽象不關注細節

建議150：拋棄七條不良的編碼習慣

一、自由格式的代碼

二、不使用抽象的代碼

三、彰顯個性的代碼

四、死代碼

五、冗餘的代碼

六、拒絕變化的代碼

七、自覺得是的代碼

建議151：以技術員自律而不是工人

一、熟悉工具

二、使用IDE

三、堅持編碼