一行MD5居然讓小伙伴都回不了家！

需求是什么

這里不再介紹具體的業(yè)務(wù)。簡而言之，有兩個接口（查詢、確認(rèn)）對前端頁面提供服務(wù)。

查詢接口返回的數(shù)據(jù)依賴于本地數(shù)據(jù)與外部接口計算后的結(jié)果，也就是頁面展示的是數(shù)據(jù)快照。確認(rèn)接口是按照頁面的展示結(jié)果請求外部接口。

考慮到用戶打開展示頁面時的數(shù)據(jù)與提交操作可能間隔很久，實際請求時結(jié)果已發(fā)生變化，而這種操作會影響業(yè)務(wù)結(jié)果。因此在提交時會進(jìn)行一次 check，如果發(fā)現(xiàn)數(shù)據(jù)發(fā)生變化需要提示頁面進(jìn)行刷新。

為了方便大家理解，我簡單的畫了個圖，畢竟上面太啰嗦了。

查詢接口：

確認(rèn)接口：

雖然這個圖有點草率，但是相信看到這里的小伙伴（默認(rèn)都是聰明的）都對需求了然于胸了。

我怎么搞得

掰扯了半天，我們的主角 MD5 還沒有出場，別著急，馬上就來了。

你也可以想想，這個場景和 MD5 是怎么扯上關(guān)系的呢？

可以看出，這里需要前端將查詢接口的返回值重新組裝作為確認(rèn)接口的入?yún)?。而后端需要再次走?shù)據(jù)聚合的邏輯與前端傳過來的業(yè)務(wù)值進(jìn)行比較，如果不匹配則提示頁面需要刷新。

一切看起來都順理成章，那么小編遇到了什么問題呢？

簡單來說有兩點：

• 前端同學(xué)表示值不好傳，因為這個頁面比較復(fù)雜，具體原因小編也沒深究，可能是被糊弄了。
• 后端同學(xué)（也就是小編）發(fā)現(xiàn)，這樣查詢接口和確認(rèn)接口耦合很嚴(yán)重，如果確認(rèn)接口需要新的入?yún)?，那么就需要改動查詢接口。隨著查詢接口邏輯越來越復(fù)雜，確認(rèn)接口的一個入?yún)⒕托枰粚右粚拥膫鬟^來。很不友好。

呵呵，機(jī)智的小編靈機(jī)一動，便想到了了MD5，看看百度百科怎么說：

MD5 信息摘要算法（英語：MD5 Message-Digest Algorithm），一種被廣泛使用的密碼散列函數(shù)，可以產(chǎn)生出一個 128 位（16 字節(jié)）的散列值（hash value），用于確保信息傳輸完整一致。

一圖勝千言：

在工程，它差不多就是這么用。

String md5= Md5Utils.get(String source);

可能有聰明的小伙伴會說了，這是散列函數(shù)存在哈希碰撞，不同的字符串也有可能生成相同的哈希值。

是的沒錯，但是在小編的業(yè)務(wù)場景中，這種出現(xiàn)的概率微乎其微，忽略不計，解釋權(quán)歸小編所有。

那么具體怎么做的呢，還是看圖說話.

改造后的查詢接口：

改造后的確認(rèn)接口：

我們需要對查詢接口返回的業(yè)務(wù)集關(guān)鍵屬性進(jìn)行組合哈希，這樣可以生成數(shù)據(jù)快照值。確認(rèn)接口無需再傳入業(yè)務(wù)集合，只需要傳入數(shù)據(jù)快照值，后端進(jìn)行對比即可知道是否發(fā)生變更。

一切都是那么的美好，接下來就到了動人心魄的編碼環(huán)節(jié)。話不多說，小編的項目中引入了hutool包，什么你不知道糊涂包？

真不錯，果然是效率擔(dān)當(dāng)，一行代碼就搞定了。

