需求是什么

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

查詢接口返回的數據依賴于本地數據與外部接口計算后的結果，也就是頁面展示的是數據快照。確認接口是按照頁面的展示結果請求外部接口。

考慮到用戶打開展示頁面時的數據與提交操作可能間隔很久，實際請求時結果已發生變化，而這種操作會影響業務結果。因此在提交時會進行一次 check，如果發現數據發生變化需要提示頁面進行刷新。

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

查詢接口：

確認接口：

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

我怎么搞得

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

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

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

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

簡單來說有兩點：

• 前端同學表示值不好傳，因為這個頁面比較復雜，具體原因小編也沒深究，可能是被糊弄了。
• 后端同學（也就是小編）發現，這樣查詢接口和確認接口耦合很嚴重，如果確認接口需要新的入參，那么就需要改動查詢接口。隨著查詢接口邏輯越來越復雜，確認接口的一個入參就需要一層一層的傳過來。很不友好。

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

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

一圖勝千言：

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

String md5= Md5Utils.get(String source);

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

是的沒錯，但是在小編的業務場景中，這種出現的概率微乎其微，忽略不計，解釋權歸小編所有。

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

改造后的查詢接口：

改造后的確認接口：

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

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

真不錯，果然是效率擔當，一行代碼就搞定了。

/**
*生成數據哈希
*/
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());

畢竟它就是糊弄你點進來的罪魁禍首。

出了什么事

當小編開發完以后，開心的部署在了測試環境。和前端聯調的時候，發現第一次請求總是超時 ？？？

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

友方的接口開發完了，小編期待的換上了對方的接口。結果現實給了小編一記左勾拳，還是第一次超時。這不科學？于是小編對自身產生了懷疑？難道不是環境的問題?

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

于是開開心心的準備上預發了。上了預發絕對沒問題！！！小編信誓旦旦的對QA說道。

上帝為你關上一扇門的同時也會為你關上一扇窗，預發環境第一次還是超時！！！小編覺得很慚愧對不起一起上線的小伙伴，畢竟大家都準備十點下機了。

小編陷入了沉思中。。。

怎么修好的

排查了預發環境的接口，友方的杰夫接口TP99只有幾毫秒，網關也沒有問題，也許是數據庫的原因，排查發現也沒有問題。頓時，小編又迷茫了。

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

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

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

由于預發環境還是比較麻煩，于是小編在測試環境準備好了arthas環境。

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

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

當看到圖標出現時，即啟動成功。具體使用方法可以查看官網，此處不再贅述。

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

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

可以看到這行生成數據快照的方法，耗時占整個接口的99.57%，緊接著我們繼續監控generateSnapShotHash方法：

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

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

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

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

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

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

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

由于現象是程序第一次運行很慢，后續很快，根據小編多年的寫/修BUG經驗懷疑是這段初始化中存在靜態加載。

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

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

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

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

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.
//省略。。。
}

正是由于這些算法實現的加載，導致MD5.create()第一次調用時耗時超過數十秒。

好了，既然找到了問題。那么改動起來就很簡單了，小編嘗試尋找了糊涂包中提供的方法，發現并沒有入參可以關閉該三方加密包的初始化。于是換用了Google提供的MD5的實現。重新打包，部署，一次成功，完美。

后語

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

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