一、背景

針對老項(xiàng)目，去年做了許多降本增效的事情，其中發(fā)現(xiàn)最多的就是接口耗時(shí)過長的問題，就集中搞了一次接口性能優(yōu)化。本文將給小伙伴們分享一下接口優(yōu)化的通用方案。

(資料圖)

二、接口優(yōu)化方案總結(jié)

1. 批處理

批量思想：批量操作數(shù)據(jù)庫，這個(gè)很好理解，我們在循環(huán)插入場景的接口中，可以在批處理執(zhí)行完成后一次性插入或更新數(shù)據(jù)庫，避免多次 IO。

//for循環(huán)單筆入庫list.stream().forEatch(msg->{    insert();});//批量入庫batchInsert();

2. 異步處理

異步思想：針對耗時(shí)比較長且不是結(jié)果必須的邏輯，我們可以考慮放到異步執(zhí)行，這樣能降低接口耗時(shí)。

例如一個(gè)理財(cái)?shù)纳曩徑涌冢?/span>入賬和寫入申購文件是同步執(zhí)行的，因?yàn)槭?T+1 交易，后面這兩個(gè)邏輯其實(shí)不是結(jié)果必須的，我們并不需要關(guān)注它的實(shí)時(shí)結(jié)果，所以我們考慮把入賬和寫入申購文件改為異步處理。如圖所示：

至于異步的實(shí)現(xiàn)方式，可以用線程池，也可以用消息隊(duì)列，還可以用一些調(diào)度任務(wù)框架。

3. 空間換時(shí)間

一個(gè)很好理解的空間換時(shí)間的例子是合理使用緩存，針對一些頻繁使用且不頻繁變更的數(shù)據(jù)，可以提前緩存起來，需要時(shí)直接查緩存，避免頻繁地查詢數(shù)據(jù)庫或者重復(fù)計(jì)算。

需要注意的事，這里用了合理二字，因?yàn)榭臻g換時(shí)間也是一把雙刃劍，需要綜合考慮你的使用場景，畢竟緩存帶來的數(shù)據(jù)一致性問題也挺令人頭疼。

這里的緩存可以是 R2M，也可以是本地緩存、memcached，或者 Map。

舉一個(gè)股票工具的查詢例子：

因?yàn)椴呗暂唲?dòng)的調(diào)倉信息，每周只更新一次，所以原來的調(diào)接口就去查庫的邏輯并不合理，而且拿到調(diào)倉信息后，需要經(jīng)過復(fù)雜計(jì)算，最終得出回測收益和跑贏滬深指數(shù)這些我們想要的結(jié)果。如果我們把查庫操作和計(jì)算結(jié)果放入緩存，可以節(jié)省很多的執(zhí)行時(shí)間。如圖：

4. 預(yù)處理

也就是預(yù)取思想，就是提前要把查詢的數(shù)據(jù)，提前計(jì)算好，放入緩存或者表中的某個(gè)字段，用的時(shí)候會(huì)大幅提高接口性能。跟上面那個(gè)例子很像，但是關(guān)注點(diǎn)不同。

舉個(gè)簡單的例子：理財(cái)產(chǎn)品，會(huì)有根據(jù)凈值計(jì)算年化收益率的數(shù)據(jù)展示需求，利用凈值去套用年化收益率計(jì)算公式計(jì)算的邏輯我們可以采用預(yù)處理，這樣每一次接口調(diào)用直接取對應(yīng)字段就可以了。

5. 池化思想

我們都用過數(shù)據(jù)庫連接池，線程池等，這就是池思想的體現(xiàn)，它們解決的問題就是避免重復(fù)創(chuàng)建對象或創(chuàng)建連接，可以重復(fù)利用，避免不必要的損耗，畢竟創(chuàng)建銷毀也會(huì)占用時(shí)間。

池化思想包含但并不局限于以上兩種，總的來說池化思想的本質(zhì)是預(yù)分配與循環(huán)使用，明白這個(gè)原理后，我們即使是在做一些業(yè)務(wù)場景的需求時(shí)，也可以利用起來。

比如：對象池

6. 串行改并行

串行就是，當(dāng)前執(zhí)行邏輯必須等上一個(gè)執(zhí)行邏輯結(jié)束之后才執(zhí)行，并行就是兩個(gè)執(zhí)行邏輯互不干擾，所以并行相對來說就比較節(jié)省時(shí)間，當(dāng)然是建立在沒有結(jié)果參數(shù)依賴的前提下。