/**
*生成數(shù)據(jù)哈希
*/
privateStringgenerateSnapShotHash(AcceptListQueryWrapResultDTOwrapResultDTO){
StringBuilderbuilder=newStringBuilder();
for(AcceptListQueryResultDTOitem:wrapResultDTO.getAllList()){
builder.append(item.getQuotationId()).append(item.getOperateType()).append(item.getPriceTypeCN());
}
returnMD5.create().digestHex16(builder.toString());
}

請各位看官記住這行代碼：

MD5.create().digestHex16(builder.toString());

畢竟它就是糊弄你點進(jìn)來的罪魁禍?zhǔn)住?/p>

出了什么事

當(dāng)小編開發(fā)完以后，開心的部署在了測試環(huán)境。和前端聯(lián)調(diào)的時候，發(fā)現(xiàn)第一次請求總是超時 ？？？

一想可能是mock平臺的問題，畢竟三方的查詢接口還沒開發(fā)完成，就不以為然。請注意，只是第一次超時。同樣的請求參數(shù)第二次光速返回。呵呵，你說不是環(huán)境的問題，小編自己都不大信呢。

友方的接口開發(fā)完了，小編期待的換上了對方的接口。結(jié)果現(xiàn)實給了小編一記左勾拳，還是第一次超時。這不科學(xué)？于是小編對自身產(chǎn)生了懷疑？難道不是環(huán)境的問題?

于是連忙在本地測試了一下，居然是光速返回。作為自信的人一定不是代碼的問題，那么這個鍋往哪里甩呢？又臭又硬的小編狠狠的思考了一分鐘，又將鍋甩給了業(yè)務(wù)網(wǎng)關(guān)（統(tǒng)一接收HTTP請求）肯定是它的毛病，畢竟測試環(huán)境的網(wǎng)關(guān)出問題很常見。

于是開開心心的準(zhǔn)備上預(yù)發(fā)了。上了預(yù)發(fā)絕對沒問題?。?！小編信誓旦旦的對QA說道。

上帝為你關(guān)上一扇門的同時也會為你關(guān)上一扇窗，預(yù)發(fā)環(huán)境第一次還是超時！??！小編覺得很慚愧對不起一起上線的小伙伴，畢竟大家都準(zhǔn)備十點下機(jī)了。

小編陷入了沉思中。。。

怎么修好的

排查了預(yù)發(fā)環(huán)境的接口，友方的杰夫接口TP99只有幾毫秒，網(wǎng)關(guān)也沒有問題，也許是數(shù)據(jù)庫的原因，排查發(fā)現(xiàn)也沒有問題。頓時，小編又迷茫了。

山重水復(fù)疑無路柳暗花明又一村，機(jī)智的小編想到了國內(nèi)知名廠商開源的一款java診斷工具Arthas，利用它可以查看方法詳細(xì)耗時。點我查看 主動打開另一扇窗。

當(dāng)你遇到以下類似問題而束手無策時，Arthas可以幫助你解決：

• 這個類從哪個 jar 包加載的？為什么會報各種類相關(guān)的 Exception？
• 我改的代碼為什么沒有執(zhí)行到？難道是我沒 commit？分支搞錯了？
• 遇到問題無法在線上 debug，難道只能通過加日志再重新發(fā)布嗎？
• 線上遇到某個用戶的數(shù)據(jù)處理有問題，但線上同樣無法 debug，線下無法重現(xiàn)！
• 是否有一個全局視角來查看系統(tǒng)的運行狀況？
• 有什么辦法可以監(jiān)控到 JVM 的實時運行狀態(tài)？
• 怎么快速定位應(yīng)用的熱點，生成火焰圖？
• 怎樣直接從 JVM 內(nèi)查找某個類的實例？

由于預(yù)發(fā)環(huán)境還是比較麻煩，于是小編在測試環(huán)境準(zhǔn)備好了arthas環(huán)境。

下面簡單介紹下使用步驟：

• 下載全量包 arthas-bin.zip
• 解壓
• chmod -777 arthas-boot.jar
• 啟動 sudo -u admin -EH java -jar /home/export/App/arthas-boot.jar

