現(xiàn)在多核CPU是主流。利用多核技術(shù)，可以有效發(fā)揮硬件的能力，提升吞吐量，對(duì)于Java程序，可以實(shí)現(xiàn)并發(fā)垃圾收集。但是Java利用多核技術(shù)也帶來了一些問題，主要是多線程共享內(nèi)存引起了。目前內(nèi)存和CPU之間的帶寬是一個(gè)主要瓶頸，每個(gè)核可以獨(dú)享一部分高速緩存，可以提高性能。JVM是利用操作系統(tǒng)的”輕量級(jí)進(jìn)程”實(shí)現(xiàn)線程，所以線程每操作一次共享內(nèi)存，都無法在高速緩存中命中，是一次開銷較大的系統(tǒng)調(diào)用。所以區(qū)別于普通的優(yōu)化，針對(duì)多核平臺(tái)，需要進(jìn)行一些特殊的優(yōu)化。
代碼優(yōu)化
線程數(shù)要大于等于核數(shù)
如果使用多線程，只有運(yùn)行的線程數(shù)比核數(shù)大，才有可能榨干CPU資源，否則會(huì)有若干核閑置。要注意的是，如果線程數(shù)目太多，就會(huì)占用過多內(nèi)存，導(dǎo)致性能不升反降。JVM的垃圾回收也是需要線程的，所以這里的線程數(shù)包含JVM自己的線程
盡量減少共享數(shù)據(jù)寫操作
每個(gè)線程有自己的工作內(nèi)存，在這個(gè)區(qū)域內(nèi)，系統(tǒng)可以毫無顧忌的優(yōu)化，如果去讀共享內(nèi)存區(qū)域，性能也不會(huì)下降。但是一旦線程想寫共享內(nèi)存(使用volatile關(guān)鍵字)，就會(huì)插入很多內(nèi)存屏障操作(Memory Barrier或者M(jìn)emory Fence)指令，保證處理器不亂序執(zhí)行。相比寫本地線程自有的變量，性能下降很多。處理方法是盡量減少共享數(shù)據(jù)，這樣也符合”數(shù)據(jù)耦合”的設(shè)計(jì)原則。
使用synchronize關(guān)鍵字
在Java1.5中，synchronize是性能低效的。因?yàn)檫@是一個(gè)重量級(jí)操作，需要調(diào)用操作接口，導(dǎo)致有可能加鎖消耗的系統(tǒng)時(shí)間比加鎖以外的操作還多。相比之下使用Java提供的Lock對(duì)象，性能更高一些。但是到了Java1.6，發(fā)生了變化。synchronize在語義上很清晰，可以進(jìn)行很多優(yōu)化，有適應(yīng)自旋，鎖消除，鎖粗化，輕量級(jí)鎖，偏向鎖等等。導(dǎo)致在Java1.6上synchronize的性能并不比Lock差。官方也表示，他們也更支持synchronize，在未來的版本中還有優(yōu)化余地。
使用樂觀策略
傳統(tǒng)的同步并發(fā)策略是悲觀的。表現(xiàn)語義為：多線程操作一個(gè)對(duì)象的時(shí)候，總覺得會(huì)有兩個(gè)線程在同時(shí)操作，所以需要鎖起來。樂觀策略是，假設(shè)平時(shí)就一個(gè)線程訪問，當(dāng)出現(xiàn)了沖突的時(shí)候，再重試。這樣更高效一些。Java的AtomicInteger就是使用了這個(gè)策略。
使用線程本地變量(ThreadLocal)
使用ThreadLocal可以生成線程本地對(duì)象的副本，不會(huì)和其他線程共享。當(dāng)該線程終止的時(shí)候，其本地變量可以全部回收。
類中Field的排序
可以將一個(gè)類會(huì)頻繁訪問到的幾個(gè)field放在一起，這樣他們就有更多的可能性被一起加入高速緩存。同時(shí)最好把他們放在頭部。基本變量和引用變量不要交錯(cuò)排放。
批量處理數(shù)組
現(xiàn)在處理器可以用一條指令來處理一個(gè)數(shù)組中的多條記錄，例如可以同時(shí)向一個(gè)byte數(shù)組中讀或者寫store記錄。所以要盡量使用System.arraycopy()這樣的批量接口，而不是自己操作數(shù)組。
JVM優(yōu)化
啟用大內(nèi)存頁(yè)
現(xiàn)在一個(gè)操作系統(tǒng)默認(rèn)頁(yè)是4K。如果你的heap是4GB，就意味著要執(zhí)行1024*1024次分配操作。所以最好能把頁(yè)調(diào)大。這個(gè)配額設(shè)計(jì)操作系統(tǒng)，單改Jvm是不行的。Linux上的配置有點(diǎn)復(fù)雜，不詳述。
在Java1.6中UseLargePages是默認(rèn)開啟的，LasrgePageSzieInBytes被設(shè)置成了4M。筆者看到一些情況下配置成了128MB，在官方的性能測(cè)試中更是配置到256MB。
啟用壓縮指針
Java的64的性能比32慢，原因是因?yàn)槠渲羔樣?2位擴(kuò)展到64位，雖然尋址空間從4GB擴(kuò)大到256 TB，但導(dǎo)致性能的下降，并占用了更多的內(nèi)存。所以對(duì)指針進(jìn)行壓縮。壓縮后的指針最多支持32GB內(nèi)存，并且可以獲得32位JVM的性能。
在JDK6 update 23默認(rèn)開啟了，之前的版本可以使用-XX:+UseCompressedOops來啟動(dòng)配置。
性能可以看這個(gè)評(píng)測(cè)，性能的提升是很可觀。
啟用NUMA
numa是一個(gè)CPU的特性。SMP架構(gòu)下，CPU的核是對(duì)稱，但是他們共享一條系統(tǒng)總線。所以CPU多了，總線就會(huì)成為瓶頸。在NUMA架構(gòu)下，若干CPU組成一個(gè)組，組之間有點(diǎn)對(duì)點(diǎn)的通訊，相互獨(dú)立。啟動(dòng)它可以提高性能。
NUMA需要硬件，操作系統(tǒng)，JVM同時(shí)啟用，才能啟用。Linux可以用numactl來配置numa,JVM通過-XX:+UseNUMA來啟用。
激進(jìn)優(yōu)化特性
在Java1.6中，激進(jìn)優(yōu)化(AggressiveOpts)是默認(rèn)開啟的。激進(jìn)優(yōu)化是一般有一些下一個(gè)版本才會(huì)發(fā)布的優(yōu)化選項(xiàng)。但是有可能造成不穩(wěn)定。前段時(shí)間以訛傳訛的JDK7的Bug，就是開啟這個(gè)選項(xiàng)后測(cè)到的。
逃逸分析
讓一個(gè)對(duì)象在一個(gè)方法內(nèi)創(chuàng)建后，如果他傳遞出去，就可以稱為方法逃逸；如果傳遞到別的線程，成為線程逃逸。如果能知道一個(gè)對(duì)象沒有逃逸，就可以把它分配在棧而不是堆上，節(jié)約GC的時(shí)間。同時(shí)可以將這個(gè)對(duì)象拆散，直接使用其成員變量，有利于利用高速緩存。如果一個(gè)對(duì)象沒有線程逃逸，就可以取消其中一切同步操作，很大的提高性能。
但是逃逸分析是很有難度的，因?yàn)榛薱pu去對(duì)一個(gè)對(duì)象去分析，要是他不逃逸，就無法優(yōu)化，之前的分析血本無歸。所以不能使用復(fù)雜的算法，同時(shí)現(xiàn)在的JVM也沒有實(shí)現(xiàn)棧上分配。所以開啟之后，性能也可能下降。
可以使用-XX:+DoEscapeAnalysis來開啟逃逸分析。
高吞吐量GC配置
對(duì)于高吞吐量，在年輕態(tài)可以使用Parallel Scavenge,年老態(tài)可以使用Parallel Old垃圾收集器。
使用-XX:+UseParallelOldGC開啟
可以將-XX:ParallelGCThreads根據(jù)CPU的個(gè)數(shù)進(jìn)行調(diào)整?？梢允荂PU數(shù)的1/2或者5/8
低延遲GC配置
對(duì)于低延遲的應(yīng)用，在年輕態(tài)可以使用ParNew,年老態(tài)可以使用CMS垃圾收集器。
可以使用-XX:+UseConcMarkSweepGC和-XX:+UseParNewGC打開。
可以將-XX:ParallelGCThreads根據(jù)CPU的個(gè)數(shù)進(jìn)行調(diào)整?？梢允荂PU數(shù)的1/2或者5/8
可以調(diào)整-XX:MaxTenuringThreshold(晉升年老代年齡)調(diào)高，默認(rèn)是15.這樣可以減少年老代GC的壓力
可以-XX:TargetSurvivorRatio，調(diào)整Survivor的占用比率。默認(rèn)50%.調(diào)高可以提供Survivor區(qū)的利用率
可以調(diào)整-XX:SurvivorRatio,調(diào)整Eden和Survivor的比重。默認(rèn)是8。這個(gè)比重越小，Survivor越大，對(duì)象可以在年輕態(tài)呆更多時(shí)間。
聯(lián)系客服