比如，理財(cái)?shù)某謧}信息展示接口，我們既需要查詢用戶的賬戶信息，也需要查詢商品信息和 banner 位信息等等來渲染持倉頁，如果是串行，基本上接口耗時(shí)就是累加的。如果是并行，接口耗時(shí)將大大降低。

如圖：

圖片

7. 索引

加索引能大大提高數(shù)據(jù)查詢效率，這個(gè)在接口設(shè)計(jì)之出也會(huì)考慮到，這里不再多贅述，隨著需求的迭代，我們重點(diǎn)整理一下索引不生效的一些場景，希望對小伙伴們有所幫助。

具體不生效場景不再一一舉例，后面有時(shí)間的話，單獨(dú)整理一下。

8. 避免大事務(wù)

所謂大事務(wù)問題，就是運(yùn)行時(shí)間較長的事務(wù)，由于事務(wù)一致不提交，會(huì)導(dǎo)致數(shù)據(jù)庫連接被占用，影響到別的請求訪問數(shù)據(jù)庫，影響別的接口性能。

舉個(gè)例子：

@Transactional(value ="taskTransactionManager", propagation =Propagation.REQUIRED, isolation =Isolation.READ_COMMITTED, rollbackFor ={RuntimeException.class,Exception.class})    publicBasicResultpurchaseRequest(PurchaseRecordrecord){        BasicResult result =newBasicResult();        //插入賬戶任務(wù)        taskMapper.insert(ManagerParamUtil.buildTask(record,TaskEnum.Task_type.pension_account.type(),TaskEnum.Account_bizType.purchase_request.type()));        //插入同步任務(wù)        taskMapper.insert(ManagerParamUtil.buildTask(record,TaskEnum.Task_type.pension_sync.type(),TaskEnum.Sync_bizType.purchase.type()));        //插入影像件上傳任務(wù)        taskMapper.insert(ManagerParamUtil.buildTask(record,TaskEnum.Task_type.pension_sync.type(),TaskEnum.Sync_bizType.cert.type()));        result.setInfo(ResultInfoEnum.SUCCESS);        return result;    }

上面這塊代碼主要是申購申請完成后，執(zhí)行一系列的后續(xù)操作，如果現(xiàn)在新增申購?fù)瓿珊螅l(fā)送 push 通知用戶的需求。很有可能我們會(huì)在后面直接追加，如下圖所示：事務(wù)中嵌套 RPC 調(diào)用，即非 DB 操作，這些非 DB 操作如果耗時(shí)較大的話，可能會(huì)出現(xiàn)大事務(wù)問題。大數(shù)據(jù)引發(fā)的問題主要有：死鎖、接口超時(shí)、主從延遲等。

@Transactional(value ="taskTransactionManager", propagation =Propagation.REQUIRED, isolation =Isolation.READ_COMMITTED, rollbackFor ={RuntimeException.class,Exception.class})    publicBasicResultpurchaseRequest(PurchaseRecordrecord){        BasicResult result =newBasicResult();        ...        pushRpc.doPush(record);        result.setInfo(ResultInfoEnum.SUCCESS);        return result;    }

所以為避免大事務(wù)問題，我們可以通過以下方案規(guī)避：

1，RPC 調(diào)用不放到事務(wù)里面

2，查詢操作盡量放到事務(wù)之外

3，事務(wù)中避免處理太多數(shù)據(jù)

9. 優(yōu)化程序結(jié)構(gòu)

程序結(jié)構(gòu)問題一般出現(xiàn)在多次需求迭代后，代碼疊加形成。會(huì)造成一些重復(fù)查詢、多次創(chuàng)建對象等耗時(shí)問題。在多人維護(hù)一個(gè)項(xiàng)目時(shí)比較多見。解決起來也比較簡單，我們需要針對接口整體做重構(gòu)，評估每個(gè)代碼塊的作用和用途，調(diào)整執(zhí)行順序。

10. 深分頁問題

深分頁問題比較常見，分頁我們一般最先想到的就是 limit ，為什么會(huì)慢，我們可以看下這個(gè) SQL：

select*from purchase_record where productCode ="PA9044"andstatus=4orderby orderTime desclimit100000,200

limit 100000,200 意味著會(huì)掃描 100200 行，然后返回 200 行，丟棄掉前 100000 行。所以執(zhí)行速度很慢。一般可以采用標(biāo)簽記錄法來優(yōu)化，比如：

select*from purchase_record where productCode ="PA9044"andstatus=4and id >100000limit200

