Java併發統計變量值偏差原因及解決方案

1 問題描述

在一個項目中，需要對發送的請求結果進行統計，開發同事定義了兩個全局共享變量CommonUtil.ReqFailNum和ReqNum,分別記錄請求失敗數和發送的請求數。並在每次發送請求之前都假定該請求會處理失敗，先對其累加，直到成功收到200的返回碼後，重新修正失敗數量。

最後當應用處理請求處於較頻繁的階段時，出現了ReqFailNum最後減為負數的情況，一次正常請求完成時，

CommonUtil.ReqFailNum ++;和CommonUtil.ReqFailNum --應該是成對出現的，這個統計值不應該為負數的。

發送請求的代碼如下：

 private static boolean XMLPost(String content, String sendUrl) throws Exception{ boolean bn = false; if ( null != content ) { //初始假設請求發送失敗，等待正常返回200後再將失敗記錄數-- 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 錯誤原因分析　　

　　統計變量在併發環境下，開發人員卻忽視了其安全問題。由於該方法在Action中調用，客戶端的每個請求，都會調用該方法。而Web服務器處理客戶端的請求時，對每個請求都創建了一個線程去處理。這段對統計變量操作的代碼，曝露在多線程環境下，卻沒有任何同步處理，很容易導致統計數據的不一致問題。　　

　　在這個應用中，ReqFailNum++這個操作實際上應該是一個原子操作，它包含了對內存的三個動作“讀-修改-寫”，並且結果狀態依賴於之前的狀態。上述代碼，在沒有同步的情況下，當兩個線程同時執行這行代碼時，可能讀到的是同一個值，同時+1 ，最終應該是兩次累計操作，結果只累加了一次，由於丟失了一次遞增操作，最終的統計值就偏差了1。

　　由於++代碼是方法最初的幾行，線程同時執行++操作的概率較大，而CommonUtil.ReqFailNum --;是在請求成功處理完成後執行的，這段時間涉及到網絡請求，處理時間不確定性較大，所以- -操作同時執行的概率也較低。最終ReqFailNum++丟失的次數會多於ReqFailNum--丟失的次數，從而導致這個共享變量ReqFailNum的值成了負數。

3 解決辦法　　

　　1）使用鎖，將ReqFailNum++或--的操作放在同步代碼塊中　　

　　2）由於是簡單的統計變量，可以利用原子變量的特性，使用AtomicInteger或AtomicLong

結論：Web項目中，共享變量的線程安全性容易被忽視，加上數據不一致問題的出現具有偶發、不可預測等因素（本來想截個圖的，但是應用目前併發量小，沒有出現數據不一致的現象，這也是併發問題隱蔽而不易被發現的原因），為了防患於未然，在項目伊始就應該分析併發因素，讓開發人員關注可變狀態的線程安全性問題，是非常必要的。