技術文章 » 介面通用優化

介面通用優化

2023-11-22 18:00:46

之前工作中，遇到一個504超時問題。原因是因為介面耗時過長，超過nginx設定的10秒。然後 真槍實彈搞了一次介面效能優化，最後介面從11.3s降為170ms。本文將跟小夥伴們分享介面優化的一些通用方案。

1. 批次思想：批次運算元據庫

優化前：

//for迴圈單筆入庫
for(TransDetail detail:transDetailList){
  insert(detail);  
}

優化後：

batchInsert(transDetailList);

打個比喻：

打個比喻:假如你需要搬一萬塊磚到樓頂,你有一個電梯,電梯一次可以放適量的磚（最多放500）, 你可以選擇一次運送一塊磚,也可以一次運送500,你覺得哪種方式更方便，時間消耗更少?

2. 非同步思想：耗時操作，考慮放到非同步執行

耗時操作，考慮用非同步處理，這樣可以降低介面耗時。

假設一個轉賬介面，匹配聯行號，是同步執行的，但是它的操作耗時有點長，優化前的流程：

 

為了降低介面耗時，更快返回，你可以把匹配聯行號移到非同步處理，優化後：

 

  • 除了轉賬這個例子，日常工作中還有很多這種例子。比如：使用者註冊成功後，簡訊郵件通知，也是可以非同步處理的~
  • 至於非同步的實現方式，你可以用執行緒池，也可以用訊息佇列實現。

3. 空間換時間思想：恰當使用快取。

在適當的業務場景，恰當地使用快取，是可以大大提高介面效能的。快取其實就是一種空間換時間的思想，就是你把要查的資料，提前放好到快取裡面，需要時，直接查快取，而避免去查資料庫或者計算的過程。

這裡的快取包括：Redis快取，JVM本地快取，memcached，或者Map等等。我舉個我工作中，一次使用快取優化的設計吧，比較簡單，但是思路很有借鑑的意義。

那是一次轉賬介面的優化，老程式碼，每次轉賬，都會根據客戶賬號，查詢資料庫，計算匹配聯行號。

 

因為每次都查資料庫，都計算匹配，比較耗時，所以使用快取，優化後流程如下：

 

4. 預取思想：提前初始化到快取

預取思想很容易理解，就是提前把要計算查詢的資料，初始化到快取。如果你在未來某個時間需要用到某個經過複雜計算的資料，才實時去計算的話，可能耗時比較大。這時候，我們可以採取預取思想，提前把將來可能需要的資料計算好，放到快取中，等需要的時候，去快取取就行。這將大幅度提高介面效能。

我記得以前在第一個公司做視訊直播的時候，看到我們的直播列表就是用到這種優化方案。就是啟動個任務，提前把直播使用者、積分等相關資訊，初始化到快取。

5. 池化思想：預分配與迴圈使用

大家應該都記得，我們為什麼需要使用執行緒池？

執行緒池可以幫我們管理執行緒，避免增加建立執行緒和銷燬執行緒的資源損耗。

如果你每次需要用到執行緒，都去建立，就會有增加一定的耗時，而執行緒池可以重複利用執行緒，避免不必要的耗時。 池化技術不僅僅指執行緒池，很多場景都有池化思想的體現，它的本質就是預分配與迴圈使用。

比如TCP三次握手，大家都很熟悉吧，它為了減少效能損耗，引入了Keep-Alive長連線，避免頻繁的建立和銷燬連線。當然，類似的例子還有很多，如資料庫連線池、HttpClient連線池。

我們寫程式碼的過程中，學會池化思想，最直接相關的就是使用執行緒池而不是去new一個執行緒。

6. 事件回撥思想：拒絕阻塞等待。

如果你呼叫一個系統B的介面，但是它處理業務邏輯，耗時需要10s甚至更多。然後你是一直阻塞等待，直到系統B的下游介面返回，再繼續你的下一步操作嗎？這樣顯然不合理。

我們參考IO多路複用模型。即我們不用阻塞等待系統B的介面，而是先去做別的操作。等系統B的介面處理完，通過事件回撥通知，我們介面收到通知再進行對應的業務操作即可。

