問題描述

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

問題解答

不知道你要問什么，多個(gè)線程同時(shí)讀取一個(gè)資源出現(xiàn)不同步問題很正常，因?yàn)榭赡芤粋€(gè)線程獲取值的時(shí)候另一個(gè)線程恰好在寫值，這就會(huì)產(chǎn)生同步問題。

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

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

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

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

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

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

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

private static AtomicInteger num=new AtomicInteger(100);