可能像圖片上的程式碼出現(xiàn)負(fù)數(shù)的機(jī)率不大,但在if語句後面加上Thread.sleep(10);就能看到輸出負(fù)數(shù)
閉關(guān)修行中......
不知道你要問什麼,多個執(zhí)行緒同時讀取一個資源出現(xiàn)不同步問題很正常,因?yàn)榭赡芤粋€執(zhí)行緒取得值的時候另一個執(zhí)行緒剛好在寫值,這就會產(chǎn)生同步問題。
解決辦法有很多,最笨的直接程式碼區(qū)塊上加同步,整個鎖起來;好點(diǎn)的是用線程安全的類,比如AtomInteger
這種,保證同步;如果對多線程很有研究,甚至可以只加很少的鎖就能完成任務(wù)。
執(zhí)行緒的呼叫順序是不保證有序的,其根本原因在於JVM協(xié)調(diào)資源時執(zhí)行緒之間的切換。
沒有對num進(jìn)行同步,不能保證當(dāng)前執(zhí)行緒對num的值改之後,其他執(zhí)行緒可以立刻看到,題主可以了解下Java記憶體模型。
以題主的程式碼為例,假設(shè)執(zhí)行到最後num=1,三個執(zhí)行緒同時執(zhí)行到if判斷,都能判斷出通過,那就有可能出現(xiàn)負(fù)數(shù)。
1、記憶體可見性
2、修改的原子性
由於num是類別靜態(tài)變量,那麼它會被存到堆中,在run()方法執(zhí)行時拷貝一份副本到棧中存儲,當(dāng)有多個線程修改時,可能同時拿到一樣的副本,但是由於執(zhí)行的前後順序,一個執(zhí)行緒修改並寫入了該變量,雖然堆中num已經(jīng)發(fā)生變化,但是其他執(zhí)行緒並不知道,它們會繼續(xù)修改那份副本。然後修改後寫入堆中,那麼這樣就會覆蓋先前執(zhí)行緒的修改,進(jìn)而導(dǎo)致狀態(tài)的不一致問題。
那麼如果才能確保線程安全性呢。那就要確保修改num之前保證對堆區(qū)修改的可見性,修改之前再拿一份副本(即使之前已經(jīng)拿過了),這個可用volatile關(guān)鍵字來保證。
原子性,由於num--實(shí)際執(zhí)行是兩個操作,那麼就會存在執(zhí)行順序問題。即使在前面說過要用volatilel來確保可見性。但是還會有修改被其他線程覆蓋的情形,只不過幾率變小了。怎麼保證原子性呢,可以採用synchronized關(guān)鍵字,Lock機(jī)制,以及JDK並發(fā)工具包等。對於這種情形,最簡單的方法就是
private static AtomicInteger num=new AtomicInteger(100);