如果大家忘記了IO模型，可以複習一下我的文章：看一遍就理解：IO模型詳解

7. 遠端呼叫由序列改為並行

假設我們設計一個APP首頁的介面，它需要查使用者資訊、需要查banner資訊、需要查彈窗資訊等等。如果是序列一個一個查，比如查使用者資訊200ms，查banner資訊100ms、查彈窗資訊50ms，那一共就耗時350ms了，如果還查其他資訊，那耗時就更大了。

 

其實我們可以改為並行呼叫，即查使用者資訊、查banner資訊、查彈窗資訊，可以同時並行發起。

 

最後介面耗時將大大降低。有些小夥伴說，不知道如何使用並行優化介面?

我之前寫過一篇文章並行優化介面的文章，保姆級別的！大家可以看一下，看完會有用的：後端思維篇，手把手教你寫一個並行呼叫模板

8. 鎖粒度避免過粗

在高並行場景，為了防止超賣等情況，我們經常需要加鎖來保護共用資源。但是，如果加鎖的粒度過粗，是很影響介面效能的。

什麼是加鎖粒度呢？

其實就是就是你要鎖住的範圍是多大。比如你在家上衛生間，你只要鎖住衛生間就可以了吧，不需要將整個家都鎖起來不讓家人進門吧，衛生間就是你的加鎖粒度。

不管你是synchronized加鎖還是redis分散式鎖，只需要在共用臨界資源加鎖即可，不涉及共用資源的，就不必要加鎖。這就好像你上衛生間，不用把整個家都鎖住，鎖住衛生間門就可以了。

比如，在業務程式碼中，有一個ArrayList因為涉及到多執行緒操作，所以需要加鎖操作，假設剛好又有一段比較耗時的操作（程式碼中的slowNotShare方法）不涉及執行緒安全問題。反例加鎖，就是一鍋端，全鎖住:

//不涉及共用資源的慢方法
private void slowNotShare() {
    try {
        TimeUnit.MILLISECONDS.sleep(100);
    } catch (InterruptedException e) {
    }
}

//錯誤的加鎖方法
public int wrong() {
    long beginTime = System.currentTimeMillis();
    IntStream.rangeClosed(1, 10000).parallel().forEach(i -> {
        //加鎖粒度太粗了，slowNotShare其實不涉及共用資源
        synchronized (this) {
            slowNotShare();
            data.add(i);
        }
    });
    log.info("cosume time:{}", System.currentTimeMillis() - beginTime);
    return data.size();
}
複製程式碼

正例：

public int right() {
    long beginTime = System.currentTimeMillis();
    IntStream.rangeClosed(1, 10000).parallel().forEach(i -> {
        slowNotShare();//可以不加鎖
        //只對List這部分加鎖
        synchronized (data) {
            data.add(i);
        }
    });
    log.info("cosume time:{}", System.currentTimeMillis() - beginTime);
    return data.size();
}
複製程式碼

9. 切換儲存方式：檔案中轉暫存資料

如果資料太大，落地資料庫實在是慢的話，就可以考慮先用檔案的方式暫存。先儲存檔案，再非同步下載檔案，慢慢儲存到資料庫。

這裡可能會有點抽象，給大家分享一個，我之前的一個真實的優化案例吧。

之前開發了一個轉賬介面。如果是並行開啟，10個並行度，每個批次1000筆轉賬明細資料，資料庫插入會特別耗時，大概6秒左右；這個跟我們公司的資料庫同步機制有關，並行情況下，因為優先保證同步，所以並行的插入變成序列啦，就很耗時。

優化前，1000筆明細轉賬資料，先落地DB資料庫，返回處理中給使用者，再非同步轉賬。如圖：

 

記得當時壓測的時候，高並行情況，這1000筆明細入庫，耗時都比較大。所以我轉換了一下思路，把批次的明細轉賬記錄儲存的檔案伺服器，然後記錄一筆轉賬總記錄到資料庫即可。接著非同步再把明細下載下來，進行轉賬和明細入庫。最後優化後，效能提升了十幾倍。

優化後，流程圖如下：

 

如果你的介面耗時瓶頸就在資料庫插入操作這裡，用來批次操作等，還是效果還不理想，就可以考慮用檔案或者MQ等暫存。有時候批次資料放到檔案，會比插入資料庫效率更高。

10. 索引

提到介面優化，很多小夥伴都會想到新增索引。沒錯，新增索引是成本最小的優化，而且一般優化效果都很不錯。

索引優化這塊的話，一般從這幾個維度去思考：

  • 你的SQL加索引了沒？
  • 你的索引是否真的生效？
  • 你的索引建立是否合理？

10.1 SQL沒加索引

我們開發的時候，容易疏忽而忘記給SQL新增索引。所以我們在寫完SQL的時候，就順手檢視一下 explain執行計劃。

explain select * from user_info where userId like '%123';
複製程式碼

你也可以通過命令show create table ，整張表的索引情況。

show create table user_info;
複製程式碼

如果某個表忘記新增某個索引，可以通過alter table add index命令新增索引

alter table user_info add index idx_name (name);
複製程式碼

一般就是：SQL的where條件的欄位，或者是order by 、group by後面的欄位需需要新增索引。

10.2 索引不生效

有時候，即使你新增了索引，但是索引會失效的。田螺哥整理了索引失效的常見原因：

 

10.3 索引設計不合理

我們的索引不是越多越好，需要合理設計。比如：

  • 刪除冗餘和重複索引。
  • 索引一般不能超過5個
  • 索引不適合建在有大量重複資料的欄位上、如性別欄位
  • 適當使用覆蓋索引
  • 如果需要使用force index強制走某個索引，那就需要思考你的索引設計是否真的合理了

11. 優化SQL

處了索引優化，其實SQL還有很多其他有優化的空間。比如這些：

 

更詳細的內容，大家可以看我之前的這兩篇文章哈：

  • 盤點MySQL慢查詢的12個原因
  • 後端程式設計師必備：書寫高質量SQL的30條建議

12.避免大事務問題

為了保證資料庫資料的一致性，在涉及到多個資料庫修改操作時，我們經常需要用到事務。而使用spring宣告式事務，又非常簡單，只需要用一個註解就行@Transactional，如下面的例子：

@Transactional
public int createUser(User user){
    //儲存使用者資訊
    userDao.save(user);
    passCertDao.updateFlag(user.getPassId());
    return user.getUserId();
}
複製程式碼

這塊程式碼主要邏輯就是建立個使用者，然後更新一個通行證pass的標記。如果現在新增一個需求，建立完使用者，呼叫遠端介面傳送一個email訊息通知，很多小夥伴會這麼寫：

@Transactional
public int createUser(User user){
    //儲存使用者資訊
    userDao.save(user);
    passCertDao.updateFlag(user.getPassId());
    sendEmailRpc(user.getEmail());
    return user.getUserId();
}
複製程式碼

這樣實現可能會有坑，事務中巢狀RPC遠端呼叫，即事務巢狀了一些非DB操作。如果這些非DB操作耗時比較大的話，可能會出現大事務問題。

所謂大事務問題就是，就是執行時間長的事務。由於事務一致不提交，就會導致資料庫連線被佔用，即並行場景下，資料庫連線池被佔滿，影響到別的請求存取資料庫，影響別的介面效能。

大事務引發的問題主要有：介面超時、死鎖、主從延遲等等。因此，為了優化介面，我們要規避大事務問題。我們可以通過這些方案來規避大事務：

  • RPC遠端呼叫不要放到事務裡面
  • 一些查詢相關的操作，儘量放到事務之外
  • 事務中避免處理太多資料

13. 深分頁問題

在以前公司分析過幾個介面耗時長的問題，最終結論都是因為深分頁問題。

深分頁問題，為什麼會慢？我們看下這個SQL

select id,name,balance from account where create_time> '2020-09-19' limit 100000,10;
複製程式碼

limit 100000,10意味著會掃描100010行，丟棄掉前100000行，最後返回10行。即使create_time，也會回表很多次。

我們可以通過標籤記錄法和延遲關聯法來優化深分頁問題。

13.1 標籤記錄法

就是標記一下上次查詢到哪一條了，下次再來查的時候，從該條開始往下掃描。就好像看書一樣，上次看到哪裡了，你就摺疊一下或者夾個書籤，下次來看的時候，直接就翻到啦。

