快捷導(dǎo)航

java.net.SocketException: Connection reset 解決方法

更新時(shí)間：2013年03月20日 14:21:57 作者：

最近糾結(jié)致死的一個(gè)java報(bào)錯(cuò)java.net.SocketException: Connection reset 終于得到解決

自從SEOTcs系統(tǒng)11月份24日更新了一下SEO得分算法以來，一直困擾我的一個(gè)問題出現(xiàn)了，java的數(shù)據(jù)job任務(wù)，在執(zhí)行過程中會(huì)經(jīng)常報(bào)以下的錯(cuò)誤：

“2011-12-03 18:00:32 DefaultHttpClient [INFO] I/O exception (java.net.SocketException) caught when processing request: Connection reset by peer: socket write error
2011-12-03 18:00:32 DefaultHttpClient [INFO] Retrying request”…

為此，我找遍了中英文的一些網(wǎng)站，搜遍了能找的每個(gè)角落，發(fā)現(xiàn)了出現(xiàn)這種狀況的原理，該java異常在客戶端和服務(wù)器端都有可能發(fā)生，引起該異常的原因有兩個(gè)：

1，如果一端的Socket被關(guān)閉（或主動(dòng)關(guān)閉，或因?yàn)楫惓Ｍ顺龆?引起的關(guān)閉），另一端仍發(fā)送數(shù)據(jù)，發(fā)送的第一個(gè)數(shù)據(jù)包引發(fā)該異常(Connect reset by peer)。

2，一端退出，但退出時(shí)并未關(guān)閉該連接，另一端如果在從連接中讀數(shù)據(jù)則拋出該異常（Connection reset）。簡單的說就是在連接斷開后的讀和寫操作引起的。

于是我簡單的認(rèn)為通過設(shè)置一些socket的timeout時(shí)間，就能解決：

但是設(shè)置以后情況依然是那樣。

這個(gè)問題困擾了好幾天，每天都在思考和對比測試中，以求發(fā)現(xiàn)造成這個(gè)原因代碼的地方，我不禁思考，同樣數(shù)量的關(guān)鍵詞數(shù)量前提下，為什么之前批量查詢排名數(shù)據(jù)沒有出錯(cuò)，而最近會(huì)頻繁報(bào)錯(cuò)，這到底是為什么？是被請求的接口網(wǎng)站屏蔽掉了我們的服務(wù)器ip？這個(gè)理由也不是很充分，肯定是程序中某個(gè)地方?jīng)]有合理釋放掉connection的連接導(dǎo)致！

在這個(gè)思路的指引下，通過幾天連續(xù)的奮戰(zhàn)和實(shí)踐，今天終于發(fā)現(xiàn)了問題的本質(zhì)，那就是那個(gè)timer的方法導(dǎo)致的！情況是這樣的，這幾天，我在手動(dòng)觸發(fā)一些批量任務(wù)，發(fā)現(xiàn)在過濾排名值為100的情況下，java的java.net.SocketException: Connection reset 這個(gè)錯(cuò)會(huì)一直拋出，而且刷屏特別厲害，在仔細(xì)對照了timer的這段代碼

后，終于猛然醒悟，對！就是這里出問題了，我自己來分析一下：

一個(gè)函數(shù)值，它返回的值，是一個(gè)臨界值，但是我這個(gè)timer的方法中，判斷了返回的值如果是臨界值的話，會(huì)迫使它在10秒內(nèi)繼續(xù)執(zhí)行那個(gè)方法，而這個(gè)方法是要去獲取一個(gè)頁面中源代碼的一個(gè)特定數(shù)據(jù)，每次這個(gè)方法執(zhí)行會(huì)消耗掉幾十毫秒的時(shí)間，即相當(dāng)于在這個(gè)時(shí)間內(nèi)，是建立了一個(gè)socket連接，但是由于它一直返回的是那個(gè)臨界值，所以這個(gè)方法會(huì)在10秒內(nèi)不停的建立socket連接以獲取數(shù)據(jù)，如果這個(gè)方法每次執(zhí)行時(shí)間大概是80ms（經(jīng)過測試，每個(gè)這樣的方法執(zhí)行時(shí)間為80毫秒左右），在10秒時(shí)間內(nèi)，會(huì)建立10*1000/80 = 125次socket連接，即每秒會(huì)建立起12.5個(gè)socket連接，再加上由于這個(gè)是過濾的程序，多個(gè)臨界值的情況會(huì)連續(xù)出現(xiàn)在一起，所以，在短暫的幾秒鐘內(nèi)，對同一個(gè)網(wǎng)站頁面的socket連接數(shù)會(huì)飆升的很高，達(dá)到幾百甚至上千，導(dǎo)致等待處理的請求連接數(shù)太高：

當(dāng)初為什么會(huì)用這個(gè)定時(shí)器方法來讓一個(gè)方法多執(zhí)行幾遍，原因就是為了獲取一個(gè)數(shù)據(jù)的穩(wěn)定值，但是現(xiàn)在想來，帶來的負(fù)面影響代價(jià)是多么的大，產(chǎn)生的效果是不可小覷的，不過經(jīng)過幾天的綜合分析和測試，終于還是發(fā)現(xiàn)了這個(gè)罪魁禍?zhǔn)?，問題解決后，心，一下子豁然了，可以安心睡覺了。。。

您可能感興趣的文章: