jvm參考配置 · jvm學習筆記

### JVM參數設置 | 參數 | 內容 | | :--- | :--- | | -Xms | 初始堆大小。如：-Xms256m；默認物理內存 1/64 | | -Xmx | 最大堆大小。如：-Xmx512m；默認物理內存 1/4 | | -Xmn:\[g\|m\|k\] | 新生代大小。新生代 = Eden + 2 個 Survivor 空間。實際可用空間為 = Eden + 1 個 Survivor，即 90%；整個JVM內存大小=年輕代大小 + 年老代大小 + 持久代大小。持久代一般固定大小為64m，所以增大年輕代后，將會減小年老代大小；如果Xms和Xmx沒有設置為同一個值時，堆空間擴展或收縮時，新生代大小是不會隨著調整的，是固定的，只有Xms和Xmx是同一個值得時候，才使用Xmn選項 | | -Xss | 設置每個線程的堆棧大小；JDK1.5+ 每個線程堆棧大小為 1M，一般來說如果棧不是很深的話， 1M 是絕對夠用了的。 | | -XX:NewRatio | 新生代與老年代的比例，如 –XX:NewRatio=2，則新生代占整個堆空間的1/3，老年代占2/3 | | -XX:SurvivorRatio | 新生代中 Eden$8$ 與 Survivor$1+1$ 的比值。默認值為 8。即 Eden 占新生代空間的 8/10，另外兩個 Survivor 各占 1/10 | | -XX:PermSize | 永久代$方法區$的初始大小 | | -XX:MaxPermSize | 永久代$方法區$的最大值 | | -XX:+PrintGCDetails | 打印 GC 信息 | | -XX:+HeapDumpOnOutOfMemoryError | 讓虛擬機在發生內存溢出時 Dump 出當前的內存堆轉儲快照，以便分析用 | | -XX:NewSize=\[g\|m\|k\] | 設置新生代最小空間大小 | | -XX:MaxNewSize | 設置新生代最大空間大小 | | -XX:MetaspaceSize | class metadata的初始空間配額，以bytes為單位，達到該值就會觸發垃圾收集進行類型卸載，同時GC會對該值進行調整 | | XX:MaxMetaspaceSize | 可以為class metadata分配的最大空間。默認是沒有限制的 | | MinHeapFreeRatio | GC后如果發現空閑堆內存占到整個預估堆內存的N%$百分比$, 則放大堆內存的預估最大值 | | MaxHeapFreeRatio | GC后如果發現空閑堆內存占到整個預估堆內存的N%$百分比$，則收縮堆內存的預估最大值, 預估堆內存是堆大小動態調控的重要選項之一. 堆內存預估最大值一定小于或等于固定最大值$-Xmx指定的數值$. 前者會根據使用情況動態調大或縮小, 以提高GC回收的效率 | _注意：java8去掉了-XX:PermSize和-XX:MaxPermSize，新增了-XX:MetaspaceSize和-XX:MaxMetaspaceSize_ 虛擬機會根據堆的空閑情況動態調整推大小，空余大于 70%，會減少到 -Xms，空余小于 40%，會增大到 -Xmx；服務器如果配置 -Xms = -Xmx，則可以避免堆自動擴展； Xmn設置新生代大小，等同于同時設置NewSize和MaxNewSize，如-Xmn128m等同于：-XX:NewSize=128m -XX:MaxNewSize=128m； ### Xmx與Xms 一般實際生產應用中，Xms與Xmx設置為同一個值，避免JVM GC頻繁縮容擴容； ### 參考配置CMS ``` JAVA_OPTS="-server -Xss256k $JAVA_OPTS" JAVA_OPTS="${JAVA_OPTS} -XX:SurvivorRatio=10" JAVA_OPTS="${JAVA_OPTS} -XX:+UseConcMarkSweepGC -XX:CMSMaxAbortablePrecleanTime=5000 -XX:+CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=80" JAVA_OPTS="${JAVA_OPTS} -XX:+UseCMSInitiatingOccupancyOnly" JAVA_OPTS="${JAVA_OPTS} -XX:+DisableExplicitGC" JAVA_OPTS="${JAVA_OPTS} -verbose:gc -Xloggc:/root/logs/app-gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps" JAVA_OPTS="${JAVA_OPTS} -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/root/logs/app-java.hprof" JAVA_OPTS="${JAVA_OPTS} -Djava.awt.headless=true" JAVA_OPTS="${JAVA_OPTS} -Dsun.net.client.defaultConnectTimeout=10000" JAVA_OPTS="${JAVA_OPTS} -Dsun.net.client.defaultReadTimeout=30000" java -Djava.security.egd=file:/dev/./urandom $JAVA_OPTS -jar ./app.jar $* ``` ### 其它 * -Xint 解釋執行不對代碼進行編譯，這種模式拋棄了 JIT 可能帶來的性能優勢，畢竟解釋器（interpreter）是逐條讀入，逐條解釋運行的； * -Xcomp 關閉解釋器，不要進行解釋執行，或者叫作最大優化級別；“-Xcomp”會導致 JVM 啟動變慢非常多，同時有些JIT 編譯器優化方式，比如分支預測，如果不進行 profiling，往往并不能進行有效優化