假設上一次記錄到100000，則SQL可以修改為：

select  id,name,balance FROM account where id > 100000 limit 10;
複製程式碼

這樣的話，後面無論翻多少頁，效能都會不錯的，因為命中了id主鍵索引。但是這種方式有侷限性：需要一種類似連續自增的欄位。

13.2 延遲關聯法

延遲關聯法，就是把條件轉移到主鍵索引樹，然後減少回表。優化後的SQL如下：

select  acct1.id,acct1.name,acct1.balance FROM account acct1 INNER JOIN (SELECT a.id FROM account a WHERE a.create_time > '2020-09-19' limit 100000, 10) AS acct2 on acct1.id= acct2.id;
複製程式碼

優化思路就是，先通過idx_create_time二級索引樹查詢到滿足條件的主鍵ID，再與原表通過主鍵ID內連線，這樣後面直接走了主鍵索引了，同時也減少了回表。

14. 優化程式結構

優化程式邏輯、程式程式碼，是可以節省耗時的。比如，你的程式建立多不必要的物件、或者程式邏輯混亂，多次重複查資料庫、又或者你的實現邏輯演演算法不是最高效的，等等。

我舉個簡單的例子：複雜的邏輯條件，有時候調整一下順序，就能讓你的程式更加高效。

假設業務需求是這樣：如果使用者是會員，第一次登陸時，需要發一條感謝簡訊。如果沒有經過思考，程式碼直接這樣寫了

if(isUserVip && isFirstLogin){
    sendSmsMsg();
}
複製程式碼

假設有5個請求過來，isUserVip判斷通過的有3個請求，isFirstLogin通過的只有1個請求。 那麼以上程式碼，isUserVip執行的次數為5次，isFirstLogin執行的次數也是3次，如下：

 

如果調整一下isUserVip和isFirstLogin的順序：

if(isFirstLogin && isUserVip ){
    sendMsg();
}
複製程式碼

isFirstLogin執行的次數是5次，isUserVip執行的次數是1次：

 

醬紫程式是不是變得更高效了呢？

15. 壓縮傳輸內容

壓縮傳輸內容，傳輸報文變得更小，因此傳輸會更快啦。10M頻寬，傳輸10k的報文，一般比傳輸1M的會快呀。

打個比喻，一匹千里馬，它馱著100斤的貨跑得快，還是馱著10斤的貨物跑得快呢？

再舉個視訊網站的例子：

如果不對視訊做任何壓縮編碼，因為頻寬又是有限的。巨大的資料量在網路傳輸的耗時會比編碼壓縮後，慢好多倍。

16. 海量資料處理，考慮NoSQL

之前看過幾個慢SQL，都是跟深分頁問題有關的。發現用來標籤記錄法和延遲關聯法，效果不是很明顯，原因是要統計和模糊搜尋，並且統計的資料是真的大。最後跟組長對齊方案，就把資料同步到Elasticsearch，然後這些模糊搜尋需求，都走Elasticsearch去查詢了。

我想表達的就是，如果資料量過大，一定要用關係型資料庫儲存的話，就可以分庫分表。但是有時候，我們也可以使用NoSQL，如Elasticsearch、Hbase等。

17. 執行緒池設計要合理

我們使用執行緒池，就是讓任務並行處理，更高效地完成任務。但是有時候，如果執行緒池設計不合理，介面執行效率則不太理想。

一般我們需要關注執行緒池的這幾個引數：核心執行緒、最大執行緒數量、阻塞佇列。

  • 如果核心執行緒過小，則達不到很好的並行效果。
  • 如果阻塞佇列不合理，不僅僅是阻塞的問題，甚至可能會OOM
  • 如果執行緒池不區分業務隔離，有可能核心業務被邊緣業務拖垮。

大家可以看下我之前兩篇有關於執行緒池的文章：

  • 細數執行緒池的10個坑
  • 面試必備：Java執行緒池解析

18.機器問題 （fullGC、執行緒打滿、太多IO資源沒關閉等等）。

