程式扎記: [ Java 文章收集 ] 多核平台JAVA優化

標籤

2013年9月9日 星期一

[ Java 文章收集 ] 多核平台JAVA優化

來源自 這裡
Preface:
現在多核 CPU 是主流。利用多核技術,可以有效發揮硬件的能力,提升吞吐量,對於 Java 程序,可以實現並發垃圾收集。但是 Java 利用多核技術也帶來了一些問題,主要是多線程共享內存引起了。目前內存和 CPU 之間的帶寬是一個主要瓶頸,每個核可以獨享一部分高速緩存,可以提高性能。JVM 是利用操作系統的”輕量級進程”實現線程,所以線程每操作一次共享內存,都無法在高速緩存中命中,是一次開銷較大的系統調用。所以區別於普通的優化,針對多核平台,需要進行一些特殊的優化.

線程數要大於等於核數:
如果使用多線程,只有運行的線程數比核數大,才有可能榨干 CPU 資源,否則會有若干核閑置。要注意的是,如果線程數目太多,就會佔用過多內存,導致性能不升反降。JVM 的垃圾回收也是需要線程的,所以這里的線程數包含 JVM 自己的線程.

盡量減少共享數據寫操作:
每個線程有自己的工作內存,在這個區域內,系統可以毫無顧忌的優化,如果去讀共享內存區域,性能也不會下降。但是一旦線程想寫共享內存(使用 volatile 關鍵字),就會插入很多內存屏障操作(Memory Barrier 或者 Memory Fence)指令,保証處理器不亂序執行。相比寫本地線程自有的變量,性能下降很多。處理方法是盡量減少共享數據,這樣也符合”數據耦合”的設計原則。

使用 synchronize 關鍵字:
在 Java1.5 中,synchronize 是性能低效的。因為這是一個重量級操作,需要調用操作接口,導致有可能加鎖消耗的系統時間比加鎖以外的操作還多。相比之下使用 Java 提供的 Lock 對象,性能更高一些。但是到了 Java1.6,發生了變化。synchronize 在語義上很清晰,可以進行很多優化,有適應自旋,鎖消除,鎖粗化,輕量級鎖,偏向鎖等等。導致在 Java1.6 上 synchronize 的性能並不比 Lock 差。官方也表示,他們也更支持 synchronize,在未來的版本中還有優化餘地.

使用樂觀策略:
傳統的同步並發策略是悲觀的。表現語義為:多線程操作一個對象的時候,總覺得會有兩個線程在同時操作,所以需要鎖起來。樂觀策略是,假設平時就一個線程訪問,當出現了沖突的時候,再重試。這樣更高效一些。Java 的 AtomicInteger 就是使用了這個策略!

使用線程本地變量(ThreadLocal)
使用 ThreadLocal 可以生成線程本地對象的副本,不會和其他線程共享。當該線程終止的時候,其本地變量可以全部回收。

類中 Field 的排序:
可以將一個類會頻繁訪問到的幾個 field 放在一起,這樣他們就有更多的可能性被一起加入高速緩存。同時最好把他們放在頭部。基本變量和引用變量不要交錯排放!

批量處理數組:
現在處理器可以用一條指令來處理一個數組中的多條記錄,例如可以同時向一個 byte 數組中讀或者寫 store 記錄。所以要盡量使用 System.arraycopy() 這樣的批量接口,而不是自己操作數組.

底下為 JVM 優化 的內容...
啟用大內存頁:
現在一個操作系統默認頁是4K。如果你的 heap 是 4GB,就意味著要執行 1024*1024 次分配操作。所以最好能把頁調大。這個配額設計操作系統,單改 Jvm 是不行的。Linux 上的配置有點復雜,不詳述. 在 Java1.6 中 UseLargePages 是默認開啟的,LasrgePageSzieInBytes 被設置成了4M。筆者看到一些情況下配置成了128MB,在官方的性能測試中更是配置到256MB. (可以參考 Java Support for Large Memory Pages)

