我們以前看到的很多架構(gòu)變遷或者演進方面的文章大多都是針對架構(gòu)方面的介紹，很少有針對代碼級別的性能優(yōu)化介紹，這就好比蓋樓一樣，樓房的基礎(chǔ)架子搭的很好，但是蓋房的工人不夠?qū)I(yè)，有很多需要注意的地方忽略了，那么在往里面填磚加瓦的時候出了問題，后果就是房子經(jīng)常漏雨，墻上有裂縫等各種問題出現(xiàn)，雖然不至于樓房塌陷，但樓房也已經(jīng)變成了危樓。那么今天我們就將針對一些代碼細節(jié)方面的東西進行介紹，歡迎大家吐槽以及提建議。

服務(wù)器環(huán)境

• 服務(wù)器配置：4核CPU，8G內(nèi)存，共4臺

• MQ：RabbitMQ

• 數(shù)據(jù)庫：DB2

• SOA框架：公司內(nèi)部封裝的Dubbo

• 緩存框架：Redis、Memcached

• 統(tǒng)一配置管理系統(tǒng)：公司內(nèi)部開發(fā)的系統(tǒng)

問題描述

單臺40TPS，加到4臺服務(wù)器能到60TPS，擴展性幾乎沒有。

在實際生產(chǎn)環(huán)境中，經(jīng)常出現(xiàn)數(shù)據(jù)庫死鎖導致整個服務(wù)中斷不可用。

數(shù)據(jù)庫事務(wù)亂用，導致事務(wù)占用時間太長。

在實際生產(chǎn)環(huán)境中，服務(wù)器經(jīng)常出現(xiàn)內(nèi)存溢出和CPU時間被占滿。

程序開發(fā)的過程中，考慮不全面，容錯很差，經(jīng)常因為一個小bug而導致服務(wù)不可用。

程序中沒有打印關(guān)鍵日志，或者打印了日志，信息卻是無用信息沒有任何參考價值。

配置信息和變動不大的信息依然會從數(shù)據(jù)庫中頻繁讀取，導致數(shù)據(jù)庫IO很大。

項目拆分不徹底，一個Tomcat中會布署多個項目WAR包。

因為基礎(chǔ)平臺的bug，或者功能缺陷導致程序可用性降低。

程序接口中沒有限流策略，導致很多VIP商戶直接拿我們的生產(chǎn)環(huán)境進行壓測，直接影響真正的服務(wù)可用性。

沒有故障降級策略，項目出了問題后解決的時間較長，或者直接粗暴的回滾項目，但是不一定能解決問題。

沒有合適的監(jiān)控系統(tǒng)，不能準實時或者提前發(fā)現(xiàn)項目瓶頸。

優(yōu)化解決方案

1、數(shù)據(jù)庫死鎖優(yōu)化解決

我們從第二條開始分析，先看一個基本例子展示數(shù)據(jù)庫死鎖的發(fā)生：

注：在上述事例中，會話B會拋出死鎖異常，死鎖的原因就是A和B二個會話互相等待。

分析：出現(xiàn)這種問題就是我們在項目中混雜了大量的事務(wù)+for update語句，針對數(shù)據(jù)庫鎖來說有下面三種基本鎖：

• Record Lock：單個行記錄上的鎖

• Gap Lock：間隙鎖，鎖定一個范圍，但不包含記錄本身

• Next-Key Lock：Gap Lock + Record Lock，鎖定一個范圍，并且鎖定記錄本身

當for update語句和gap lock和next-key lock鎖相混合使用，又沒有注意用法的時候，就非常容易出現(xiàn)死鎖的情況。

那我們用大量的鎖的目的是什么，經(jīng)過業(yè)務(wù)分析發(fā)現(xiàn)，其實就是為了防重，同一時刻有可能會有多筆支付單發(fā)到相應(yīng)系統(tǒng)中，而防重措施是通過在某條記錄上加鎖的方式來進行。

針對以上問題完全沒有必要使用悲觀鎖的方式來進行防重，不僅對數(shù)據(jù)庫本身造成極大的壓力，同時也會把對于項目擴展性來說也是很大的擴展瓶頸，我們采用了三種方法來解決以上問題：

• 使用Redis來做分布式鎖，Redis采用多個來進行分片，其中一個Redis掛了也沒關(guān)系，重新爭搶就可以了。

• 使用主鍵防重方法，在方法的入口處使用防重表，能夠攔截所有重復的訂單，當重復插入時數(shù)據(jù)庫會報一個重復錯，程序直接返回。

• 使用版本號的機制來防重。

以上三種方式都必須要有過期時間，當鎖定某一資源超時的時候，能夠釋放資源讓競爭重新開始。

2、數(shù)據(jù)庫事務(wù)占用時間過長

偽代碼示例：

項目中類似這樣的程序有很多，經(jīng)常把類似httpClient，或者有可能會造成長時間超時的操作混在事務(wù)代碼中，不

僅會造成事務(wù)執(zhí)行時間超長，而且也會嚴重降低并發(fā)能力。

