一道很是棘手的 Java 面試題：i++ 是線程安全的嗎？

i++ 是線程安全的嗎？

相信不少中高級的 Java 面試者都遇到過這個問題，不少對這個不是很清楚的確定是一臉蒙逼。心裏確定還在質疑，i++ 竟然還有線程安全問題？只能說本身瞭解的不夠多，本身的水平有限。

先來看下面的示例來驗證下 i++ 究竟是不是線程安全的。

1000個線程，每一個線程對共享變量 count 進行 1000 次 ++ 操做。

上面的例子咱們指望的結果應該是 1000000，但運行 N 遍，你會發現老是不爲 1000000，至少你如今知道了 i++ 操做它不是線程安全的了。

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

每一個線程都有本身的工做內存，每一個線程須要對共享變量操做時必須先把共享變量從主內存 load 到本身的工做內存，等完成對共享變量的操做時再 save 到主內存。

問題就出在這了，若是一個線程運算完後還沒刷到主內存，此時這個共享變量的值被另一個線程從主內存讀取到了，這個時候讀取的數據就是髒數據了，它會覆蓋其餘線程計算完的值。。。

這也是經典的內存不可見問題，那麼把 count 加上 volatile 讓內存可見是否能解決這個問題呢？ 答案是：不能。由於 volatile 只能保證可見性，不能保證原子性。多個線程同時讀取這個共享變量的值，就算保證其餘線程修改的可見性，也不能保證線程之間讀取到一樣的值而後相互覆蓋對方的值的狀況。

關於多線程的幾種關鍵概念請翻閱《多線程之原子性、可見性、有序性詳解》這篇文章。

解決方案

說了這麼多，對於 i++ 這種線程不安全問題有沒有其餘解決方案呢？固然有，請參考如下幾種解決方案。

一、對 i++ 操做的方法加同步鎖，同時只能有一個線程執行 i++ 操做；

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

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

推薦去個人博客閱讀更多：

1.Java JVM、集合、多線程、新特性系列教程

2.Spring MVC、Spring Boot、Spring Cloud 系列教程

3.Maven、Git、Eclipse、Intellij IDEA 系列工具教程

4.Java、後端、架構、阿里巴巴等大廠最新面試題

以爲不錯，別忘了點贊+轉發哦！