當(dāng)看到圖標(biāo)出現(xiàn)時，即啟動成功。具體使用方法可以查看官網(wǎng)，此處不再贅述。

我們使用trace命令查看方法耗時，同時在頁面請求該查詢接口。

trace --skipJDKMethod false com.jd.universal.inquiry.service.protocol.jsf.AcceptListWebErpServiceImpl queryList

可以看到這行生成數(shù)據(jù)快照的方法，耗時占整個接口的99.57%，緊接著我們繼續(xù)監(jiān)控generateSnapShotHash方法：

trace --skipJDKMethod false com.jd.universal.inquiry.service.protocol.jsf.AcceptListWebErpServiceImpl generateSnapShotHash

可以看到方法的耗時都集中在

[99.99% 36562.318173ms ] cn.hutool.crypto.digest.MD5:create() #103

接著再次頁面點擊請求操作，出現(xiàn)以下情況：

可以看到后面多次請求 cn.hutool.crypto.digest.MD5:create()方法耗時僅不到一毫秒。和我們之前遇到的狀況一致。此時已確定是這行MD5導(dǎo)致的第一次加載很慢。

雖然原因找到了，但是還是得看下為什么這行代碼只有在第一次時這么慢，于是我們進(jìn)入該方法看看它到底搞什么幺蛾子。

可以看到初始化方法如下：

由于現(xiàn)象是程序第一次運行很慢，后續(xù)很快，根據(jù)小編多年的寫/修BUG經(jīng)驗懷疑是這段初始化中存在靜態(tài)加載。

MessageDigest是JDK自帶的類，為應(yīng)用程序提供摘要算法的，這里我們關(guān)注點就落在了上面的一行。我們點進(jìn)去看一下：

果然我們看到了他在嘗試加載BouncyCastle庫，我們來看一下這個庫的介紹：

BouncyCastle（輕量級密碼術(shù)包）是一種用于 Java 平臺的開放源碼的輕量級密碼術(shù)包；Bouncycstle 包含了大量的密碼算法，其支持橢圓曲線密碼算法，并提供 JCE 1.2.1 的實現(xiàn)。

所以問題的答案就呼之欲出了，隨著源碼的深入，我們看到：

privatevoidsetup()
{
loadAlgorithms(DIGEST_PACKAGE,DIGESTS);

loadAlgorithms(SYMMETRIC_PACKAGE,SYMMETRIC_GENERIC);

loadAlgorithms(SYMMETRIC_PACKAGE,SYMMETRIC_MACS);

loadAlgorithms(SYMMETRIC_PACKAGE,SYMMETRIC_CIPHERS);

loadAlgorithms(ASYMMETRIC_PACKAGE,ASYMMETRIC_GENERIC);

loadAlgorithms(ASYMMETRIC_PACKAGE,ASYMMETRIC_CIPHERS);

loadAlgorithms(KEYSTORE_PACKAGE,KEYSTORES);

loadAlgorithms(SECURE_RANDOM_PACKAGE,SECURE_RANDOMS);

loadPQCKeys();//sowecanhandlecertificatescontainingthem.
//省略。。。
}

正是由于這些算法實現(xiàn)的加載，導(dǎo)致MD5.create()第一次調(diào)用時耗時超過數(shù)十秒。

好了，既然找到了問題。那么改動起來就很簡單了，小編嘗試尋找了糊涂包中提供的方法，發(fā)現(xiàn)并沒有入?yún)⒖梢躁P(guān)閉該三方加密包的初始化。于是換用了Google提供的MD5的實現(xiàn)。重新打包，部署，一次成功，完美。

后語

QA同學(xué)在測試環(huán)境測出了這個問題，而自信的本人不屑一顧，堅持自己愚昧的觀點，先認(rèn)為是Mock的問題，接著又說是網(wǎng)關(guān)的問題。由于我的盲目自信，導(dǎo)致上線到很晚，表示非常的慚愧。總結(jié)失敗的原因：

• 合理評估使用第三方包
• 測試環(huán)境遇到的問題盡力去追，不要盲目下結(jié)論
• 要聽QA的話