啟用壓縮指針:
Java 的64的性能比32慢,原因是因為其指針由32位擴展到64位,雖然尋址空間從4GB 擴大到 256 TB,但導致性能的下降,並佔用了更多的內存。所以對指針進行壓縮。壓縮後的指針最多支持 32GB 內存,並且可以獲得 32位 JVM 的性能。在 JDK6 update 23 默認開啟了,之前的版本可以使用 -XX:+UseCompressedOops 來啟動配置。性能可以看這個評測,性能的提升是很可觀.

啟用 NUMA:
NUMA (Non-Uniform Memory Access) 是一個 CPU 的特性。SMP 架構下,CPU 的核是對稱,但是他們共享一條系統總線。所以 CPU 多了,總線就會成為瓶頸。在 NUMA 架構下,若干 CPU 組成一個組,組之間有點對點的通訊,相互獨立。啟動它可以提高性能。 NUMA 需要硬件,操作系統,JVM 同時啟用,才能啟用。Linux 可以用 numactl 來配置 numa,JVM 通過 -XX:+UseNUMA 來啟用。

激進優化特性:
在 Java1.6 中,激進優化(AggressiveOpts)是默認開啟的。激進優化是一般有一些下一個版本才會發布的優化選項。但是有可能造成不穩定。前段時間以訛傳訛的 JDK7的 Bug,就是開啟這個選項後測到的.

逃逸分析:
讓一個對象在一個方法內創建後,如果他傳遞出去,就可以稱為方法逃逸;如果傳遞到別的線程,成為線程逃逸。如果能知道一個對象沒有逃逸,就可以把它分配在棧而不是堆上,節約 GC 的時間。同時可以將這個對象拆散,直接使用其成員變量,有利於利用高速緩存。如果一個對象沒有線程逃逸,就可以取消其中一切同步操作,很大的提高性能.

但是逃逸分析是很有難度的,因為花了 cpu 去對一個對象去分析,要是他不逃逸,就無法優化,之前的分析血本無歸。所以不能使用復雜的算法,同時現在的 JVM 也沒有實現棧上分配。所以開啟之後,性能也可能下降. 可以使用 -XX:+DoEscapeAnalysis 來開啟逃逸分析。

高吞吐量 GC 配置:
對於高吞吐量,在年輕態可以使用 Parallel Scavenge,年老態可以使用 Parallel Old 垃圾收集器:
使用 -XX:+UseParallelOldGC 開啟
可以將 -XX:ParallelGCThreads 根據 CPU 的個數進行調整。可以是 CPU 數的1/2或者5/8 低延遲 GC 配置
對於低延遲的應用,在年輕態可以使用 ParNew,年老態可以使用 CMS 垃圾收集器。
可以使用 -XX:+UseConcMarkSweepGC 和 -XX:+UseParNewGC 打開。
可以將 -XX:ParallelGCThreads 根據 CPU 的個數進行調整。可以是 CPU 數的1/2或者5/8
可以調整 -XX:MaxTenuringThreshold (晉升年老代年齡)調高,默認是15.這樣可以減少年老代 GC 的壓力
可以 -XX:TargetSurvivorRatio,調整 Survivor 的佔用比率。默認50%.調高可以提供 Survivor 區的利用率
可以調整 -XX:SurvivorRatio,調整 Eden 和 Survivor 的比重。默認是8。這個比重越小,Survivor 越大,對象可以在年輕態呆更多時間。

Supplement:
Java 理論與實踐: 正確使用Volatile 變量
Java 語言中的 volatile 變量可以被看作是一種 “程度較輕的synchronized ”;與 synchronized塊 相比,volatile 變量所需的編碼較少,並且運行時開銷也較少,但是它所能實現的功能也僅是 synchronized 的一部分。本文介紹了幾種有效使用volatile變量的模式,並強調了幾種不適合使用volatile變量的情形...

理解 ThreadLocal
[ JVM 應用 ] 垃圾收集器與記憶體分配策略 - Part2


沒有留言:

張貼留言

網誌存檔

關於我自己

我的相片
Where there is a will, there is a way!