這樣優(yōu)化的好處是命中了主鍵索引，無論多少頁，性能都還不錯(cuò)，但是局限性是需要一個(gè)連續(xù)自增的字段

11.SQL 優(yōu)化

sql 優(yōu)化能大幅提高接口的查詢性能，由于本文重點(diǎn)講述接口優(yōu)化的方案，具體 sql 優(yōu)化不再一一列舉，小伙伴們可以結(jié)合索引、分頁、等關(guān)注點(diǎn)考慮優(yōu)化方案。

12. 鎖粒度避免過粗

鎖一般是為了在高并發(fā)場景下保護(hù)共享資源采用的一種手段，但是如果鎖的粒度太粗，會(huì)很影響接口性能。

關(guān)于鎖粒度：就是你要鎖的范圍有多大，不管是 synchronized 還是 redis 分布式鎖，只需要在臨界資源處加鎖即可，不涉及共享資源的，不必要加鎖，就好比你要上衛(wèi)生間，只需要把衛(wèi)生間的門鎖上就可以，不需要把客廳的門也鎖上。

錯(cuò)誤的加鎖方式：

//非共享資源privatevoidnotShare(){}//共享資源privatevoidshare(){}privateintwrong(){    synchronized(this){      share();      notShare();    }}

正確的加鎖方式：

//非共享資源privatevoidnotShare(){}//共享資源privatevoidshare(){}privateintright(){    notShare();    synchronized(this){    share(); }}

（三）Java性能優(yōu)化的55個(gè)細(xì)節(jié)

1. 盡量在合適的場合使用單例

使用單例可以減輕加載的負(fù)擔(dān)，縮短加載的時(shí)間，提高加載的效率，但并不是所有地方都適用于單例，簡單來說，單例主要適用于以下三個(gè)方面：

第一，控制資源的使用，通過線程同步來控制資源的并發(fā)訪問；

第二，控制實(shí)例的產(chǎn)生，以達(dá)到節(jié)約資源的目的；

第三，控制數(shù)據(jù)共享，在不建立直接關(guān)聯(lián)的條件下，讓多個(gè)不相關(guān)的進(jìn)程或線程之間實(shí)現(xiàn)通信。

2. 盡量避免隨意使用靜態(tài)變量

要知道，當(dāng)某個(gè)對象被定義為static變量所引用，那么GC通常是不會(huì)回收這個(gè)對象所占有的內(nèi)存，如

public class A{    private static B b = new B(); }

此時(shí)靜態(tài)變量b的生命周期與A類同步，如果A類不會(huì)卸載，那么b對象會(huì)常駐內(nèi)存，直到程序終止。

3. 盡量避免過多過常的創(chuàng)建Java對象

盡量避免在經(jīng)常調(diào)用的方法，循環(huán)中new對象，由于系統(tǒng)不僅要花費(fèi)時(shí)間來創(chuàng)建對象，而且還要花時(shí)間對這些對象進(jìn)行垃圾回收和處理，在我們可以控制的范圍內(nèi)，最大限度的重用對象，最好能用基本的數(shù)據(jù)類型或數(shù)組來替代對象。

4. 盡量使用final修飾符

帶有final修飾符的類是不可派生的。在JAVA核心API中，有許多應(yīng)用final的例子，例如java.lang.String，為String類指定final防止了使用者覆蓋length()方法。另外，如果一個(gè)類是final的，則該類所有方法都是final的。java編譯器會(huì)尋找機(jī)會(huì)內(nèi)聯(lián)（inline）所有的final方法（這和具體的編譯器實(shí)現(xiàn)有關(guān)）。此舉能夠使性能平均提高50%。

如：讓訪問實(shí)例內(nèi)變量的getter/setter方法變成”final：

簡單的getter/setter方法應(yīng)該被置成final，這會(huì)告訴編譯器，這個(gè)方法不會(huì)被重載，所以，可以變成”inlined”,例子：

class MAF {      public void setSize (int size) {           _size = size;      }      private int _size; }更正class DAF_fixed {      final public void setSize (int size) {           _size = size;      }      private int _size; }

5. 盡量使用局部變量

調(diào)用方法時(shí)傳遞的參數(shù)以及在調(diào)用中創(chuàng)建的臨時(shí)變量都保存在棧（Stack）中，速度較快。其他變量，如靜態(tài)變量，實(shí)例變量等，都在堆（Heap）中創(chuàng)建，速度較慢。

6. 盡量處理好包裝類型和基本類型兩者的使用場所