那么我們在用事務(wù)的時候，遵循的原則是快進快出，事務(wù)代碼要盡量小。針對以上偽代碼，我們要用httpClient這一行拆分出來，避免同事務(wù)性的代碼混在一起，這不是一個好習慣。

3、CPU時間被占滿分析

下面以我之前分析的一個案例作為問題的起始點，首先看下面的圖：

項目在壓測的過程中，CPU一直居高不下，那么通過分析得出如下分析：

1）數(shù)據(jù)庫連接池影響

我們針對線上的環(huán)境進行模擬，盡量真實的在測試環(huán)境中再現(xiàn)，采用數(shù)據(jù)庫連接池為咱們默認的C3P0。

那么當壓測到二萬批，100個用戶同時訪問的時候，并發(fā)量突然降為零！報錯如下：

com.yeepay.g3.utils.common.exception.YeepayRuntimeException: Could not get JDBC Connection; nested exception is java.sql.SQLException: An attempt by a client to checkout a Connection has timed out.

那么針對以上錯誤跟蹤C3P0源碼，以及在網(wǎng)上搜索資料發(fā)現(xiàn)C3P0在大并發(fā)下表現(xiàn)的性能不佳。

2）線程池使用不當引起

以上代碼的場景是每一次并發(fā)請求過來，都會創(chuàng)建一個線程，將DUMP日志導出進行分析發(fā)現(xiàn)，項目中啟動了一萬多個線程，而且每個線程都極為忙碌，徹底將資源耗盡。

那么問題到底在哪里呢？？？就在這一行！

private static final ExecutorService executorService = Executors.newCachedThreadPool();

在并發(fā)的情況下，無限制的申請線程資源造成性能嚴重下降，在圖表中顯拋物線形狀的元兇就是它！！！那么采用這種方式最大可以產(chǎn)生多少個線程呢？？答案是：Integer的最大值！看如下源碼：

那么嘗試修改成如下代碼：

private static final ExecutorService executorService = Executors.newFixedThreadPool(50);

修改完成以后，并發(fā)量重新上升到100以上TPS，但是當并發(fā)量非常大的時候，項目GC（垃圾回收能力下降），分析原因還是因為Executors.newFixedThreadPool(50)這一行，雖然解決了產(chǎn)生無限線程的問題，但是當并發(fā)量非常大的時候，采用newFixedThreadPool這種方式，會造成大量對象堆積到隊列中無法及時消費，看源碼如下：

可以看到采用的是無界隊列，也就是說隊列是可以無限的存放可執(zhí)行的線程，造成大量對象無法釋放和回收。

2）最終線程池技術(shù)方案

方案一

注：因為服務(wù)器的CPU只有4核，有的服務(wù)器甚至只有2核，所以在應(yīng)用程序中大量使用線程的話，反而會造成性能影響，針對這樣的問題，我們將所有異步任務(wù)全部拆出應(yīng)用項目，以任務(wù)的方式發(fā)送到專門的任務(wù)處理器處理，處理完成回調(diào)應(yīng)用程序器。后端定時任務(wù)會定時掃描任務(wù)表，定時將超時未處理的異步任務(wù)再次發(fā)送到任務(wù)處理器進行處理。

方案二

使用AKKA技術(shù)框架，下面是我以前寫的一個簡單的壓測情況：

http://www.jianshu.com/p/6d62256e3327

4、日志打印問題

先看下面這段日志打印程序：

像這樣的代碼是嚴格不符合規(guī)范的，雖然每個公司都有自己的打印要求。

首先日志的打印必須是以logger.error或者logger.warn的方式打印出來。

日志打印格式：[系統(tǒng)來源] 錯誤描述 [關(guān)鍵信息]，日志信息要能打印出能看懂的信息，有前因和后果。甚至有些方法的入?yún)⒑统鰠⒁惨紤]打印出來。

在輸入錯誤信息的時候，Exception不要以e.getMessage的方式打印出來。

合理的日志格式是：

我們在程序中大量的打印日志，雖然能夠打印很多有用信息幫助我們排查問題，但是更多是日志量太多不僅影響磁盤IO，更多會造成線程阻塞對程序的性能造成較大影響。

在使用Log4j1.2.14版本的時候，使用如下格式：

%d %-5p %c:%L [%t] - %m%n

那么在壓測的時候會出現(xiàn)下面大量的線程阻塞，如下圖：

再看壓測圖如下：

原因可以根據(jù)log4j源碼分析如下：

注：Log4j源碼里用了synchronized鎖，然后又通過打印堆棧來獲取行號，在高并發(fā)下可能就會出現(xiàn)上面的情況。

于是修改Log4j配置文件為：

%d %-5p %c [%t] - %m%n

上面問題解決，線程阻塞的情況很少出現(xiàn)，極大的提高了程序的并發(fā)能力，如下圖所示：

作者介紹

程超，易寶支付架構(gòu)師，10年Java工作經(jīng)驗，擅長和感興趣的技術(shù)領(lǐng)域是分布式和大數(shù)據(jù)方面，目前主要從事金融支付類方向。

總結(jié)

以上是生活随笔為你收集整理的如何从代码层面优化系统性能的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。