溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要講解了如何解決Java并發(fā)統(tǒng)計變量值偏差，內(nèi)容清晰明了，對此有興趣的小伙伴可以學習一下，相信大家閱讀完之后會有幫助。
1 問題描述
在一個項目中，需要對發(fā)送的請求結(jié)果進行統(tǒng)計，開發(fā)同事定義了兩個全局共享變量CommonUtil.ReqFailNum和ReqNum,分別記錄請求失敗數(shù)和發(fā)送的請求數(shù)。并在每次發(fā)送請求之前都假定該請求會處理失敗，先對其累加，直到成功收到200的返回碼后，重新修正失敗數(shù)量。
最后當應用處理請求處于較頻繁的階段時，出現(xiàn)了ReqFailNum最后減為負數(shù)的情況，一次正常請求完成時，
CommonUtil.ReqFailNum ++;和CommonUtil.ReqFailNum --應該是成對出現(xiàn)的，這個統(tǒng)計值不應該為負數(shù)的。
發(fā)送請求的代碼如下：
private static boolean XMLPost(String content, String sendUrl) throws Exception{
boolean bn = false;
if ( null != content ) {
//初始假設請求發(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服務器處理客戶端的請求時，對每個請求都創(chuàng)建了一個線程去處理。這段對統(tǒng)計變量操作的代碼，曝露在多線程環(huán)境下，卻沒有任何同步處理，很容易導致統(tǒng)計數(shù)據(jù)的不一致問題?！ ?br/>
在這個應用中，ReqFailNum++這個操作實際上應該是一個原子操作，它包含了對內(nèi)存的三個動作“讀-修改-寫”，并且結(jié)果狀態(tài)依賴于之前的狀態(tài)。上述代碼，在沒有同步的情況下，當兩個線程同時執(zhí)行這行代碼時，可能讀到的是同一個值，同時+1 ，最終應該是兩次累計操作，結(jié)果只累加了一次，由于丟失了一次遞增操作，最終的統(tǒng)計值就偏差了1。
由于++代碼是方法最初的幾行，線程同時執(zhí)行++操作的概率較大，而CommonUtil.ReqFailNum --;是在請求成功處理完成后執(zhí)行的，這段時間涉及到網(wǎng)絡請求，處理時間不確定性較大，所以- -操作同時執(zhí)行的概率也較低。最終ReqFailNum++丟失的次數(shù)會多于ReqFailNum--丟失的次數(shù)，從而導致這個共享變量ReqFailNum的值成了負數(shù)。
3 解決辦法
1）使用鎖，將ReqFailNum++或--的操作放在同步代碼塊中
2）由于是簡單的統(tǒng)計變量，可以利用原子變量的特性，使用AtomicInteger或AtomicLong
結(jié)論：Web項目中，共享變量的線程安全性容易被忽視，加上數(shù)據(jù)不一致問題的出現(xiàn)具有偶發(fā)、不可預測等因素（本來想截個圖的，但是應用目前并發(fā)量小，沒有出現(xiàn)數(shù)據(jù)不一致的現(xiàn)象，這也是并發(fā)問題隱蔽而不易被發(fā)現(xiàn)的原因），為了防患于未然，在項目伊始就應該分析并發(fā)因素，讓開發(fā)人員關注可變狀態(tài)的線程安全性問題，是非常必要的。
看完上述內(nèi)容，是不是對如何解決Java并發(fā)統(tǒng)計變量值偏差有進一步的了解，如果還想學習更多內(nèi)容，歡迎關注億速云行業(yè)資訊頻道。
免責聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點不代表本網(wǎng)站立場，如果涉及侵權請聯(lián)系站長郵箱：is@yisu.com進行舉報，并提供相關證據(jù)，一經(jīng)查實，將立刻刪除涉嫌侵權內(nèi)容。
