其實(shí)寫Java的人貌似和CPU沒啥關(guān)系，最多最多和我們在前面提及到的如何將CPU跑滿、如何設(shè)置線程數(shù)有點(diǎn)關(guān)系，但是那個算法只是一個參考，很多場景不同需要采取實(shí)際的手段來解決才可以；而且將CPU跑滿后我們還會考慮如何讓CPU不是那么滿，呵呵，人類，就是這么XX，呵呵，好了，本文要說的是其他的一些東西，也許你在java的寫代碼時幾乎不用關(guān)注CPU，因為滿足業(yè)務(wù)才是第一重要的事情，如果你要做到框架級別，為框架提供很多共享數(shù)據(jù)緩存之類的東西，中間必然存在很多數(shù)據(jù)的征用問題，當(dāng)然java提供了很多concurrent包的類，你可以用它，但是它內(nèi)部如何做的，你要明白細(xì)節(jié)才能用得比較好，否則還不如不用，本文可能不是闡述這些內(nèi)容作為重點(diǎn)，因為如標(biāo)題黨：我們要說CPU，呵呵。

還是那句話，貌似java和CPU沒有多少關(guān)系，我們現(xiàn)在來聊聊有啥關(guān)系；

1、當(dāng)遇到共享元素，我們通常第一想法是通過volatile來保證一致性讀的操作，也就是絕對的可見性，所謂可見性，就是每次要使用該數(shù)據(jù)的時候，CPU不會使用任何cache的內(nèi)容都會從內(nèi)存中去抓取一次數(shù)據(jù)，并且這個過程對多CPU仍然有效，也就是相當(dāng)CPU和內(nèi)存之間此時是同步的，CPU會像總線發(fā)出一個Lock addl 0類似的的匯編指令，+0但相對于什么都不會做；不過一旦該指令完成，后續(xù)操作將不再影響這個元素其他線程的訪問，也就是他能實(shí)現(xiàn)的絕對可見性，但是不能實(shí)現(xiàn)一致性操作，也就是說，volatile不能實(shí)現(xiàn)的是i++這類操作的一致性（在多線程下并發(fā)），因為i++操作是被分解為：

int tmp = i;tmp = tmp + 1;i = tmp;

這三個步驟來完成，從這點(diǎn)你也能看出i++為什么能實(shí)現(xiàn)先做其他的事情再自我加1，因為它講值賦予給了另一個變量。

2、我們要用到多線程并發(fā)一致性，就需要用到鎖的機(jī)制，目前類似Atomic*的東西基本可以滿足這些要求，內(nèi)部提供了很多unsafe類的方法，通過不斷對比絕對可見性的數(shù)據(jù)來保證獲取的數(shù)據(jù)是最新的；接下來我們繼續(xù)來說一些CPU其他的事情。

3、以前我們?yōu)榱藢PU跑滿，但是無論如何跑不滿，因為我們開始說了忽略掉內(nèi)存與CPU的延遲，今天既然提及到這兒，我們就簡單說下延遲，一般來講現(xiàn)在的CPU有三級cache，年代不同延遲不同，所以具體數(shù)字只能說個大概而已，現(xiàn)在的CPU一般一級cache的延遲在1-2ns，二級cache一般是幾個ns到十來ns左右，三級cache一般是30ns到50ns不等，內(nèi)存訪問普遍會上到70ns甚至更多（計算機(jī)發(fā)展速度很快，這個值也僅僅在某些CPU上的數(shù)據(jù)，做一個范圍參考而已）；別看這個延遲很小，都是納秒級別，你會發(fā)現(xiàn)你的程序被拆分為指令運(yùn)算的時候，會有很多CPU交互，每次交互的延遲如果有這么大的偏差，此時系統(tǒng)性能是會有變化的；

4、回到剛才說的volatile，它每次從內(nèi)存中獲取數(shù)據(jù)，就是放棄cache，自然如果在某些單線程的操作中，會變得更加慢，有些時候我們也不得不這樣做，甚至于讀寫操作都要求一致性，甚至于整個數(shù)據(jù)塊都被同步，我們只能在一定程度上降低鎖的粒度，但是不能完全沒有鎖，即使是CPU本身級別也會有指令級別的限制。

5、在CPU本身級別的原子操作一般叫屏障，有讀屏障、寫屏障等，一般是基于一個點(diǎn)的觸發(fā)，當(dāng)程序多條指令發(fā)送到CPU的時候，有些指令未必是按照程序的順序來執(zhí)行，有些必須按照程序的順序來執(zhí)行，只要能最終保證一致即可；在排序上，JIT在運(yùn)行時會做改變，CPU指令級別也會做改變，原因主要是為了優(yōu)化運(yùn)行時指令讓程序跑得更快。

6、CPU級別會對內(nèi)存做cache line的操作，所謂cache line會連續(xù)讀一塊內(nèi)存，一般和CPU型號和架構(gòu)有關(guān)系，現(xiàn)在很多CPU每次讀取連續(xù)內(nèi)存一般是64byte，早期的有32byte的，所以在某些數(shù)組遍歷的時候會比較快（基于列遍歷很慢），但這個并不完全對，下面會對照一些相反的情況來說。

