Oracle JDK7 bug 發現、分析與解決實戰
本文首發於 vivo網際網路技術 微信公眾號
連結： https://mp.weixin.qq.com/s/8f34CaTp--Wz5pTHKA0Xeg
作者：vivo 官網商城開發團隊
眾所周知，Oracle JDK 是 Java 語言的絕對權威，很多時候 JDK 與 Java 語言近似一個概念。但我們始終要保持實事求是的精神，敢於質疑。本文記錄了一次線上troubleshoot 實戰，包含問題分析、解決並提交 bug 的核心過程。
一、背景現象
總之 就是某系統上線後 CLOSE_WAIT數量隨著時間增加而大量增加，持續觸發多個告警。
二、分析定位過程
部署了一個節點，用來複現之前出現的問題。
Step1 問題聚焦
先檢視到底是哪些IP之間的連線產生了大量CLOSE_WAIT，另外系統還會涉及調第三方，總之要確認連線建立的雙方。
執行命令：
netstat -np | grep tcp|grep "CLOSE_WAIT"
結果：
（ps：xxx、yyy、zzz 均無含義，基於資訊保安考慮，遮蔽掉 ip）。
tcp 3547 0 10.107.17.xxx:34602 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 38 0 10.107.17.xxx:59088 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 38 0 10.107.17.xxx:58028 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 38 0 10.107.17.xxx:51962 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 3563 0 10.107.17.xxx:46962 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 38 0 10.107.17.xxx:34608 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 38 0 10.107.17.xxx:46496 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 38 0 10.107.17.xxx:50774 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 38 0 10.107.17.xxx:59904 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 38 0 10.107.17.xxx:40208 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 38 0 10.107.17.xxx:41064 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 38 0 10.107.17.xxx:36994 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 3547 0 10.107.17.xxx:45080 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 6235 0 10.107.17.xxx:60966 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 38 0 10.107.17.xxx:56178 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 3547 0 10.107.17.xxx:39922 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 38 0 10.107.17.xxx:43270 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 38 0 10.107.17.xxx:40926 zzz.202.32.242:443 CLOSE_WAIT 19819/java tcp 38 0 10.107.17.xxx:44472 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 2891 0 10.107.17.xxx:43036 zzz.202.32.241:443 CLOSE_WAIT 19819/java ........ ........ tcp 38 0 10.107.17.xxx:33472 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 38 0 10.107.17.xxx:51976 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 38 0 10.107.17.xxx:57788 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 38 0 10.107.17.xxx:35638 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 38 0 10.107.17.xxx:43778 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 38 0 10.107.17.xxx:46418 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 38 0 10.107.17.xxx:49914 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 38 0 10.107.17.xxx:49258 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 38 0 10.107.17.xxx:48718 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 38 0 10.107.17.xxx:51480 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 38 0 10.107.17.xxx:59816 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 38 0 10.107.17.xxx:49266 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 38 0 10.107.17.xxx:50246 yyy.12.230.115:443 CLOSE_WAIT 19819/java tcp 38 0 10.107.17.xxx:39324 yyy.12.230.115:443 CLOSE_WAIT 19819/java
總之：
yyy.12.230.115
zzz.202.32.241
zzz.202.32.241
這個三個IP是導火索。
Step2 問題分析
這三個IP具體是誰？具體是請求了哪個介面？
暫時無法直接獲知！最直接的導火索暫時斷了線索。接著從側面開始檢視更多資訊，
-
JVM資訊
外部資源、執行緒 什麼的都看了,未發現明顯異常
-
抓包
要抓包獲取更多線索了。對於很久沒有碰過TCP層，有些吃力。
得到線索：發現大量的RST
那麼是什麼操作會導致CLOSE_WAIT呢？什麼樣的連線導致大量RST呢(可參考RST通常原因)？
Step3 程式碼分析定位
運維大佬的協助查詢，得知這三個IP是圖片CDN服務。
至此，可以定位到具體程式碼邏輯，圖片CDN請求可以排查程式碼。
仔細分析這部分原始碼後，推測因為伺服器 發起 URL請求，請求不存在，導致丟擲異常，但是JDK中卻沒有地方關閉Socket。
javax.imageio.read（URL）
/**
* Returns a <code>BufferedImage</code> as the result of decoding
* a supplied <code>URL</code> with an <code>ImageReader</code>
* chosen automatically from among those currently registered. An
* <code>InputStream</code> is obtained from the <code>URL</code>,
* which is wrapped in an <code>ImageInputStream</code>. If no
* registered <code>ImageReader</code> claims to be able to read
* the resulting stream, <code>null</code> is returned.
*
* <p> The current cache settings from <code>getUseCache</code>and
* <code>getCacheDirectory</code> will be used to control caching in the
* <code>ImageInputStream</code> that is created.
*
* <p> This method does not attempt to locate
* <code>ImageReader</code>s that can read directly from a
* <code>URL</code>; that may be accomplished using
* <code>IIORegistry</code> and <code>ImageReaderSpi</code>.
*
* @param input a <code>URL</code> to read from.
*
* @return a <code>BufferedImage</code> containing the decoded
* contents of the input, or <code>null</code>.
*
* @exception IllegalArgumentException if <code>input</code> is
* <code>null</code>.
* @exception IOException if an error occurs during reading.
*/
public static BufferedImage read(URL input) throws IOException { if (input == null) { throw new IllegalArgumentException("input == null!");
}
InputStream istream = null; try { //此處，建立TCP連線！並且直接獲取流,因為流資料不存在，進入cache塊，丟擲！
istream = input.openStream();
} catch (IOException e) { throw new IIOException("Can't get input stream from URL!", e);
}
ImageInputStream stream = createImageInputStream(istream);
BufferedImage bi; try {
bi = read(stream); if (bi == null) {
stream.close();
}
} finally {
istream.close();
} return bi;
}
可以看到JDK並沒有關閉 ImageIO.read(url) 程式碼中封裝的Socket連線！CDN會請求超時關閉導致伺服器處於CLOSE_WAIT？限於網路經驗有限，並不能100%確認我的想法。所以模擬下吧。
Step4 復現與模擬
根據系統業務原始碼，快速模擬：
public static void main(String[] args) throws InterruptedException {
ExecutorService ex = Executors.newFixedThreadPool(100); for (int i = 0; i < 5000; i++) {
ex.execute(task());
}
}
/**
* @throws IOException
* @throws MalformedURLException
*/private static Runnable task() {
return new Runnable() {
@Override public void run() { // domain must exists,but file doesnot.
String vivofsUrl = "
File file = null;
BufferedImage image = null;
try {
file = File.createTempFile("abc", "jpg");
URL url1 = new URL(vivofsUrl);
image = ImageIO.read(url1);
} catch (Throwable e) {
e.printStackTrace();
} finally { if (null != file) {
file.delete();
} if (null != image) {
image.flush();
image = null;
}
}
}
};
}
抓包
TCP檢視
問題復現！
Step5 溝通後提報bug
report 給Oracle。
三、Oracle溝通
提單之後，Oracle跟我聯絡溝通。擷取部分郵件內容，僅供參考。
已被採納
四、疑點與不足
TCP狀態機的流轉不夠熟悉透徹。導致一些問題不能從TCP狀態機分析推理，知識的全面精通需要不斷提高。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69912579/viewspace-2702794/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 線上BUG：MySQL死鎖分析實戰MySql
- 《機器學習實戰》決策樹(ID3演算法)的分析與實現機器學習演算法
- 由報警郵件分析發現的備庫oracle bugOracle
- 線上出現bug解決用例
- Maven實戰與原理分析（二）：maven實戰Maven
- kewastUnPackStats(): oracle 11.2.0.1的bug解決方法ASTOracle
- Oracle分析函式多層使用時的一個bug及其解決方案Oracle函式
- SpringCloudAlibaba分散式事務解決方案Seata實戰與原始碼分析-上SpringGCCloud分散式原始碼
- SpringCloudAlibaba分散式事務解決方案Seata實戰與原始碼分析-中SpringGCCloud分散式原始碼
- [Oracle] ORA-03113錯誤分析與解決Oracle
- 量表設計與分析實戰
- 機器學習 - 決策樹：技術全解與案例實戰機器學習
- FPGA解決物聯網實現的核心挑戰FPGA
- Hive常見的bug與解決辦法。Hive
- MySQL觸發器的詳細教學與實戰分析MySql觸發器
- ORACLE常見錯誤程式碼的分析與解決(轉)Oracle
- Oracle 10.2.0.5 EM 啟動BUG問題解決Oracle
- 探索TiDB Lightning的原始碼來解決發現的bugTiDB原始碼
- oradebug分析oracle hangOracle
- C++實現迷宮的生成與解決C++
- RabbitMQ實戰：可用性分析和實現MQ
- masm32開發包與VC6.0之間存在的Bug的體現及解決辦法ASM
- 常見BUG解決
- RecyclerView 事件分發原理實戰分析View事件
- Redux流程分析與實現Redux
- CSRF 詳解與攻防實戰
- Flutter完整開發實戰詳解(八、 實用技巧與填坑)Flutter
- IE雙倍邊距BUG 觸發 解決方案
- 解決GAT專案Bug：軌跡分析查詢不到資料
- Redis哨兵機制全面深入分析與講解[實戰演示篇]Redis
- flutter packages 開發實戰——釋出失敗問題解決FlutterPackage
- Flutter完整開發實戰詳解(二、快速開發實戰篇)Flutter
- MySQL死鎖分析與解決之路MySql
- 在使用SwipebackLayout出現的bug以及解決的方法
- 小冊上新：Taro 多端開發實現原理與專案實戰
- 發現gap及解決
- iOS 解決MJPhotoBrowser的bugiOS
- BUG 解決記錄 一