有時候，我們的介面慢，就是機器處理問題。主要有fullGC、執行緒打滿、太多IO資源沒關閉等等。

  • 之前排查過一個fullGC問題： 運營小姐姐匯出60多萬的excel的時候，說卡死了，接著我們就收到監控告警。後面排查得出，我們老程式碼是Apache POI生成的excel，匯出excel資料量很大時，當時JVM記憶體吃緊會直接Full GC了。
  • 如果執行緒打滿了，也會導致介面都在等待了。所以。如果是高並行場景，我們需要接入限流，把多餘的請求拒絕掉。
  • 如果IO資源沒關閉，也會導致耗時增加。這個大家可以看下，平時你的電腦一直開啟很多很多檔案，是不是會覺得很卡。

（三）Java效能優化的55個細節

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

使用單例可以減輕載入的負擔，縮短載入的時間，提高載入的效率，但並不是所有地方都適用於單例，簡單來說，單例主要適用於以下三個方面：

第一，控制資源的使用，通過執行緒同步來控制資源的並行存取；

第二，控制範例的產生，以達到節約資源的目的；

第三，控制資料共用，在不建立直接關聯的條件下，讓多個不相關的程序或執行緒之間實現通訊。

2. 儘量避免隨意使用靜態變數

要知道，當某個物件被定義為static變數所參照，那麼GC通常是不會回收這個物件所佔有的記憶體，如

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

此時靜態變數b的生命週期與A類同步，如果A類不會解除安裝，那麼b物件會常駐記憶體，直到程式終止。

3. 儘量避免過多過常的建立Java物件

儘量避免在經常呼叫的方法，迴圈中new物件，由於系統不僅要花費時間來建立物件，而且還要花時間對這些物件進行垃圾回收和處理，在我們可以控制的範圍內，最大限度的重用物件，最好能用基本的資料型別或陣列來替代物件。

4. 儘量使用final修飾符

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

如：讓存取範例內變數的getter/setter方法變成」final：

簡單的getter/setter方法應該被置成final，這會告訴編譯器，這個方法不會被過載，所以，可以變成」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. 儘量使用區域性變數

呼叫方法時傳遞的引數以及在呼叫中建立的臨時變數都儲存在棧（Stack）中，速度較快。其他變數，如靜態變數，範例變數等，都在堆（Heap）中建立，速度較慢。

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

雖然包裝型別和基本型別在使用過程中是可以相互轉換，但它們兩者所產生的記憶體區域是完全不同的，基本型別資料產生和處理都在棧中處理，包裝型別是物件，是在堆中產生範例。在集合類物件，有物件方面需要的處理適用包裝型別，其他的處理提倡使用基本型別。

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

都知道，實現同步是要很大的系統開銷作為代價的，甚至可能造成死鎖，所以儘量避免無謂的同步控制。synchronize方法被呼叫時，直接會把當前物件鎖 了，在方法執行完之前其他執行緒無法呼叫當前物件的其他方法。所以synchronize的方法儘量小，並且應儘量使用方法同步代替程式碼塊同步。

9. 儘量不要使用finalize方法

實際上，將資源清理放在finalize方法中完成是非常不好的選擇，由於GC的工作量很大，尤其是回收Young代記憶體時，大都會引起應用程式暫停，所以再選擇使用finalize方法進行資源清理，會導致GC負擔更大，程式執行效率更差。

10. 儘量使用基本資料型別代替物件

String str = "hello";

上面這種方式會建立一個「hello」字串，而且JVM的字元快取池還會快取這個字串；

String str = new String("hello");

此時程式除建立字串外，str所參照的String物件底層還包含一個char[]陣列，這個char[]陣列依次存放了h,e,l,l,o

11. 多執行緒在未發生執行緒安全前提下應儘量使用HashMap、ArrayList

HashTable、Vector等使用了同步機制，降低了效能。

12. 儘量合理的建立HashMap

當你要建立一個比較大的hashMap時，充分利用這個建構函式

public HashMap(int initialCapacity, float loadFactor);

避免HashMap多次進行了hash重構,擴容是一件很耗費效能的事，在預設中initialCapacity只有16，而loadFactor是 0.75，需要多大的容量，你最好能準確的估計你所需要的最佳大小，同樣的Hashtable，Vectors也是一樣的道理。

