java.net.SocketException: Connection reset 解決方法
自從SEOTcs系統(tǒng)11月份24日更新了一下SEO得分算法以來(lái),一直困擾我的一個(gè)問(wèn)題出現(xiàn)了,java的數(shù)據(jù)job任務(wù),在執(zhí)行過(guò)程中會(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異常在客戶(hù)端和服務(wù)器端都有可能發(fā)生,引起該異常的原因有兩個(gè):
1,如果一端的Socket被關(guān)閉(或主動(dòng)關(guān)閉,或因?yàn)楫惓M顺龆?引起的關(guān)閉),另一端仍發(fā)送數(shù)據(jù),發(fā)送的第一個(gè)數(shù)據(jù)包引發(fā)該異常(Connect reset by peer)。
2,一端退出,但退出時(shí)并未關(guān)閉該連接,另一端如果在從連接中讀數(shù)據(jù)則拋出該異常(Connection reset)。簡(jiǎn)單的說(shuō)就是在連接斷開(kāi)后的讀和寫(xiě)操作引起的。
于是我簡(jiǎn)單的認(rèn)為通過(guò)設(shè)置一些socket的timeout時(shí)間,就能解決:

但是設(shè)置以后情況依然是那樣。
這個(gè)問(wèn)題困擾了好幾天,每天都在思考和對(duì)比測(cè)試中,以求發(fā)現(xiàn)造成這個(gè)原因代碼的地方,我不禁思考,同樣數(shù)量的關(guān)鍵詞數(shù)量前提下,為什么之前批量查詢(xún)排名數(shù)據(jù)沒(méi)有出錯(cuò),而最近會(huì)頻繁報(bào)錯(cuò),這到底是為什么?是被請(qǐng)求的接口網(wǎng)站屏蔽掉了我們的服務(wù)器ip?這個(gè)理由也不是很充分,肯定是程序中某個(gè)地方?jīng)]有合理釋放掉connection的連接導(dǎo)致!
在這個(gè)思路的指引下,通過(guò)幾天連續(xù)的奮戰(zhàn)和實(shí)踐,今天終于發(fā)現(xiàn)了問(wèn)題的本質(zhì),那就是那個(gè)timer的方法導(dǎo)致的!情況是這樣的,這幾天,我在手動(dòng)觸發(fā)一些批量任務(wù),發(fā)現(xiàn)在過(guò)濾排名值為100的情況下,java的java.net.SocketException: Connection reset 這個(gè)錯(cuò)會(huì)一直拋出,而且刷屏特別厲害,在仔細(xì)對(duì)照了timer的這段代碼
后,終于猛然醒悟,對(duì)!就是這里出問(wèn)題了,我自己來(lái)分析一下:
一個(gè)函數(shù)值,它返回的值,是一個(gè)臨界值,但是我這個(gè)timer的方法中,判斷了返回的值如果是臨界值的話(huà),會(huì)迫使它在10秒內(nèi)繼續(xù)執(zhí)行那個(gè)方法,而這個(gè)方法是要去獲取一個(gè)頁(yè)面中源代碼的一個(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)過(guò)測(cè)試,每個(gè)這樣的方法執(zhí)行時(shí)間為80毫秒左右),在10秒時(shí)間內(nèi),會(huì)建立10*1000/80 = 125次socket連接,即每秒會(huì)建立起12.5個(gè)socket連接,再加上由于這個(gè)是過(guò)濾的程序,多個(gè)臨界值的情況會(huì)連續(xù)出現(xiàn)在一起,所以,在短暫的幾秒鐘內(nèi),對(duì)同一個(gè)網(wǎng)站頁(yè)面的socket連接數(shù)會(huì)飆升的很高,達(dá)到幾百甚至上千,導(dǎo)致等待處理的請(qǐng)求連接數(shù)太高:

當(dāng)初為什么會(huì)用這個(gè)定時(shí)器方法來(lái)讓一個(gè)方法多執(zhí)行幾遍,原因就是為了獲取一個(gè)數(shù)據(jù)的穩(wěn)定值,但是現(xiàn)在想來(lái),帶來(lái)的負(fù)面影響代價(jià)是多么的大,產(chǎn)生的效果是不可小覷的,不過(guò)經(jīng)過(guò)幾天的綜合分析和測(cè)試,終于還是發(fā)現(xiàn)了這個(gè)罪魁禍?zhǔn)祝瑔?wèn)題解決后,心,一下子豁然了,可以安心睡覺(jué)了。。。
相關(guān)文章
解決IDEA使用Spring Initializr創(chuàng)建項(xiàng)目時(shí)無(wú)法連接到https://start.spring.io的問(wèn)
這篇文章主要介紹了解決IDEA使用Spring Initializr創(chuàng)建項(xiàng)目時(shí)無(wú)法連接到https://start.spring.io的問(wèn)題,本文通過(guò)圖文并茂的形式給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2020-04-04
SpringBoot實(shí)現(xiàn)分庫(kù)分表
這篇文章主要介紹了SpringBoot實(shí)現(xiàn)分庫(kù)分表,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2022-02-02
SpringBoot應(yīng)用中出現(xiàn)的Full GC問(wèn)題的場(chǎng)景與解決
這篇文章主要為大家詳細(xì)介紹了SpringBoot應(yīng)用中出現(xiàn)的Full GC問(wèn)題的場(chǎng)景與解決方法,文中的示例代碼講解詳細(xì),感興趣的小伙伴可以跟隨小編一起學(xué)習(xí)一下2025-04-04
Java?Chassis3熔斷機(jī)制的改進(jìn)路程技術(shù)解密
這篇文章主要介紹了Java?Chassis?3技術(shù)解密之熔斷機(jī)制的改進(jìn)路程實(shí)例分析,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2024-01-01
使用concurrentHashMap如何實(shí)現(xiàn)緩存
文章介紹了使用ConcurrentHashMap實(shí)現(xiàn)緩存的線(xiàn)程安全性和初始化方法,以及如何處理高并發(fā)場(chǎng)景下的緩存清理和數(shù)據(jù)一致性問(wèn)題,包括分桶、使用ConcurrentLinkedQueue以及使用CountDownLatch來(lái)確保緩存數(shù)據(jù)的不丟失2025-02-02
RocketMQ?ConsumeQueue與IndexFile實(shí)時(shí)更新機(jī)制源碼解析
這篇文章主要為大家介紹了RocketMQ?ConsumeQueue與IndexFile實(shí)時(shí)更新機(jī)制源碼解析,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-05-05
Springboot自帶定時(shí)任務(wù)實(shí)現(xiàn)動(dòng)態(tài)配置Cron參數(shù)方式
這篇文章主要介紹了Springboot自帶定時(shí)任務(wù)實(shí)現(xiàn)動(dòng)態(tài)配置Cron參數(shù)方式,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2021-11-11