7、CPU對數(shù)據(jù)如果發(fā)生了修改，此時就不得不說CPU對數(shù)據(jù)修改的狀態(tài)，數(shù)據(jù)如果都被讀取，在多CPU下可以被多線程并行讀取并，當(dāng)對數(shù)據(jù)塊發(fā)生寫操作的時候，就不一樣了，數(shù)據(jù)塊會有獨(dú)占、修改、失效等狀態(tài)，數(shù)據(jù)修改后自然就會失效，當(dāng)在多CPU下，多個線程都在對同一個數(shù)據(jù)塊進(jìn)行修改時，就會發(fā)生CPU之間的總線數(shù)據(jù)拷貝（QPI），當(dāng)然如果修改到同一個數(shù)據(jù)上的時候我們是沒有辦法的，但是回到第6點(diǎn)的cache line里面，問題就比較麻煩了，如果數(shù)據(jù)是在同一個數(shù)組上，而數(shù)組中的元素會被同時cache line到一個CPU上的時候，多線程的QPI就會非常頻繁，有些時候即使是數(shù)組上組裝的是對象也會出現(xiàn)這個問題，如：

class InputInteger {private int value;public InputInteger(int i) {this.value = i;}}InputInteger[] integers = new InputInteger[SIZE];for(int i=0 ; i < SIZE ; i++) {integers[i] = new InputInteger(i);}

此時你看出來integers里面放的全部是對象，數(shù)組上只有對象的引用，但是對象的排布理論上說各自對象是獨(dú)立的，不會連續(xù)存放，不過java在分配對象內(nèi)存的時候，很多時候，在Eden區(qū)域是連續(xù)分配的，當(dāng)在for循環(huán)的時候，如果沒有其他線程的接入，這些對象就會被存放在一起，即使被GC到OLD區(qū)域也很有可能會放在一起，所以靠簡單對象來解決cache line后還對整個數(shù)組修改的方式貌似不靠譜，因為int 是4字節(jié)，如果在64模式下，這個大小是24字節(jié)（有4byte補(bǔ)齊），指針壓縮開啟是16byte；也就是每次cpu可以看齊3-4個對象，如何讓CPUcache了，但是又不影響系統(tǒng)的QPI，別想通過分隔對象來完成，因為GC過程內(nèi)存拷貝過程很可能會拷貝到一起，最好的辦法是補(bǔ)齊，雖然有點(diǎn)浪費(fèi)內(nèi)存，但是這是最靠譜的方法，就是將對象補(bǔ)齊到64字節(jié)，上述若未開啟指針壓縮有24byte，此時還有40個字節(jié)，只需要在對象內(nèi)部增加5個long即可。

class InputInteger {public int value;private long a1,a2,a3,a4,a5;}

呵呵，這個辦法很土，不過很管用，有些時候，Jvm編譯的時候發(fā)現(xiàn)這幾個參數(shù)啥都沒做，就直接給你干掉了，優(yōu)化無效，土辦法加土辦法就是在一個方法體里面簡單對這5個參數(shù)做一個操作（都用上），但是這個方法永遠(yuǎn)不調(diào)用它即可。

8、在CPU這個級別有些時候就未必能先做盡量先做的道理為王者了，類似獲取鎖這種操作，在AtomicIntegerFieldUpdater的操作，如果調(diào)用getAndSet(true)在單線程下你會發(fā)現(xiàn)跑得還蠻快，在多核CPU下就開始變慢，為什么上面說得很清楚了，因為getAndSet里面是修改后對比，先改了再說，QPI會很高，所以這個時候，先做get操作，再修改才是比較好的做法；還有就是獲取一次，如果獲取不到，就讓步一下，讓其他的線程去做其他的事情；

9、CPU有些時候為了解決某些CPU忙和不繁忙的問題，會有很多算法來解決，如NUMA是其中一種方案，不過不論哪種架構(gòu)都在一定場景下比較有用，對有所有場景未必有效；有隊列鎖機(jī)制來完成對CPU狀態(tài)管理，不過這又存在了cache line的問題，因為狀態(tài)都是經(jīng)常改變的，各類應(yīng)用程序的內(nèi)核為了配合CPU也會出一些算法來做，使得CPU可以更加有效的利用起來，如CLH隊列等。

有關(guān)這方面的細(xì)節(jié)會很多如用普通變量循環(huán)疊加和用volatile類型的做以及Atomic*系列的來做，完全是不一樣的；多維度數(shù)組循環(huán)，按照不同緯度向后次序來循環(huán)也是不一樣的，細(xì)節(jié)上點(diǎn)很多，明白為什么就在實(shí)際優(yōu)化過程中有靈感了；鎖的細(xì)節(jié)說太細(xì)很暈，在系統(tǒng)底層的級別，始終有一些輕量級的原子操作，不論誰說他的代碼是不需要加鎖的，最細(xì)的可以細(xì)到CPU在每個瞬間只能執(zhí)行一條指令那么簡單，多核心CPU在總線級別也會有共享區(qū)來控制一些內(nèi)容，有讀級別、寫級別、內(nèi)存級別等，在不同的場景下使得鎖的粒度盡量降低，那么系統(tǒng)的性能不言而喻，很正常的結(jié)果。秀好圖

來源：xieyu_zy

鏈接：http://blog.csdn.net/xieyuooo/article/details/7789032