一道非常棘手的 常見Java 面試題：i++ 是執行緒安全的嗎？

i++ 是執行緒安全的嗎？

相信很多中高階的 Java 面試者都遇到過這個問題，很多對這個不是很清楚的肯定是一臉蒙逼。內心肯定還在質疑，i++ 居然還有執行緒安全問題？只能說自己瞭解的不夠多，自己的水平有限。

先來看下面的示例來驗證下 i++ 到底是不是執行緒安全的。

1000個執行緒，每個執行緒對共享變數 count 進行 1000 次 ++ 操作。

上面的例子我們期望的結果應該是 1000000，但執行 N 遍，你會發現總是不為 1000000，至少你現在知道了 i++ 操作它不是執行緒安全的了。

先來看 JMM 模型中對共享變數的讀寫原理吧。

每個執行緒都有自己的工作記憶體，每個執行緒需要對共享變數操作時必須先把共享變數從主記憶體 load 到自己的工作記憶體，等完成對共享變數的操作時再 save 到主記憶體。

問題就出在這了，如果一個執行緒運算完後還沒刷到主記憶體，此時這個共享變數的值被另外一個執行緒從主記憶體讀取到了，這個時候讀取的資料就是髒資料了，它會覆蓋其他執行緒計算完的值。。。

**這也是經典的記憶體不可見問題，那麼把 count 加上 volatile 讓記憶體可見是否能解決這個問題呢？**答案是：不能。因為 volatile 只能保證可見性，不能保證原子性。多個執行緒同時讀取這個共享變數的值，就算保證其他執行緒修改的可見性，也不能保證執行緒之間讀取到同樣的值然後相互覆蓋對方的值的情況。

關於多執行緒的幾種關鍵概念請翻閱Java中高階核心知識全面解析——執行緒池(好處、Executor 框架、ThreadPoolExecutor類簡單介紹)這篇文章。

解決方案

說了這麼多，對於 i++ 這種執行緒不安全問題有沒有其他解決方案呢？當然有，請參考以下幾種解決方案。

1、對 i++ 操作的方法加同步鎖，同時只能有一個執行緒執行 i++ 操作；

2、使用支援原子性操作的類，如 java.util.concurrent.atomic.AtomicInteger，它使用的是 CAS 演算法，效率優於第 1 種；

如果對你有幫助，點個贊分享下給個鼓勵吧！

覺得不錯，點贊轉發一下，謝謝大家！