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

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

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

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

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

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

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

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

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

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

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

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);}

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

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

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

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

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

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

來源：xieyu_zy

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