雖然包裝類型和基本類型在使用過程中是可以相互轉(zhuǎn)換，但它們兩者所產(chǎn)生的內(nèi)存區(qū)域是完全不同的，基本類型數(shù)據(jù)產(chǎn)生和處理都在棧中處理，包裝類型是對象，是在堆中產(chǎn)生實(shí)例。在集合類對象，有對象方面需要的處理適用包裝類型，其他的處理提倡使用基本類型。

7. 慎用synchronized，盡量減小synchronize的方法

都知道，實(shí)現(xiàn)同步是要很大的系統(tǒng)開銷作為代價(jià)的，甚至可能造成死鎖，所以盡量避免無謂的同步控制。synchronize方法被調(diào)用時(shí)，直接會(huì)把當(dāng)前對象鎖 了，在方法執(zhí)行完之前其他線程無法調(diào)用當(dāng)前對象的其他方法。所以synchronize的方法盡量小，并且應(yīng)盡量使用方法同步代替代碼塊同步。

9. 盡量不要使用finalize方法

實(shí)際上，將資源清理放在finalize方法中完成是非常不好的選擇，由于GC的工作量很大，尤其是回收Young代內(nèi)存時(shí)，大都會(huì)引起應(yīng)用程序暫停，所以再選擇使用finalize方法進(jìn)行資源清理，會(huì)導(dǎo)致GC負(fù)擔(dān)更大，程序運(yùn)行效率更差。

10. 盡量使用基本數(shù)據(jù)類型代替對象

String str = "hello";

上面這種方式會(huì)創(chuàng)建一個(gè)“hello”字符串，而且JVM的字符緩存池還會(huì)緩存這個(gè)字符串；

String str = new String("hello");

此時(shí)程序除創(chuàng)建字符串外，str所引用的String對象底層還包含一個(gè)char[]數(shù)組，這個(gè)char[]數(shù)組依次存放了h,e,l,l,o

11. 多線程在未發(fā)生線程安全前提下應(yīng)盡量使用HashMap、ArrayList

HashTable、Vector等使用了同步機(jī)制，降低了性能。

12. 盡量合理的創(chuàng)建HashMap

當(dāng)你要?jiǎng)?chuàng)建一個(gè)比較大的hashMap時(shí)，充分利用這個(gè)構(gòu)造函數(shù)

public HashMap(int initialCapacity, float loadFactor);

避免HashMap多次進(jìn)行了hash重構(gòu),擴(kuò)容是一件很耗費(fèi)性能的事，在默認(rèn)中initialCapacity只有16，而loadFactor是 0.75，需要多大的容量，你最好能準(zhǔn)確的估計(jì)你所需要的最佳大小，同樣的Hashtable，Vectors也是一樣的道理。

13. 盡量減少對變量的重復(fù)計(jì)算

如：

for(int i=0;i<list.size();i++)

應(yīng)該改為

for(int i=0,len=list.size();i<len;i++)

并且在循環(huán)中應(yīng)該避免使用復(fù)雜的表達(dá)式，在循環(huán)中，循環(huán)條件會(huì)被反復(fù)計(jì)算，如果不使用復(fù)雜表達(dá)式，而使循環(huán)條件值不變的話，程序?qū)?huì)運(yùn)行的更快。

14. 盡量避免不必要的創(chuàng)建

如：

A a = new A();if(i==1){list.add(a);}

應(yīng)該改為

if(i==1){  A a = new A();  list.add(a);}

15. 盡量在finally塊中釋放資源

程序中使用到的資源應(yīng)當(dāng)被釋放，以避免資源泄漏。這最好在finally塊中去做。不管程序執(zhí)行的結(jié)果如何，finally塊總是會(huì)執(zhí)行的，以確保資源的正確關(guān)閉。

16. 盡量使用移位來代替"a/b"的操作

"/"是一個(gè)代價(jià)很高的操作，使用移位的操作將會(huì)更快和更有效

如

int num = a / 4;int num = a / 8;

應(yīng)該改為

int num = a >> 2;int num = a >> 3;

但注意的是使用移位應(yīng)添加注釋，因?yàn)橐莆徊僮鞑恢庇^，比較難理解

17.盡量使用移位來代替"a*b"的操作

同樣的，對于"*"操作，使用移位的操作將會(huì)更快和更有效

如

int num = a * 4;int num = a * 8;

應(yīng)該改為

int num = a << 2;int num = a << 3;

18. 盡量確定StringBuffer的容量