13. 儘量減少對變數的重複計算

如：

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

應該改為

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

並且在迴圈中應該避免使用複雜的表示式，在迴圈中，迴圈條件會被反覆計算，如果不使用複雜表示式，而使迴圈條件值不變的話，程式將會執行的更快。

14. 儘量避免不必要的建立

如：

A a = new A();

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

應該改為

if(i==1){

  A a = new A();

  list.add(a);

}

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

程式中使用到的資源應當被釋放，以避免資源洩漏。這最好在finally塊中去做。不管程式執行的結果如何，finally塊總是會執行的，以確保資源的正確關閉。

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

"/"是一個代價很高的操作，使用移位的操作將會更快和更有效

如

int num = a / 4;

int num = a / 8;

應該改為

int num = a >> 2;

int num = a >> 3;

但注意的是使用移位應新增註釋，因為移位元運算不直觀，比較難理解

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

同樣的，對於'*'操作，使用移位的操作將會更快和更有效

如

int num = a * 4;

int num = a * 8;

應該改為

int num = a << 2;

int num = a << 3;

18. 儘量確定StringBuffer的容量

StringBuffer 的構造器會建立一個預設大小（通常是16）的字元陣列。在使用中，如果超出這個大小，就會重新分配記憶體，建立一個更大的陣列，並將原先的陣列複製過來，再 丟棄舊的陣列。在大多數情況下，你可以在建立 StringBuffer的時候指定大小，這樣就避免了在容量不夠的時候自動增長，以提高效能。

如：

StringBuffer buffer = new StringBuffer(1000);

19. 儘量早釋放無用物件的參照

大部分時，方法區域性參照變數所參照的物件 會隨著方法結束而變成垃圾，因此，大部分時候程式無需將區域性，參照變數顯式設為null。

例如：

Java程式碼

Public void test(){ 

  Object obj = new Object(); 

  …… 

  Obj=null; 

}

上面這個就沒必要了，隨著方法test()的執行完成，程式中obj參照變數的作用域就結束了。但是如果是改成下面：

Java程式碼

Public void test(){ 

  Object obj = new Object(); 

  …… 

  Obj=null; 

  //執行耗時，耗記憶體操作；或呼叫耗時，耗記憶體的方法

  …… 

}

這時候就有必要將obj賦值為null，可以儘早的釋放對Object物件的參照。

20. 儘量避免使用二維陣列

二維資料佔用的記憶體空間比一維陣列多得多，大概10倍以上。

21. 儘量避免使用split

除非是必須的，否則應該避免使用split，split由於支援正規表示式，所以效率比較低，如果是頻繁的幾十，幾百萬的呼叫將會耗費大量資源，如果確實需要頻繁的呼叫split，可以考慮使用apache的StringUtils.split(string,char)，頻繁split的可以快取結果。

22. ArrayList & LinkedList

一個是線性表，一個是連結串列，一句話，隨機查詢儘量使用ArrayList，ArrayList優於LinkedList，LinkedList還要移動指標，新增刪除的操作LinkedList優於ArrayList，ArrayList還要行動資料，不過這是理論性分析，事實未必如此，重要的是理解好2者得資料結構，對症下藥。

23. 儘量使用System.arraycopy ()代替通過來回圈複製陣列

System.arraycopy() 要比通過迴圈來複制陣列快的多

24. 儘量快取經常使用的物件

儘可能將經常使用的物件進行快取，可以使用陣列，或HashMap的容器來進行快取，但這種方式可能導致系統佔用過多的快取，效能下降，推薦可以使用一些第三方的開源工具，如EhCache，Oscache進行快取，他們基本都實現了FIFO/FLU等快取演演算法。

25. 儘量避免非常大的記憶體分配

有時候問題不是由當時的堆狀態造成的，而是因為分配失敗造成的。分配的記憶體塊都必須是連續的，而隨著堆越來越滿，找到較大的連續塊越來越困難。

26. 慎用異常

