?JVM
內存參數調優
我們前面所提到的堆內存(heap)是由Java虛擬機控制管理的,因此,這些參數對JVM而言都有一個默認值,但在某些情況下這些參數的默認值并不是最優的,這就需要我們通過調整這些參數的值來提高JVM的性能,最終提高應用的性能指標。
在實際的應用開發中,如果應用所使用的系統內存較大,經常會引發內存溢出的錯誤:
…
java.lang.OutOfMemoryError <<no stack trace available>>
java.lang.OutOfMemoryError <<no stack trace available>>
? ? Exception in thread "main"
…
這可能是因為應用要使用的堆內存(heap)超過了JVM所管理內存范圍,如果我們適當追加內存值有時就可以避免這種致命錯誤的出現。
在WINDOWS系統上你可以通過參數-verbosegc查看JVM回收內存的信息,在HP UNIX系統上你可以通過-Xverbosegc:file=/tmp/gc$$.out參數將信息重定向到一個文件中。然后查看相應的信息,例如下面的這個類。
public class A {
??? ???public static void main(String args[]) {
??? ???? for (int i =0 ;i < 100000;++i) {
??????????? ???A a = new A();
??? ???? }
??? ???? System.out.println("this is a GC test");
??? ???}
}
在類A的main方法中創建了100 000個A對象,然后我們看一下JVM回收內存的情況,編譯并執行這個類:
>java -verbosegc A
[GC 512K->91K(1984K), 0.0027537 secs]
this is a ?GC test
從輸出信息中可以看出總共有1984KB的內存被回收,耗時0.002 753 7秒。現在我們將類A添加一行清除對象引用的代碼:
public class A {
??? ???public static void main(String args[]) {
??? ???? for (int i =0 ;i < 100000;++i) {
???????????? ??A a = new A();
? ?????????????a = null;
??? ???? }
??? ???? System.out.println("this is a GC test");
??? ???}
}
編譯并執行這個類:
>java -verbosegc A
[GC 512K->91K(1 984K), 0.0 027 450 secs]
this is a ?GC test
我們 看到被回收內存的數量并沒有變化,但是回收所需要的時間卻變成了0.002 745 0秒,后者比前者節省了0.000 008 7秒,千萬不要小看這0.000 008 7秒,當你的應用足夠復雜時這個時間就會成指數級增長,看來我們主動清除對象引用的方法,確實可以加速JVM對垃圾內存的回收。
如果再在類A中加入一行強制系統內存回收的代碼,結果又會怎樣呢?如下所示:
public class A {
?? ?public static void main(String args[]) {
??? ???? for (int i =0 ;i < 100000;++i) {
????????? ?????A a = new A();
??? ???????????a = null;
??? ???? }
??? ???? System.gc();
??? ???? System.out.println("this is a GC test");
??? }
}
編譯并執行這個類:
>java -verbosegc A
[GC 512K->91K(1984K), 0.0 027 272 secs]
[Full GC 487K->91K(1984K), 0.0 070 730 secs]
this is a ?GC test
系統 這次做了兩次內存回收,第一次是程序中強制系統內存回收的代碼System.gc()導致的內存回收,而后者是系統最終的內存回收操作,我們看到強制內存回收耗時不長,可是卻導致了系統最終垃圾回收的時間加長了很多,因此我們在采用強制系統垃圾回收(通過顯式調用方法System.gc())的辦法來回收系統垃圾內存的辦法,還是存在一些弊端的,應盡量少用,或者說只在必要的時候應用。
上面我們提到的內存回收操作就是回收JVM所 管理的堆內存(heap)。當系統連續申請內存并且超過JVM所管理的堆內存(heap)的最大值時,就會產生系統內存溢出的致命異常,下面我們來看一下 怎樣通過設置JVM的內存參數來優化JVM對內存的管理,避免內存溢出異常的發生。表2-1所示的就是與JVM內存相關的參數及其說明。
?
?
?
?
?
?
表2-1? 與JVM內存相關的參數及其說明
JVM
堆內存(heap)設置選項
|
參數格式
|
說??? 明
|
設置新對象生產堆內存(Setting the Newgeneration heap size)
|
-XX:NewSize
|
通過這個選項可以設置Java新對象生產堆內存。在通常情況下這個選項的數值為1 024的整數倍并且大于1MB。這個值的取值規則為,一般情況下這個值-XX:NewSize是最大堆內存(maximum heap size)的四分之一。增加這個選項值的大小是為了增大較大數量的短生命周期對象
增加Java新對象生產堆內存相當于增加了處理器的數目。并且可以并行地分配內存,但是請注意內存的垃圾回收卻是不可以并行處理的
|
續表?
JVM
堆內存(heap)設置選項
|
參數格式
|
說??? 明
|
設置最大新對象生產堆內存(Setting the maximum New generation heap size)
|
-XX:MaxNewSize
|
通過這個選項可以設置最大Java新對象生產堆內存。通常情況下這個選項的數值為1?024的整數倍并且大于1MB
其功用與上面的設置新對象生產堆內存-XX:NewSize相同
|
設置新對象生產堆內存的比例(Setting New heap size ratios)
|
-XX:SurvivorRatio
|
新對象生產區域通常情況下被分為3個子區域:伊甸園,與兩個殘存對象空間,這兩個空間的大小是相同的。通過用-XX:SurvivorRatio=X選項配置伊甸園與殘存對象空間(Eden/survivor)的大小的比例。你可以試著將這個值設置為8,然后監控、觀察垃圾回收的工作情況
|
設置堆內存池的最小值
(Setting minimum heap size)
|
-Xms
|
通過這個選項可以要求系統為堆內存池分配內存空間的最小值。通常情況下這個選項的數值為1?024的整數倍并且大于1MB。這個值的取值規則為,一般情況下這個值(-Xms)與最大堆內存相同,以降低垃圾回收的頻度
|
設置堆內存池的最大值(Setting maximum heap size)
|
-Xmx
|
通過這個選項可以要求系統為堆內存池分配內存空間的最大值。通常情況下這個選項的數值為1?024的整數倍并且大于1 MB
一般情況下這個值(-Xmx)與最小堆內存(minimum heap size –Xms)相同,以降低垃圾回收的頻度
|
取消垃圾回收
|
-Xnoclassgc
|
這個選項用來取消系統對特定類的垃圾回收。它可以防止當這個類的所有引用丟失之后,這個類仍被引用時不會再一次被重新裝載,因此這個選項將增大系統堆內存的空間
|
設置棧內存的大小
|
-Xss
|
這個選項用來控制本地線程棧的大小,當這個選項被設置的較大(>2MB)時將會在很大程度上降低系統的性能。因此在設置這個值時應該格外小心,調整后要注意觀察系統的性能,不斷調整以期達到最優
|
根據表2-1中所描述的參數意義,我們可以在啟動應用時為JVM設置相應的參數值以提高系統的性能,例如下面的例子:
java -XX:NewSize=128m -XX:MaxNewSize=128m -XX:SurvivorRatio=8? -Xms512m
-Xmx512m MyApplication
類文件(.class)的大小
由Java源文件.java文件編譯成JVM 可解釋執行的Java字節文件.class。因所采用的編譯方式的不同而大小也不同。通常.class文件的大小也存在是否占用較大內存的問題。通過降 低.class文件的大小,不但可以降低系統內存的開銷,還可以節省網絡開銷,雖然這部分內容與JVM內存管理聯系不大,但是我覺得還是有必要提一下,因 為這在你開發Applet應用時會有幫助(注:在本書后續的章節中,將會對如何減小Java類尺寸的技術話題做更為深入的探討)。因為一般來說, Applet應用都是靠網絡分布式傳輸由客戶端瀏覽器裝載運行的,如果類文件較大,無疑將會增大網絡開銷,降低傳輸速度無法滿足用戶的需求,并且如果類文件較大,無疑也會消耗客戶端內存資源。我們可以通過在Java編譯器javac中添加相應的參數,來縮小類文件的大小,解決上面的問題。
通常有三種編譯方式會影響類文件的大小。
(1)默認編譯方式:? javac ??A.java。
(2)調試編譯方式:? javac ?–g A.java。
(3)代碼編譯方式:? javac ?–g:none A.java。
例如如下所示的簡單的類A:
public class A {
? ?????public static void main(String args[]) {
? ????????for (int i =0 ;i < 100000;++i) {
?? ???????A a = new A();
?? ???????}
?? ????}
}
通過上面這三種方式編譯后的類文件的大小分別為:
默認編譯方式:291字節。
調試編譯方式:422字節。
代碼編譯方式:207字節。
采用三種不同的方式,編譯產生的類文件的大小差異非常大,這是什么原因導致的呢?原來在于.class文件中包含多個不同的部分或屬性。
代碼(Code)屬性包含實際的方法字節碼。 源文件信息(SourceFile Information)包含用于生成.class的源文件名稱。代碼行序號表(LineNumberTable)用來映射源文件中的代碼行序號與字節碼 文件中的序號偏移。本地變量表(LocalVariableTable)用來映射本地變量與棧楨的偏移。
&
注意? 如果你想了解字節碼文件.class的文件結構詳細信息,請參考相關的技術資料,這里就不詳細講解了。
正是由于上面這三種編譯方式生成的類文件所包含的信息不同,才導致了類文件的大小差異較大,其包含的信息分別如下所示。
默認編譯方式:代碼(Code)、源文件信息(SourceFile Information)、代碼行序號表(LineNumberTable)。
調試編譯方式:代碼(Code)、源文件信息(SourceFile Information)、代碼行序號表(LineNumberTable)、本地變量表(LocalVariableTable)。
代碼編譯方式:代碼(Code)。
這就是三種編譯方式產生類文件大小不同的根本原因。而這三種編譯方式在程序開發的不同階段卻都起著非常重要的作用,例如,調試編譯方式在程序的調試開發過程中應采用,以獲取更為詳細的調試信息。因此具體應用上面的三種編譯方式中的哪一種,應該適時而定。
?