StringBuffer 的構(gòu)造器會(huì)創(chuàng)建一個(gè)默認(rèn)大?。ㄍǔＪ?6）的字符數(shù)組。在使用中，如果超出這個(gè)大小，就會(huì)重新分配內(nèi)存，創(chuàng)建一個(gè)更大的數(shù)組，并將原先的數(shù)組復(fù)制過來，再 丟棄舊的數(shù)組。在大多數(shù)情況下，你可以在創(chuàng)建 StringBuffer的時(shí)候指定大小，這樣就避免了在容量不夠的時(shí)候自動(dòng)增長，以提高性能。

如：

StringBuffer buffer = new StringBuffer(1000);

19. 盡量早釋放無用對象的引用

大部分時(shí)，方法局部引用變量所引用的對象 會(huì)隨著方法結(jié)束而變成垃圾，因此，大部分時(shí)候程序無需將局部，引用變量顯式設(shè)為null。

例如：

Java代碼

Public void test(){   Object obj = new Object();   ……   Obj=null; }

上面這個(gè)就沒必要了，隨著方法test()的執(zhí)行完成，程序中obj引用變量的作用域就結(jié)束了。但是如果是改成下面：

Java代碼

Public void test(){   Object obj = new Object();   ……   Obj=null;   //執(zhí)行耗時(shí)，耗內(nèi)存操作；或調(diào)用耗時(shí)，耗內(nèi)存的方法  …… }

這時(shí)候就有必要將obj賦值為null，可以盡早的釋放對Object對象的引用。

20. 盡量避免使用二維數(shù)組

二維數(shù)據(jù)占用的內(nèi)存空間比一維數(shù)組多得多，大概10倍以上。

21. 盡量避免使用split

除非是必須的，否則應(yīng)該避免使用split，split由于支持正則表達(dá)式，所以效率比較低，如果是頻繁的幾十，幾百萬的調(diào)用將會(huì)耗費(fèi)大量資源，如果確實(shí)需要頻繁的調(diào)用split，可以考慮使用apache的StringUtils.split(string,char)，頻繁split的可以緩存結(jié)果。

22. ArrayList & LinkedList

一個(gè)是線性表，一個(gè)是鏈表，一句話，隨機(jī)查詢盡量使用ArrayList，ArrayList優(yōu)于LinkedList，LinkedList還要移動(dòng)指針，添加刪除的操作LinkedList優(yōu)于ArrayList，ArrayList還要移動(dòng)數(shù)據(jù)，不過這是理論性分析，事實(shí)未必如此，重要的是理解好2者得數(shù)據(jù)結(jié)構(gòu)，對癥下藥。

23. 盡量使用System.arraycopy ()代替通過來循環(huán)復(fù)制數(shù)組

System.arraycopy() 要比通過循環(huán)來復(fù)制數(shù)組快的多

24. 盡量緩存經(jīng)常使用的對象

盡可能將經(jīng)常使用的對象進(jìn)行緩存，可以使用數(shù)組，或HashMap的容器來進(jìn)行緩存，但這種方式可能導(dǎo)致系統(tǒng)占用過多的緩存，性能下降，推薦可以使用一些第三方的開源工具，如EhCache，Oscache進(jìn)行緩存，他們基本都實(shí)現(xiàn)了FIFO/FLU等緩存算法。

25. 盡量避免非常大的內(nèi)存分配

有時(shí)候問題不是由當(dāng)時(shí)的堆狀態(tài)造成的，而是因?yàn)榉峙涫≡斐傻摹７峙涞膬?nèi)存塊都必須是連續(xù)的，而隨著堆越來越滿，找到較大的連續(xù)塊越來越困難。

26. 慎用異常

當(dāng)創(chuàng)建一個(gè)異常時(shí)，需要收集一個(gè)棧跟蹤(stack track)，這個(gè)棧跟蹤用于描述異常是在何處創(chuàng)建的。構(gòu)建這些棧跟蹤時(shí)需要為運(yùn)行時(shí)棧做一份快照，正是這一部分開銷很大。當(dāng)需要?jiǎng)?chuàng)建一個(gè) Exception 時(shí)，JVM 不得不說：先別動(dòng)，我想就您現(xiàn)在的樣子存一份快照，所以暫時(shí)停止入棧和出棧操作。棧跟蹤不只包含運(yùn)行時(shí)棧中的一兩個(gè)元素，而是包含這個(gè)棧中的每一個(gè)元素。

