這是一個真實案例，曾經(jīng)惹出碩大風波，故事的起因卻很簡單，就是需要實現(xiàn)一個簡單的計數(shù)器，每次取值然后加1，于是就有了下面這段代碼：
private int counter = 0;
public int getCount ( ) {
return counter++;
}
這個計數(shù)器被用于生成一個sessionId，這個sessionID用于和外部計費系統(tǒng)交互，這個sessionId理所當然的要求保證全局唯一而不重復。但是很遺憾，上面的代碼最終被發(fā)現(xiàn)會產(chǎn)生相同的id，因此會造成一些請求莫名其妙的報錯.....更痛苦的是，上面這段代碼是一個來自其他部門開發(fā)的工具類，我們當時只是拿了它的jar包來調(diào)用，沒有源碼，更沒有想這里面會有如此低級而可怕的錯誤。
由于重復的sessionId，造成有個別請求失敗，雖然出現(xiàn)概率極低，經(jīng)常跑一天測試都不見得能重現(xiàn)一次。因為是和計費相關(guān)，因此哪怕是再低的概率出錯，也不得不要求解決。實際情況是，項目開發(fā)到最后階段，都開始做發(fā)布前最后的穩(wěn)定性測試了，在7*24小時的連續(xù)測試中，這個問題往往在測試開始幾天后才重現(xiàn)，將當時負責trouble shooting的同事折騰的很慘......經(jīng)過反復的查找，終于有人懷疑到這里，反編譯了那個jar包，才看到上面這段出問題的代碼。
這個低級的錯誤，源于一個java的基本知識：
++操作，無論是i++還是++i，都不是原子操作！
而一個非原子操作，在多線程并發(fā)下會有線程安全的問題：這里稍微解釋一下，上面的"++"操作符，從原理上講它其實包含以下：計算加1之后的新值，然后將這個新值賦值給原變量，返回原值。類似于下面的代碼
private int counter = 0;
public int getCount ( ) {
int result = counter;
int newValue = counter + 1; // 1. 計算新值
counter = newValue; // 2. 將新值賦值給原變量
return result;
}
多線程并發(fā)時，如果兩個線程同時調(diào)用getCount()方法，則他們可能得到相同的counter值。為了保證安全，一個最簡單的方法就是在getCount()方法上做同步：
private int counter = 0;
public synchronized int getCount ( ) {
return counter++;
}
這樣就可以避免因++操作符的非原子性而造成的并發(fā)危險。
我們在這個案例基礎(chǔ)上稍微再擴展一下，如果這里的操作是原子操作，就可以不用同步而安全的并發(fā)訪問嗎？我們將這個代碼稍作修改:
private int something = 0;
public int getSomething ( ) {
return something;
}
public void setSomething (int something) {
this.something = something;
}
假設(shè)有多線程同時并發(fā)訪問getSomething()和setSomething()方法，那么當一個線程通過調(diào)用setSomething()方法設(shè)置一個新的值時，其他調(diào)用getSomething()的方法是不是立即可以讀到這個新值呢？這里的"this.something = something;" 是一個對int 類型的賦值，按照java 語言規(guī)范，對int的賦值是原子操作，這里不存在上面案例中的非原子操作的隱患。
但是這里還是有一個重要問題，稱為"內(nèi)存可見性"。這里涉及到j(luò)ava內(nèi)存模型的一系列知識，限于篇幅，不詳盡講述，不清楚這些知識點的可以自己翻翻資料，最簡單的辦法就是google一下這兩個關(guān)鍵詞"java 內(nèi)存模型", "java 內(nèi)存可見性"?；蛘?，可以參考這個帖子"java線程安全總結(jié)"， http://www.iteye.com/topic/806990。
解決這里的"內(nèi)存可見性"問題的方式有兩個，一個是繼續(xù)使用 synchronized 關(guān)鍵字，代碼如下
private int something = 0;
public synchronized int getSomething ( ) {
return something;
}
public synchronized void setSomething (int something) {
this.something = something;
}
另一個是使用volatile 關(guān)鍵字，
private volatile int something = 0;
public int getSomething ( ) {
return something;
}
public void setSomething (int something) {
this.something = something;
}
使用volatile 關(guān)鍵字的方案，在性能上要好很多，因為volatile是一個輕量級的同步，只能保證多線程的內(nèi)存可見性，不能保證多線程的執(zhí)行有序性。因此開銷遠比synchronized要小。
讓我們再回到開始的案例，因為我們采用直接在 getCount() 方法前加synchronized 的修改方式，因此不僅僅避免了非原子性操作帶來的多線程的執(zhí)行有序性問題，也"順帶"解決了內(nèi)存可見性問題。
OK，現(xiàn)在可以繼續(xù)了，前面講到可以通過在 getCount() 方法前加synchronized 的方式來解決問題，但是其實還有更方便的方式，可以使用jdk 5.0之后引入的concurrent包中提供的原子類，java.util.concurrent.atomic.Atomic***，如AtomicInteger，AtomicLong等。
private AtomicInteger counter = new AtomicInteger(0);
public int getCount ( ) {
return counter.incrementAndGet();
}
Atomic類不僅僅提供了對數(shù)據(jù)操作的線程安全保證，而且提供了一系列的語義清晰的方法如incrementAndGet(),getAndIncrement,addAndGet(),getAndAdd()，使用方便。更重要的是，Atomic類不是一個簡單的同步封裝，其內(nèi)部實現(xiàn)不是簡單的使用synchronized，而是一個更為高效的方式CAS (compare and swap) + volatile，從而避免了synchronized的高開銷，執(zhí)行效率大為提升。限于篇幅，關(guān)于“CAS”原理就不在這里講訴。
因此，出于性能考慮，強烈建議盡量使用Atomic類，而不要去寫基于synchronized關(guān)鍵字的代碼實現(xiàn)。
最后總結(jié)一下，在這個帖子中我們講訴了一下幾個問題：
1. ++操作不是原子操作
2. 非原子操作有線程安全問題
3. 并發(fā)下的內(nèi)存可見性
4. Atomic類通過CAS + volatile可以比synchronized做的更高效，推薦使用