作者：京東零售 付偉
1. 前言
大家好，當你點開這篇文章的時候也許心想是哪個 XX 小編混到這裏，先不要着急扔臭雞蛋，本文是一篇標準（正經）的問題覆盤文章。好了，一行MD5居然讓小夥伴下不了班，到底是什麼問題呢，讓我們一起來看看吧。
2. 正文
2.1 需求是什麼
這裏不再介紹具體的業務。簡而言之，有兩個接口（查詢、確認）對前端頁面提供服務。
查詢接口返回的數據依賴於本地數據與外部接口計算後的結果，也就是頁面展示的是數據快照。確認接口是按照頁面的展示結果請求外部接口。
考慮到用户打開展示頁面時的數據與提交操作可能間隔很久，實際請求時結果已發生變化，而這種操作會影響業務結果。因此在提交時會進行一次 check，如果發現數據發生變化需要提示頁面進行刷新。
為了方便大家理解，我簡單的畫了個圖，畢竟上面太囉嗦了。
- 查詢接口
- 確認接口
雖然這個圖有點草率，但是相信看到這裏的小夥伴（默認都是聰明的）都對需求瞭然於胸了。
2.2 我怎麼搞得
掰扯了半天，我們的主角MD5還沒有出場，彆着急風雨總在彩虹後。
可以看出，這裏需要前端將查詢接口的返回值重新組裝作為確認接口的入參。而後端需要再次走數據聚合的邏輯與前端傳過來的業務值進行比較，如果不匹配則提示頁面需要刷新。
一切看起來都順理成章，那麼小編遇到了什麼問題呢？
簡單來説有兩點：
- 前端同學表示值不好傳，因為這個頁面比較複雜，具體原因小編也沒深究，可能是被糊弄了。
- 後端同學（也就是小編）發現，這樣查詢接口和確認接口耦合很嚴重，如果確認接口需要新的入參，那麼就需要改動查詢接口。隨着查詢接口邏輯越來越複雜，確認接口的一個入參就需要一層一層的傳過來。很不友好。
呵呵，機智的小編靈機一動，便想到了了MD5，看看百度百科怎麼説
MD5 信息摘要算法（英語：MD5 Message-Digest Algorithm），一種被廣泛使用的密碼散列函數，可以產生出一個 128 位（16 字節）的散列值（hash value），用於確保信息傳輸完整一致。
一圖勝千言
在工程，它差不多就是這麼用。
String md5= Md5Utils.get(String source);
可能有聰明的小夥伴會説了，這是散列函數存在哈希碰撞，不同的字符串也有可能生成相同的哈希值。
是的沒錯，但是在小編的業務場景中，這種出現的概率微乎其微，忽略不計，解釋權歸小編所有。
那麼具體怎麼做的呢，還是看圖説話：
- 改造後的查詢接口
- 改造後的確認接口
我們需要對查詢接口返回的業務集關鍵屬性進行組合哈希，這樣可以生成數據快照值。確認接口無需再傳入業務集合，只需要傳入數據快照值，後端進行對比即可知道是否發生變更。
一切都是那麼的美好，接下來就到了動人心魄的編碼環節。話不多説，小編的項目中引入了hutool包，什麼你不知道糊塗包？
Hutool 是一個小而全的 Java 工具類庫，通過靜態方法封裝，降低相關 API 的學習成本，提高工作效率，使 Java 擁有函數式語言般的優雅，讓 Java 語言也可以“甜甜的”。Hutool 中的工具方法來自每個用户的精雕細琢，它涵蓋了 Java 開發底層代碼中的方方面面，它既是大型項目開發中解決小問題的利器，也是小型項目中的效率擔當；
真不錯，果然是效率擔當，一行代碼就搞定了。
/**
* 生成數據哈希
*/
private String generateSnapShotHash(AcceptListQueryWrapResultDTO wrapResultDTO) {
StringBuilder builder = new StringBuilder();
for (AcceptListQueryResultDTO item : wrapResultDTO.getAllList()) {
builder.append(item.getQuotationId()).append(item.getOperateType()).append(item.getPriceTypeCN());
}
return MD5.create().digestHex16(builder.toString());
}
請各位看官記住這行代碼
MD5.create().digestHex16(builder.toString());
畢竟它就是糊弄你點進來的罪魁禍首。
2.3 出了什麼事
當小編開發完以後，開心的部署在了測試環境。和前端聯調的時候，發現第一次請求總是超時 ？？？
一想可能是mock平台的問題，畢竟三方的查詢接口還沒開發完成，就不以為然。請注意，只是第一次超時。同樣的請求參數第二次光速返回。呵呵，你説不是環境的問題，小編自己都不大信呢。
友方的接口開發完了，小編期待的換上了對方的接口。結果現實給了小編一記左勾拳，還是第一次超時。這不科學？於是小編對自身產生了懷疑？難道不是環境的問題?
於是連忙在本地測試了一下，居然是光速返回。作為自信的人一定不是代碼的問題，那麼這個鍋往哪裏甩呢？又臭又硬的小編狠狠的思考了一分鐘，又將鍋甩給了業務網關（統一接收HTTP請求）肯定是它的毛病，畢竟測試環境的網關出問題很常見。
於是開開心心的準備上預發了。上了預發絕對沒問題！！！小編信誓旦旦的對QA説道。
上帝為你關上一扇門的同時也會為你關上一扇窗，預發環境第一次還是超時！！！小編覺得很慚愧對不起一起上線的小夥伴，畢竟大家都準備十點下機了。
小編陷入了沉思中。。。
2.4 怎麼修好的
排查了預發環境的接口，友方的傑夫接口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 的實現。
所以問題的答案就呼之欲出了，隨着源碼的深入，我們看到：
private void setup()
{
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(); // so we can handle certificates containing them.
//省略。。。
}
正是由於這些算法實現的加載，導致MD5.create()第一次調用時耗時超過數十秒。
好了，既然找到了問題。那麼改動起來就很簡單了，小編嘗試尋找了糊塗包中提供的方法，發現並沒有入參可以關閉該三方加密包的初始化。於是換用了Google提供的MD5的實現。重新打包，部署，一次成功，完美。
3. 後語
QA同學在測試環境測出了這個問題，而自信的本人不屑一顧，堅持自己愚昧的觀點，先認為是Mock的問題，接着又説是網關的問題。由於小編的盲目自信，導致上線到很晚，表示非常的慚愧。總結失敗的原因：
- 合理評估使用第三方包
- 測試環境遇到的問題盡力去追，不要盲目下結論
- 要聽QA的話
4. 參考
Bouncy Castle 加密算法包
arthas 官方文檔
使用 Arthas 進行生產代碼熱修復