當建立一個異常時，需要收集一個棧跟蹤(stack track)，這個棧跟蹤用於描述異常是在何處建立的。構建這些棧跟蹤時需要為執行時棧做一份快照，正是這一部分開銷很大。當需要建立一個 Exception 時，JVM 不得不說：先別動，我想就您現在的樣子存一份快照，所以暫時停止入棧和出棧操作。棧跟蹤不只包含執行時棧中的一兩個元素，而是包含這個棧中的每一個元素。

如果您建立一個 Exception ，就得付出代價。好在捕獲異常開銷不大，因此可以使用 try-catch 將核心內容包起來。從技術上講，您甚至可以隨意地丟擲異常，而不用花費很大的代價。招致效能損失的並不是 throw 操作——儘管在沒有預先建立異常的情況下就丟擲異常是有點不尋常。真正要花代價的是建立異常。幸運的是，好的程式設計習慣已教會我們，不應該不管三七二十一就丟擲異常。異常是為異常的情況而設計的，使用時也應該牢記這一原則。

27. 儘量重用物件

特別是String物件的使用中，出現字串連線情況時應使用StringBuffer代替，由於系統不僅要花時間生成物件，以後可能還需要花時間對這些物件進行垃圾回收和處理。因此生成過多的物件將會給程式的效能帶來很大的影響。

28. 不要重複初始化變數

預設情況下，呼叫類別建構函式時，java會把變數初始化成確定的值，所有的物件被設定成null，整數變數設定成0，float和double變數設定成0.0，邏輯值設定成false。當一個類從另一個類派生時，這一點尤其應該注意，因為用new關鍵字建立一個物件時，建構函式鏈中的所有建構函式都會被自動呼叫。這裡有個注意，給成員變數設定初始值但需要呼叫其他方法的時候，最好放在一個方法比如initXXX()中，因為直接呼叫某方法賦值可能會因為類尚未初始化而拋空指標異常，如：public int state = this.getState();

29. 在java+Oracle的應用系統開發中，java中內嵌的SQL語言應儘量使用大寫形式，以減少Oracle解析器的解析負擔。

30. 在java程式設計過程中，進行資料庫連線，I/O流操作，在使用完畢後，及時關閉以釋放資源。因為對這些大物件的操作會造成系統大的開銷。

31. 過分的建立物件會消耗系統的大量記憶體，嚴重時，會導致記憶體漏失，因此，保證過期的物件的及時回收具有重要意義。JVM的GC並非十分智慧，因此建議在物件使用完畢後，手動設定成null。

32. 在使用同步機制時，應儘量使用方法同步代替程式碼塊同步**。**

33. 不要在迴圈中使用Try/Catch語句，應把Try/Catch放在迴圈最外層

Error是獲取系統錯誤的類，或者說是虛擬機器器錯誤的類。不是所有的錯誤Exception都能獲取到的，虛擬機器器報錯Exception就獲取不到，必須用Error獲取。

34. 通過StringBuffer的建構函式來設定他的初始化容量，可以明顯提升效能

StringBuffer的預設容量為16，當StringBuffer的容量達到最大容量時，她會將自身容量增加到當前的2倍+2，也就是2*n+2。無論何時，只要StringBuffer到達她的最大容量，她就不得不建立一個新的物件陣列，然後複製舊的物件陣列，這會浪費很多時間。所以給StringBuffer設定一個合理的初始化容量值，是很有必要的！

35. 合理使用java.util.Vector

Vector與StringBuffer類似，每次擴充套件容量時，所有現有元素都要賦值到新的儲存空間中。Vector的預設儲存能力為10個元素，擴容加倍。vector.add(index,obj) 這個方法可以將元素obj插入到index位置，但index以及之後的元素依次都要向下移動一個位置（將其索引加 1）。除非必要，否則對效能不利。同樣規則適用於remove(int index)方法，移除此向量中指定位置的元素。將所有後續元素左移（將其索引減 1）。返回此向量中移除的元素。所以刪除vector最後一個元素要比刪除第1個元素開銷低很多。刪除所有元素最好用removeAllElements()方法。如果要刪除vector裡的一個元素可以使用 vector.remove(obj)；而不必自己檢索元素位置，再刪除，如int index = indexOf（obj）;vector.remove(index)；

38. 不用new關鍵字建立物件的範例