如果您創(chuàng)建一個(gè) Exception ，就得付出代價(jià)。好在捕獲異常開銷不大，因此可以使用 try-catch 將核心內(nèi)容包起來。從技術(shù)上講，您甚至可以隨意地拋出異常，而不用花費(fèi)很大的代價(jià)。招致性能損失的并不是 throw 操作——盡管在沒有預(yù)先創(chuàng)建異常的情況下就拋出異常是有點(diǎn)不尋常。真正要花代價(jià)的是創(chuàng)建異常。幸運(yùn)的是，好的編程習(xí)慣已教會(huì)我們，不應(yīng)該不管三七二十一就拋出異常。異常是為異常的情況而設(shè)計(jì)的，使用時(shí)也應(yīng)該牢記這一原則。

27. 盡量重用對象

特別是String對象的使用中，出現(xiàn)字符串連接情況時(shí)應(yīng)使用StringBuffer代替，由于系統(tǒng)不僅要花時(shí)間生成對象，以后可能還需要花時(shí)間對這些對象進(jìn)行垃圾回收和處理。因此生成過多的對象將會(huì)給程序的性能帶來很大的影響。

28. 不要重復(fù)初始化變量

默認(rèn)情況下，調(diào)用類的構(gòu)造函數(shù)時(shí)，java會(huì)把變量初始化成確定的值，所有的對象被設(shè)置成null，整數(shù)變量設(shè)置成0，float和double變量設(shè)置成0.0，邏輯值設(shè)置成false。當(dāng)一個(gè)類從另一個(gè)類派生時(shí)，這一點(diǎn)尤其應(yīng)該注意，因?yàn)橛胣ew關(guān)鍵字創(chuàng)建一個(gè)對象時(shí)，構(gòu)造函數(shù)鏈中的所有構(gòu)造函數(shù)都會(huì)被自動(dòng)調(diào)用。這里有個(gè)注意，給成員變量設(shè)置初始值但需要調(diào)用其他方法的時(shí)候，最好放在一個(gè)方法比如initXXX()中，因?yàn)橹苯诱{(diào)用某方法賦值可能會(huì)因?yàn)轭惿形闯跏蓟鴴伩罩羔槷惓?，如：public int state = this.getState();

29. 在java+Oracle的應(yīng)用系統(tǒng)開發(fā)中，java中內(nèi)嵌的SQL語言應(yīng)盡量使用大寫形式，以減少Oracle解析器的解析負(fù)擔(dān)。

30. 在java編程過程中，進(jìn)行數(shù)據(jù)庫連接，I/O流操作，在使用完畢后，及時(shí)關(guān)閉以釋放資源。因?yàn)閷@些大對象的操作會(huì)造成系統(tǒng)大的開銷。

31. 過分的創(chuàng)建對象會(huì)消耗系統(tǒng)的大量內(nèi)存，嚴(yán)重時(shí)，會(huì)導(dǎo)致內(nèi)存泄漏，因此，保證過期的對象的及時(shí)回收具有重要意義。JVM的GC并非十分智能，因此建議在對象使用完畢后，手動(dòng)設(shè)置成null。

32. 在使用同步機(jī)制時(shí)，應(yīng)盡量使用方法同步代替代碼塊同步**。**

33. 不要在循環(huán)中使用Try/Catch語句，應(yīng)把Try/Catch放在循環(huán)最外層

Error是獲取系統(tǒng)錯(cuò)誤的類，或者說是虛擬機(jī)錯(cuò)誤的類。不是所有的錯(cuò)誤Exception都能獲取到的，虛擬機(jī)報(bào)錯(cuò)Exception就獲取不到，必須用Error獲取。

34. 通過StringBuffer的構(gòu)造函數(shù)來設(shè)定他的初始化容量，可以明顯提升性能

StringBuffer的默認(rèn)容量為16，當(dāng)StringBuffer的容量達(dá)到最大容量時(shí)，她會(huì)將自身容量增加到當(dāng)前的2倍+2，也就是2*n+2。無論何時(shí)，只要StringBuffer到達(dá)她的最大容量，她就不得不創(chuàng)建一個(gè)新的對象數(shù)組，然后復(fù)制舊的對象數(shù)組，這會(huì)浪費(fèi)很多時(shí)間。所以給StringBuffer設(shè)置一個(gè)合理的初始化容量值，是很有必要的！

35. 合理使用java.util.Vector

