昨天出現一個生產問題。我們的channel系統代碼里，調用其中一個三方服務商的http介面時未設置超時時間。碰巧昨天出現一筆http請求持續數小時始終無響應，加之程式是單線程處理交易請求，就出現因為線程一直處於RUNNABLE狀態而導致系統生產能力嚴重下降。 現在說這個結論很easy，而昨天排查這個 ...
昨天出現一個生產問題。我們的channel系統代碼里，調用其中一個三方服務商的http介面時未設置超時時間。碰巧昨天出現一筆http請求持續數小時始終無響應，加之程式是單線程處理交易請求，就出現因為線程一直處於RUNNABLE狀態而導致系統生產能力嚴重下降。
現在說這個結論很easy，而昨天排查這個問題卻很是花費了許多周折。
那麼，解決這個問題，自然是為這個服務商的http請求設置合理的超時時間。
組內的小伙很快fix了這段代碼，為方法里的http請求設置了connectTimeout和socketTimeout。
發現問題，上來就解決，往往是低效的方式。
為什麼這麼說呢？
曾經我們系統化地調整過channel里的對外http連接的超時時間。而怎麼單單遺漏了這個服務商呢？原來，查看代碼才發現，是這個服務商並沒有依賴我們的公共的http util類，而是單獨寫的http post方法，藏匿得比較深。
consequently，once do,do it well。通過review代碼後，我改成了讓這個服務商也調用公共的http util來實現http通信。
當看到一些不好的代碼時，會發現我還算優秀；當看到優秀的代碼時，也才意識到持續學習的重要！--buguge
本文來自博客園，轉載請註明原文鏈接：https://www.cnblogs.com/buguge/p/17307910.html