用new關鍵詞建立類的範例時，建構函式鏈中的所有建構函式都會被自動呼叫。但如果一個物件實現了Cloneable介面，我們可以呼叫她的clone()方法。clone()方法不會呼叫任何類建構函式。下面是Factory模式的一個典型實現：

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

改進後的程式碼使用clone()方法：

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

39. 不要將陣列宣告為：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(); 
}

利用雜湊值取出相應的Entry做比較得到結果，取得entry的值之後直接取key和value。

41. array(陣列)和ArrayList的使用

array 陣列效率最高，但容量固定，無法動態改變，ArrayList容量可以動態增長，但犧牲了效率。

42. 單執行緒應儘量使用 HashMap, ArrayList,除非必要，否則不推薦使用HashTable,Vector，她們使用了同步機制，而降低了效能。

43. StringBuffer,StringBuilder的區別在於：java.lang.StringBuffer 執行緒安全的可變字元序列。一個類似於String的字串緩衝區，但不能修改。StringBuilder與該類相比，通常應該優先使用StringBuilder類，因為她支援所有相同的操作，但由於她不執行同步，所以速度更快。為了獲得更好的效能，在構造StringBuffer或StringBuilder時應儘量指定她的容量。當然如果不超過16個字元時就不用了。相同情況下，使用StringBuilder比使用StringBuffer僅能獲得10%~15%的效能提升，但卻要冒多執行緒不安全的風險。綜合考慮還是建議使用StringBuffer。

44. 儘量使用基本資料型別代替物件。

45. 使用具體類比使用介面效率高，但結構彈性降低了，但現代IDE都可以解決這個問題。

46. 考慮使用靜態方法，如果你沒有必要去存取物件的外部，那麼就使你的方法成為靜態方法。她會被更快地呼叫，因為她不需要一個虛擬函數導向表。這同事也是一個很好的實踐，因為她告訴你如何區分方法的性質，呼叫這個方法不會改變物件的狀態。

47. 應儘可能避免使用內在的GET,SET方法。

48.避免列舉，浮點數的使用。

以下舉幾個實用優化的例子：

一、避免在迴圈條件中使用複雜表示式

在不做編譯優化的情況下，在迴圈中，迴圈條件會被反覆計算，如果不使用複雜表示式，而使迴圈條件值不變的話，程式將會執行的更快。例子：

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擴充大小的時候需要重新建立一個更大的陣列，將原原先陣列中的內容複製過來，最後，原先的陣列再被回收。可見Vector容量的擴大是一個頗費時間的事。

通常，預設的10個元素大小是不夠的。你最好能準確的估計你所需要的最佳大小。例子：

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

更正：

自己設定初始大小。

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

三、在finally塊中關閉Stream

程式中使用到的資源應當被釋放，以避免資源洩漏。這最好在finally塊中去做。不管程式執行的結果如何，finally塊總是會執行的，以確保資源的正確關閉。

四、使用'System.arraycopy ()'代替通過來回圈複製陣列,例子：

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);
}
}

五、讓存取範例內變數的getter/setter方法變成」final」

簡單的getter/setter方法應該被置成final，這會告訴編譯器，這個方法不會被過載，所以，可以變成」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'

常數字串並不需要動態改變長度。

例子：

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

更正：把StringBuffer換成String，如果確定這個String不會再變的話，這將會減少執行開銷提高效能。

七、在字串相加的時候，使用 ' ' 代替 " "，如果該字串只有一個字元的話

例子：

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

更正：

將一個字元的字串替換成' '

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

以上僅是Java方面程式設計時的效能優化，效能優化大部分都是在時間、效率、程式碼結構層次等方面的權衡，各有利弊，不要把上面內容當成教條，或許有些對我們實際工作適用，有些不適用，還望根據實際工作場景進行取捨吧，活學活用，變通為宜。

四、最後

我相信很多介面的效率問題不是一朝一夕形成的，在需求迭代的過程中，為了需求快速上線，採取直接累加程式碼的方式去實現功能，這樣會造成以上這些介面效能問題。

變換思路，更高一級思考問題，站在介面設計者的角度去開發需求，會避免很多這樣的問題，也是降本增效的一種行之有效的方式。

以上，共勉！