Java并發(fā)統(tǒng)計變量值偏差原因及解決方案
1 問題描述
在一個項目中,需要對發(fā)送的請求結(jié)果進行統(tǒng)計,開發(fā)同事定義了兩個全局共享變量CommonUtil.ReqFailNum和ReqNum,分別記錄請求失敗數(shù)和發(fā)送的請求數(shù)。并在每次發(fā)送請求之前都假定該請求會處理失敗,先對其累加,直到成功收到200的返回碼后,重新修正失敗數(shù)量。
最后當應(yīng)用處理請求處于較頻繁的階段時,出現(xiàn)了ReqFailNum最后減為負數(shù)的情況,一次正常請求完成時,
CommonUtil.ReqFailNum ++;和CommonUtil.ReqFailNum --應(yīng)該是成對出現(xiàn)的,這個統(tǒng)計值不應(yīng)該為負數(shù)的。
發(fā)送請求的代碼如下:
private static boolean XMLPost(String content, String sendUrl) throws Exception{ boolean bn = false; if ( null != content ) { //初始假設(shè)請求發(fā)送失敗,等待正常返回200后再將失敗記錄數(shù)-- CommonUtil.ReqFailNum ++; URL url =null; URLConnection con = null; OutputStreamWriter out = null; try { url = new URL(sendUrl); con = url.openConnection(); }catch (MalformedURLException e1) { throw new ConnException("MalformedURLException"); } catch (IOException e) { throw new ConnException("IOException"); } con.setConnectTimeout(2000); con.setReadTimeout(2000); con.setDoOutput(true); con.setRequestProperty("Connection", "keep-alive"); con.setRequestProperty("Pragma:", "no-cache"); con.setRequestProperty("Cache-Control", "no-cache"); con.setRequestProperty("Content-Type", "text/xml"); try { out = new OutputStreamWriter(con.getOutputStream(), "UTF-8"); out.write(content); out.flush(); out.close(); } catch (UnsupportedEncodingException e) { throw new ConnException("UnsupportedEncodingException"); } catch (IOException e) { String exceptionStr = CommonUtil.stackTraceStr(e); throw new ConnException("IOException."+exceptionStr); }finally{ try { if(out != null){ out.close(); } } catch (IOException e) { throw new ConnException("IOException..."); } } String headline = con.getHeaderField(0); if (headline != null && headline.indexOf("200") > -1) { CommonUtil.ReqFailNum --; CommonUtil.ReqNum ++; bn = true; logger.info("sendUrl:: return 200 ok" ); } } return bn; }
2 錯誤原因分析
統(tǒng)計變量在并發(fā)環(huán)境下,開發(fā)人員卻忽視了其安全問題。由于該方法在Action中調(diào)用,客戶端的每個請求,都會調(diào)用該方法。而Web服務(wù)器處理客戶端的請求時,對每個請求都創(chuàng)建了一個線程去處理。這段對統(tǒng)計變量操作的代碼,曝露在多線程環(huán)境下,卻沒有任何同步處理,很容易導(dǎo)致統(tǒng)計數(shù)據(jù)的不一致問題?! ?br />
在這個應(yīng)用中,ReqFailNum++這個操作實際上應(yīng)該是一個原子操作,它包含了對內(nèi)存的三個動作“讀-修改-寫”,并且結(jié)果狀態(tài)依賴于之前的狀態(tài)。上述代碼,在沒有同步的情況下,當兩個線程同時執(zhí)行這行代碼時,可能讀到的是同一個值,同時+1 ,最終應(yīng)該是兩次累計操作,結(jié)果只累加了一次,由于丟失了一次遞增操作,最終的統(tǒng)計值就偏差了1。
由于++代碼是方法最初的幾行,線程同時執(zhí)行++操作的概率較大,而CommonUtil.ReqFailNum --;是在請求成功處理完成后執(zhí)行的,這段時間涉及到網(wǎng)絡(luò)請求,處理時間不確定性較大,所以- -操作同時執(zhí)行的概率也較低。最終ReqFailNum++丟失的次數(shù)會多于ReqFailNum--丟失的次數(shù),從而導(dǎo)致這個共享變量ReqFailNum的值成了負數(shù)。
3 解決辦法
1)使用鎖,將ReqFailNum++或--的操作放在同步代碼塊中
2)由于是簡單的統(tǒng)計變量,可以利用原子變量的特性,使用AtomicInteger或AtomicLong
結(jié)論:Web項目中,共享變量的線程安全性容易被忽視,加上數(shù)據(jù)不一致問題的出現(xiàn)具有偶發(fā)、不可預(yù)測等因素(本來想截個圖的,但是應(yīng)用目前并發(fā)量小,沒有出現(xiàn)數(shù)據(jù)不一致的現(xiàn)象,這也是并發(fā)問題隱蔽而不易被發(fā)現(xiàn)的原因),為了防患于未然,在項目伊始就應(yīng)該分析并發(fā)因素,讓開發(fā)人員關(guān)注可變狀態(tài)的線程安全性問題,是非常必要的。
以上就是本文的全部內(nèi)容,希望對大家的學(xué)習(xí)有所幫助,也希望大家多多支持腳本之家。
相關(guān)文章
詳解Java的內(nèi)置異常以及創(chuàng)建自定義異常子類的方法
這篇文章主要介紹了詳解Java的內(nèi)置異常以及創(chuàng)建自定義異常子類的方法,是Java入門學(xué)習(xí)中的基礎(chǔ)知識,需要的朋友可以參考下2015-09-09springboot?集成identityserver4身份驗證的過程解析
這篇文章主要介紹了springboot?集成identityserver4身份驗證的相關(guān)知識,本文給大家介紹的非常詳細,對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值,需要的朋友參考下吧2024-01-01spring mvc DispatcherServlet之前端控制器架構(gòu)詳解
這篇文章主要為大家詳細介紹了spring mvc DispatcherServlet之前端控制器架構(gòu),具有一定的參考價值,感興趣的小伙伴們可以參考一下2018-04-04