問題描述

可能像圖片上的代碼出現(xiàn)負(fù)數(shù)的概率不大，但在if語句后加上Thread.sleep(10);就能看到輸出負(fù)數(shù)

問題解答

不知道你要問什么，多個線程同時讀取一個資源出現(xiàn)不同步問題很正常，因為可能一個線程獲取值的時候另一個線程恰好在寫值，這就會產(chǎn)生同步問題。

解決辦法有很多，最笨的直接代碼塊上加同步，整個鎖起來；好點的是用線程安全的類，比如AtomInteger這種，保證同步；如果對多線程很有研究，甚至可以只加很少的鎖就能完成任務(wù)。

線程的調(diào)用順序是不保證有序的，其根本原因在于JVM協(xié)調(diào)資源時線程之間的切換。

本質(zhì)原因是CPU為了提高效率會對指令進行重排序

沒有對num進行同步，不能保證當(dāng)前線程對num的值改之后，其他線程可以立馬看到，題主可以了解下Java內(nèi)存模型。 以題主的代碼為例，假設(shè)執(zhí)行到最后num=1，三個線程同時執(zhí)行到if判斷，都能判斷出通過，那就有可能出現(xiàn)負(fù)數(shù)。

1、內(nèi)存可見性2、修改的原子性

由于num是類靜態(tài)變量，那么它會被存到堆中，在run()方法執(zhí)行時拷貝一份副本到棧中存儲，當(dāng)有多個線程修改時，可能同時拿到一樣的副本，但是由于執(zhí)行的前后順序，一個線程修改并寫入了該變量，雖然堆中num已經(jīng)發(fā)生變化，但是其他線程并不知道，它們會繼續(xù)修改那份副本。然后修改后寫入堆中，那這樣就會覆蓋之前線程的修改，進而導(dǎo)致狀態(tài)的不一致問題。那么如果才能確保線程安全性呢。那就要確保修改num之前保證對堆區(qū)修改的可見性，修改之前再拿一份副本(即使之前已經(jīng)拿過了)，這個可用volatile關(guān)鍵字來保證。

原子性，由于num--實際執(zhí)行是兩個操作,那么就會存在執(zhí)行順序問題。即使在前面說過用volatilel來保證可見性。但是還會存在修改被其他線程覆蓋的情形，只不過幾率變小了。怎樣保證原子性呢，可以采用synchronized關(guān)鍵字，Lock機制，以及JDK并發(fā)工具包等。對于這種情形，最簡單的辦法就是

private static AtomicInteger num=new AtomicInteger(100);