Vector與StringBuffer類似，每次擴(kuò)展容量時(shí)，所有現(xiàn)有元素都要賦值到新的存儲(chǔ)空間中。Vector的默認(rèn)存儲(chǔ)能力為10個(gè)元素，擴(kuò)容加倍。vector.add(index,obj) 這個(gè)方法可以將元素obj插入到index位置，但index以及之后的元素依次都要向下移動(dòng)一個(gè)位置（將其索引加 1）。除非必要，否則對性能不利。同樣規(guī)則適用于remove(int index)方法，移除此向量中指定位置的元素。將所有后續(xù)元素左移（將其索引減 1）。返回此向量中移除的元素。所以刪除vector最后一個(gè)元素要比刪除第1個(gè)元素開銷低很多。刪除所有元素最好用removeAllElements()方法。如果要?jiǎng)h除vector里的一個(gè)元素可以使用 vector.remove(obj)；而不必自己檢索元素位置，再刪除，如int index = indexOf（obj）;vector.remove(index)；

38. 不用new關(guān)鍵字創(chuàng)建對象的實(shí)例

用new關(guān)鍵詞創(chuàng)建類的實(shí)例時(shí)，構(gòu)造函數(shù)鏈中的所有構(gòu)造函數(shù)都會(huì)被自動(dòng)調(diào)用。但如果一個(gè)對象實(shí)現(xiàn)了Cloneable接口，我們可以調(diào)用她的clone()方法。clone()方法不會(huì)調(diào)用任何類構(gòu)造函數(shù)。下面是Factory模式的一個(gè)典型實(shí)現(xiàn)：

public static Credit getNewCredit() {     return new Credit(); }

改進(jìn)后的代碼使用clone()方法：

private static Credit BaseCredit = new Credit(); public static Credit getNewCredit() {     return (Credit)BaseCredit.clone(); }

39. 不要將數(shù)組聲明為：public static final

40. HaspMap的遍歷：

Map<String, String[]> paraMap = new HashMap<String, String[]>(); for( Entry<String, String[]> entry : paraMap.entrySet() ) {     String appFieldDefId = entry.getKey();     String[] values = entry.getValue(); }

利用散列值取出相應(yīng)的Entry做比較得到結(jié)果，取得entry的值之后直接取key和value。

41. array(數(shù)組)和ArrayList的使用

array 數(shù)組效率最高，但容量固定，無法動(dòng)態(tài)改變，ArrayList容量可以動(dòng)態(tài)增長，但犧牲了效率。

42. 單線程應(yīng)盡量使用 HashMap, ArrayList,除非必要，否則不推薦使用HashTable,Vector，她們使用了同步機(jī)制，而降低了性能。

43. StringBuffer,StringBuilder的區(qū)別在于：java.lang.StringBuffer 線程安全的可變字符序列。一個(gè)類似于String的字符串緩沖區(qū)，但不能修改。StringBuilder與該類相比，通常應(yīng)該優(yōu)先使用StringBuilder類，因?yàn)樗С炙邢嗤牟僮?，但由于她不?zhí)行同步，所以速度更快。為了獲得更好的性能，在構(gòu)造StringBuffer或StringBuilder時(shí)應(yīng)盡量指定她的容量。當(dāng)然如果不超過16個(gè)字符時(shí)就不用了。相同情況下，使用StringBuilder比使用StringBuffer僅能獲得10%~15%的性能提升，但卻要冒多線程不安全的風(fēng)險(xiǎn)。綜合考慮還是建議使用StringBuffer。

44. 盡量使用基本數(shù)據(jù)類型代替對象。

45. 使用具體類比使用接口效率高，但結(jié)構(gòu)彈性降低了，但現(xiàn)代IDE都可以解決這個(gè)問題。

46. 考慮使用靜態(tài)方法，如果你沒有必要去訪問對象的外部，那么就使你的方法成為靜態(tài)方法。她會(huì)被更快地調(diào)用，因?yàn)樗恍枰粋€(gè)虛擬函數(shù)導(dǎo)向表。這同事也是一個(gè)很好的實(shí)踐，因?yàn)樗嬖V你如何區(qū)分方法的性質(zhì)，調(diào)用這個(gè)方法不會(huì)改變對象的狀態(tài)。

47. 應(yīng)盡可能避免使用內(nèi)在的GET,SET方法。

48.避免枚舉，浮點(diǎn)數(shù)的使用。

以下舉幾個(gè)實(shí)用優(yōu)化的例子：

一、避免在循環(huán)條件中使用復(fù)雜表達(dá)式

在不做編譯優(yōu)化的情況下，在循環(huán)中，循環(huán)條件會(huì)被反復(fù)計(jì)算，如果不使用復(fù)雜表達(dá)式，而使循環(huán)條件值不變的話，程序?qū)?huì)運(yùn)行的更快。例子：

