天天說要做性能優(yōu)化，到底在優(yōu)化什么？
面試過程中經(jīng)常被問到：
你做過性能優(yōu)化嗎? 優(yōu)化了哪些方面？ 怎么做優(yōu)化的？ 優(yōu)化的效果如何？
連環(huán)炮問下來，對于有做過優(yōu)化的老司機來說，肯定能抗住。對于沒有真正做過優(yōu)化的小白來說，肯定扛不住這一系列的追問，最后只能以面試失敗而告終。
那么性能優(yōu)化到底在優(yōu)化什么呢？我們來盤點下一些常用的優(yōu)化手段。
SQL 優(yōu)化
當(dāng)你開發(fā)的接口響應(yīng)時間超過了 200ms 的時候就得優(yōu)化了，當(dāng)然 200ms 不是絕對值，具體還是看應(yīng)用場景。以 App 舉例，進一個頁面調(diào)用 5 個接口（題外話：也可以做聚合），那么總共就是 1s 的時間，對用戶來說體驗還算可以，當(dāng)然是越快響應(yīng)越好。
接口耗時 200ms，其中占大頭的還是對數(shù)據(jù)庫的操作，一個接口中會有 N 次數(shù)據(jù)庫操作。所以優(yōu)化 SQL 的速度優(yōu)先級是最高的，大量的慢 SQL 會拖垮整個系統(tǒng)。
關(guān)于 SQL 的優(yōu)化不是本文的重點，大部分慢 SQL 還是跟各位平時開發(fā)時的習(xí)慣有關(guān)系。大部分在寫 SQL 的時候不太會去考慮性能，只要寫出來就可以了，join 隨手就來，也不梳理查詢字段，不加索引，剛開始上線沒問題，等到并發(fā)量，數(shù)據(jù)量起來的時候就涼涼了。
關(guān)于數(shù)據(jù)庫的使用規(guī)范大家可以參考下這篇文章：老大讓我整理下公司內(nèi)部mysql使用規(guī)范，分享給大家
當(dāng)數(shù)據(jù)量大了后肯定要做讀寫分離和分庫分表的，這也是優(yōu)化的必經(jīng)之路。
減少重復(fù)調(diào)用
性能不好的另一個致命問題就是重復(fù)調(diào)用，相同的邏輯在不同的方法中重復(fù)對數(shù)據(jù)庫查詢，重復(fù)調(diào)用 RPC 服務(wù)等。
比如下面的代碼：
skuDao.querySkus(productId).stream().map(sku -> {
skuDao.getById(sku.getId());
})
明明數(shù)據(jù)已經(jīng)查詢出來了，又根據(jù) ID 重新去查詢了一次，數(shù)量越多，浪費的時間越多。這里只是舉例，我相信在真實的項目中大量存在重復(fù)查詢的情況，之前我還寫過一篇文章，講解如何解決這種重復(fù)查詢問題，感興趣的可以查看這篇文章：簡直騷操作，ThreadLocal還能當(dāng)緩存用
按需查詢
很多業(yè)務(wù)邏輯不復(fù)雜的功能，卻響應(yīng)很慢。往往都是寫代碼的時候沒有思考，隨便就調(diào)用一些已經(jīng)存在的方法，導(dǎo)致整體響應(yīng)變慢，總結(jié)起來就是：性能問題大部分都是代碼寫出來的。
說個場景，大家肯定都見到過。參數(shù)是一個商品 ID, 功能是上架商品，需要進行狀態(tài)的判斷，符合條件才能上架。這個場景下只需要獲取商品的狀態(tài)進行判斷即可，有的時候你看到的代碼往往都是下面的方式：
GoodsDetail goods = goodsService.detail(id);
if (goods.getStatus() == GoodsStatusEnum.XXXX) {
}
detail 中有大量的邏輯，除了基本的商品信息，還有很多其他的內(nèi)容，這就是慢的原因。
并行調(diào)用
針對一個接口，如果設(shè)計到多個內(nèi)部 RPC 服務(wù)或者多個外部接口，在接口之間沒有關(guān)聯(lián)關(guān)系的情況下，我們可以采用并行調(diào)用的方式來提高性能。
CompletableFuture 就非常適合并行調(diào)用的場景，關(guān)于 CompletableFuture 的使用本文不做詳細(xì)說明，做 Java 的都要會用。
除了 CompletableFuture 之外，對于集合類的處理，可以用 parallelStream 來實現(xiàn)并行調(diào)用。
在微服務(wù)中有一層專門用于聚合 API, 聚合層就非常適合并行調(diào)用，一個功能或者一個頁面展示會涉及到多個接口，通過聚合層在后端進行接口的聚合和數(shù)據(jù)的裁剪，一起響應(yīng)給前端。
上緩存
緩存也是優(yōu)化中最常用的，效果提升最明顯的，成本也不大。對于緩存，也不要濫用，不是所有場景都可以靠堆緩存來提高性能的。
首先對于實時性要求不高的業(yè)務(wù)場景可以優(yōu)先使用緩存，也不用太考慮更新的問題，自然過期就行。
實時性要求高的業(yè)務(wù)場景，用緩存一定要有完整的緩存更新機制，否則很容易造成業(yè)務(wù)數(shù)據(jù)和緩存數(shù)據(jù)不一致的情況。
建議的做法是訂閱 binlog 來統(tǒng)一更新緩存，不要在代碼中去更新或者失效緩存，簡單的場景還好，入口就那幾個，問題不大。有些數(shù)據(jù)在多個場景下使用，需要更新的入口太多了，
異步處理
有些邏輯，不需要實時反饋給用戶那就可以采用異步的方式在后臺進行處理。
異步處理的方式最常見的就是將任務(wù)加到線程池中進行處理，線程池需要考慮容量以及對一些指標(biāo)的監(jiān)控，相關(guān)的文章可以查看我的這篇：一時技癢，擼了個動態(tài)線程池，源碼放Github了
除了一些指標(biāo)的監(jiān)控，線程池的使用另一個需要關(guān)注的問題就是任務(wù)的持久化。如果你的數(shù)據(jù)本來就是存儲好了的，然后讀取出來通過線程池去執(zhí)行是沒問題的。如果是沒有持久化直接丟入線程池中進行執(zhí)行，就有可能出現(xiàn)丟失的情況，比如服務(wù)重啟之類的場景。
關(guān)于持久化，無論是線程池還是 EventBus 這種，都會遇到，所以針對異步的場景我建議大家使用消息隊列比較好。
消息隊列可以存儲任務(wù)信息，保證不會丟失。單獨消費隊列的消息進行邏輯處理，如果想提高消費速度，也可以在隊列的消費方使用線程池進行多線程消費，多線程消費也要避免消息丟失的情況，可以查看我的這篇文章：噓！異步事件這樣用真的好么？
JVM 參數(shù)調(diào)整
JVM 參數(shù)的調(diào)整，一般情況下我們都不用怎么去調(diào)整。偶爾有些代碼寫的不好，導(dǎo)致內(nèi)存溢出了，這個時候會去做一些調(diào)整和優(yōu)化代碼。
參數(shù)調(diào)整主要是去降低 GC 的導(dǎo)致的停頓問題，如果你的程序一直在 GC, 一直在停頓，你的接口自然就慢了。
只要沒有頻繁的 Full GC，在優(yōu)化這塊 JVM 的參數(shù)調(diào)整可以最后再做，優(yōu)先以 SQL 優(yōu)化這些為主。
加機器
加機器是最后的終極大招了，并發(fā)量上去的時候，你在怎么優(yōu)化單機器和單數(shù)據(jù)庫抗并發(fā)能力也是有限的，這個時候只能水平擴展了。
如果是創(chuàng)業(yè)初期，并且在快速發(fā)展，加機器是最直接的優(yōu)化方式了，雖然說成本上去了，但是開發(fā)資源也是成本，節(jié)約下來可以實現(xiàn)更多的業(yè)務(wù)需求。等到中期穩(wěn)定了再考慮架構(gòu)，性能方面整體的優(yōu)化和重構(gòu)。
就像玩游戲一樣，有裝備的玩家才能所向睥睨啊，對于后端應(yīng)用來說也是一樣，高配的機器，高配的數(shù)據(jù)庫配置，高配的緩存等。