import java.util.Vector; class CEL {      void method (Vector vector) {          for (int i = 0; i < vector.size (); i++)   // Violation              ; // ...      } }

更正：

class CEL_fixed {      void method (Vector vector) {          int size = vector.size ()          for (int i = 0; i < size; i++)              ; // ...      } }

二、為"Vectors" 和 "Hashtables"定義初始大小

JVM為Vector擴(kuò)充大小的時(shí)候需要重新創(chuàng)建一個(gè)更大的數(shù)組，將原原先數(shù)組中的內(nèi)容復(fù)制過來，最后，原先的數(shù)組再被回收?？梢奦ector容量的擴(kuò)大是一個(gè)頗費(fèi)時(shí)間的事。

通常，默認(rèn)的10個(gè)元素大小是不夠的。你最好能準(zhǔn)確的估計(jì)你所需要的最佳大小。例子：

import java.util.Vector;public class DIC {public void addObjects (Object[] o) {// if length > 10, Vector needs to expandfor (int i = 0; i< o.length;i++) {  v.add(o);  // capacity before it can add more elements.}}public Vector v = new Vector();  // no initialCapacity.}

更正：

自己設(shè)定初始大小。

public Vector v = new Vector(20); public Hashtable hash = new Hashtable(10);

三、在finally塊中關(guān)閉Stream

程序中使用到的資源應(yīng)當(dāng)被釋放，以避免資源泄漏。這最好在finally塊中去做。不管程序執(zhí)行的結(jié)果如何，finally塊總是會(huì)執(zhí)行的，以確保資源的正確關(guān)閉。

四、使用"System.arraycopy ()"代替通過來循環(huán)復(fù)制數(shù)組,例子：

public class IRB{void method () {int[] array1 = new int [100];for (int i = 0; i < array1.length; i++) {array1 [i] = i;}int[] array2 = new int [100];for (int i = 0; i < array2.length; i++) {array2 [i] = array1 [i]; // Violation}}}

更正：

public class IRB{void method () {int[] array1 = new int [100];for (int i = 0; i < array1.length; i++) {array1 [i] = i;}int[] array2 = new int [100];System.arraycopy(array1, 0, array2, 0, 100);}}

五、讓訪問實(shí)例內(nèi)變量的getter/setter方法變成”final”

簡單的getter/setter方法應(yīng)該被置成final，這會(huì)告訴編譯器，這個(gè)方法不會(huì)被重載，所以，可以變成”inlined”,例子：

class MAF {public void setSize (int size) {_size = size;}private int _size;}

更正：

class DAF_fixed {final public void setSize (int size) {_size = size;}private int _size;}

六、對于常量字符串，用"String" 代替 "StringBuffer"

常量字符串并不需要?jiǎng)討B(tài)改變長度。

例子：

public class USC {String method () {StringBuffer s = new StringBuffer ("Hello");String t = s + "World!";return t;}}

更正：把StringBuffer換成String，如果確定這個(gè)String不會(huì)再變的話，這將會(huì)減少運(yùn)行開銷提高性能。

七、在字符串相加的時(shí)候，使用 " " 代替 " "，如果該字符串只有一個(gè)字符的話

例子：

public class STR {public void method(String s) {String string = s + "d"  // violation.string = "abc" + "d"    // violation.}}

更正：

將一個(gè)字符的字符串替換成" "

public class STR {public void method(String s) {String string = s + "d"string = "abc" + "d" }}

以上僅是Java方面編程時(shí)的性能優(yōu)化，性能優(yōu)化大部分都是在時(shí)間、效率、代碼結(jié)構(gòu)層次等方面的權(quán)衡，各有利弊，不要把上面內(nèi)容當(dāng)成教條，或許有些對我們實(shí)際工作適用，有些不適用，還望根據(jù)實(shí)際工作場景進(jìn)行取舍吧，活學(xué)活用，變通為宜。

四、最后

我相信很多接口的效率問題不是一朝一夕形成的，在需求迭代的過程中，為了需求快速上線，采取直接累加代碼的方式去實(shí)現(xiàn)功能，這樣會(huì)造成以上這些接口性能問題。

變換思路，更高一級思考問題，站在接口設(shè)計(jì)者的角度去開發(fā)需求，會(huì)避免很多這樣的問題，也是降本增效的一種行之有效的方式。

以上，共勉！

標(biāo)簽：