本文目錄一覽:
JVM調優常用參數配置
說明:
1、一般初始堆和最大堆設置一樣,因為:現在內存不是什麼稀缺的資源,但是如果不一樣,從初始堆到最大堆的過程會有一定的性能開銷,所以一般設置為初始堆和最大堆一樣。64位系統理論上可以設置為無限大,但是一般設置為 4G ,因為如果再大,JVM進行垃圾回收出現的暫停時間會比較長,這樣全GC過長,影響JVM對外提供服務,所以不能太大。一般設置為4G。
2、-XX:NewRaio和-XX:SurvivorRatio這兩個參數,都是設置年輕代和年老代的大小的,設置一個即可,第一是設置年輕代的大小,第二個是設置比值,理論上設置一個既可以滿足需求
打印GC回收的過程日誌信息
以下配置主要針對分代收集回收算法而言
年輕代的設置很關鍵
JVM中最大堆大小有三方面限制:相關操作系統的數據模型(32bit還是64bit)限制:系統的可用虛擬內存限制;系統的可用物理內存限制。32位系統下,一般限制在1.5G-2G;64位操作系統對內存沒有限制。在Windows Server 2003系統,3.5G物理內存,JDK5.0下測試,最大設置為1478m。
典型設置:
JVM給了三種選擇:串行收集器,並行收集器,並發收集器,但是串行收集器只適用於小數據量的情況,一般不考慮使用了,所以這裡只針對並行收集器和並發收集器。默認情況下,JDK5.0以前是使用的串行收集器,如果想使用其他收集器需要在啟動時加入相應的參數, JDK5.0以後,JVM會根據系統當前的配置進行判斷
吞吐量優先的並行收集器
並行收集器主要以到達一定的吞吐量為目標,適用於後台處理
響應時間優先的並發收集器
並發收集器主要是保證系統的響應時間,減少垃圾收集時的停頓時間。適用於應用服務器、電信領域等。
6.1年輕代大小選擇
響應時間優先的應用:儘可能設置大,直到接近系統的最低響應時間限制(根據實際情況選擇)。在此種情況下,年輕代收集發生的頻率也是最小的。同時減少到達年老代的對象。
吞吐量優先的應用:儘可能的設置大,可能到達Gbit的成都,因為對響應時間沒有要求,垃圾收集可以並行進行,一般適合8核CPU以上應用。
6.2年老代大小選擇
響應時間優先的應用:年老代使用並發收集器,所以其大小需要小心設置,一般要考慮並發會話率和會話持續時間等一些參數。如果堆設置小了,可能會造成內存碎片、高回收頻率以及應用暫停而使用傳統的標記清除方式;如果堆大了,則需要較長的收集時間。最優化的方案,一般需要參考一下數據獲得:
1、並發垃圾收集信息
2、持久代並發收集次數
3、傳統GC信息
4、花在年輕代和年老代回收上的時間比例減少年輕代和年老代花費的時間,一般會提高應用的效率
6.3吞吐量優先的應用
一般吞吐量優先的應用都有一個很大的年輕代和一個較小的年老代。原因是,這樣可以儘可能回收掉大部分短期對象,減少中期對象,而年老代盡存放長期存活的對象
6.4較小堆引起的碎片問題
因為年老代的並發收集器使用標記、清除算法,所以不會對堆進行壓縮。當收集器回收時,他會把相鄰的空間進行合併,這樣可以分配給較大的對象。但是當堆空間較小時,運行一段時間以後,就會出現「碎片」,如果並發收集器找不到足夠的空間,那麼並發收集器將會停止,然後使用傳統的標記、清除方式進行回收。如果出現「碎片」,可能需要進行如下配置:
Jconsole,jProfile,VisualVM
Jconsole:jdk自帶, 功能簡單,但是可以再系統有一定負荷的情況下使用,對垃圾回收算法有很詳細的跟蹤。
JProfiler:商業軟件,需要付費,但是功能強大
VisualVM:JDK自帶,功能強大,與Jprofiler類似,推薦
觀察內存釋放情況、集合類檢查,對象樹
上面這些調優工具都提供了強大的功能,但是總的來說一般分為以下幾類功能:
一般就是根據垃圾回收前後情況對比,同時根據對象引用情況( 常見的集合對象引用 )分析,基本都可以找到泄漏點。
持久代沾滿處理:
1、-XX:MaxPermSize=16m
2、換JDK比如:JRocket
系統內存被沾滿:
一般是因為沒有足夠的資源產生線程造成的,系統創建線程時,除了要在Java堆中分配內存外,操作系統本身也需要分配資源來創建線程。因此,當線程數量大的一定程度以後,堆中或許還有空間,但是操作系統分配不出資源來了,出現異常。
分配給Java虛擬機的內存越多,系統剩餘的資源就越少,因此,當系統內存固定時,分配給Java虛擬機的內存越多,那麼,系統總共能夠產生的線程也就越少,兩者成反比。同事,可以通過修改-Xss來減少分配給單個線程的空間,也可以增加系統總共生產的線程數。
java程序內存問題的診斷方法:
查看jmap的命令參數,幫助查看堆信息
jvm優化.有哪些jvm參數?用過哪些jvm調優工具
JVM是最好的軟件工程之一,它為Java提供了堅實的基礎,許多流行語言如Kotlin、Scala、Clojure、Groovy都使用JVM作為運行基礎。一個專業的Java工程師必須要了解並掌握JVM,接下來就給大家分享Java基礎知識中JVM調優相關知識點。
杭州Java基礎知識學習之JVM調優講解
JVM常見的調優參數包括:
-Xmx:指定java程序的最大堆內存, 使用java -Xmx5000M -version判斷當前系統能分配的最大堆內存;
-Xms:指定最小堆內存, 通常設置成跟最大堆內存一樣,減少GC;
-Xmn:設置年輕代大小。整個堆大小=年輕代大小+年老代大小。所以增大年輕代後,將會減小年老代大小。此值對系統性能影響較大,Sun官方推薦配置為整個堆的3/8;
-Xss:指定線程的最大棧空間, 此參數決定了java函數調用的深度, 值越大調用深度越深, 若值太小則容易出棧溢出錯誤(StackOverflowError);
-XX:PermSize:指定方法區(永久區)的初始值,默認是物理內存的1/64,在Java8永久區移除, 代之的是元數據區,由-XX:MetaspaceSize指定;
-XX:MaxPermSize:指定方法區的最大值, 默認是物理內存的1/4,在java8中由-XX:MaxMetaspaceSize指定元數據區的大小;
-XX:NewRatio=n:年老代與年輕代的比值,-XX:NewRatio=2, 表示年老代與年輕代的比值為2:1;
-XX:SurvivorRatio=n:Eden區與Survivor區的大小比值,-XX:SurvivorRatio=8表示Eden區與Survivor區的大小比值是8:1:1,因為Survivor區有兩個(from, to)。
JVM實質上分為三大塊,年輕代(YoungGen),年老代(Old Memory),及持久代(Perm,在Java8中被取消)。
年輕代大小選擇
響應時間優先的應用:儘可能設大,直到接近系統的最低響應時間限制(根據實際情況選擇)。在此種情況下,年輕代收集發生的頻率也是最小的。同時,減少到達年老代的對象。
吞吐量優先的應用:儘可能的設置大,可能到達Gbit的程度。因為對響應時間沒有要求,垃圾收集可以並行進行,一般適合8CPU以上的應用。
年老代大小選擇
響應時間優先的應用:年老代使用並發收集器,所以其大小需要小心設置,一般要考慮並發會話率和會話持續時間等一些參數。如果堆設置小了,可以會造成內存碎片、高回收頻率以及應用暫停而使用傳統的標記清除方式;如果堆大了,則需要較長的收集時間。最優化的方案,一般需要參考以下數據獲得:並發垃圾收集信息、持久代並發收集次數、傳統GC信息、花在年輕代和年老代回收上的時間比例。
減少年輕代和年老代花費的時間,一般會提高應用的效率。
吞吐量優先的應用:一般吞吐量優先的應用都有一個很大的年輕代和一個較小的年老代。原因是,這樣可以儘可能回收掉大部分短期對象,減少中期的對象,而年老代盡存放長期存活對象。
較小堆引起的碎片問題
因為年老代的並發收集器使用標記、清除算法,所以不會對堆進行壓縮。當收集器回收時,他會把相鄰的空間進行合併,這樣可以分配給較大的對象。但是,當堆空間較小時,運行一段時間以後,就會出現「碎片」,如果並發收集器找不到足夠的空間,那麼並發收集器將會停止,然後使用傳統的標記、清除方式進行回收。如果出現「碎片」,可能需要進行如下配置:
-XX:+UseCMSCompactAtFullCollection:使用並發收集器時,開啟對年老代的壓縮。
-XX:CMSFullGCsBeforeCompaction=0:上面配置開啟的情況下,這裡設置多少次Full GC後,對年老代進行壓縮。
北大青鳥java培訓:簡單的Java性能調優技巧?
大多數JAVA開發人員理所當然地以為性能優化很複雜,需要大量的經驗和知識。
好吧,不能說這是完全錯誤的。
優化應用程序以獲得最佳性能不是一件容易的事情。
但是,這並不意味着如果你不具備這些知識,就不能做任何事情。
這裡有一些易於遵循的調優方式,貴陽java培訓建議可以做個參考! 大部分建議是針對Java的。
但也有若干建議是與語言無關的,可以應用於所有應用程序和編程語言。
在討論專門針對Java的性能調優技巧之前,讓我們先來看看通用技巧。
1.在你知道必要之前不要優化 這可能是最重要的性能調整技巧之一。
你應該遵循常見的最佳實踐做法並嘗試高效地實現用例。
但是,這並不意味着在你證明必要之前,你應該更換任何標準庫或構建複雜的優化。
在大多數情況下,過早優化不但會佔用大量時間,而且會使代碼變得難以閱讀和維護。
更糟糕的是,這些優化通常不會帶來任何好處,因為你花費大量時間來優化的是應用程序的非關鍵部分。
那麼,你如何證明你需要優化一些東西呢? 首先,你需要定義應用程序代碼的速度得多快,例如,為所有API調用指定最大響應時間,或者指定在特定時間範圍內要導入的記錄數量。
在完成這些之後,你就可以測量應用程序的哪些部分太慢需要改進。
然後,接着看第二個技巧。
2.使用分析器查找真正的瓶頸 在你遵循第一個建議並確定了應用程序的某些部分需要改進後,那麼從哪裡開始呢? 你可以用兩種方法來解決問題: ·查看你的代碼,並從看起來可疑或者你覺得可能會產生問題的部分開始。
·或者使用分析器並獲取有關代碼每個部分的行為和性能的詳細信息。
希望不需要我解釋為什麼應該始終遵循第二種方法的原因。
很明顯,基於分析器的方法可以讓你更好地理解代碼的性能影響,並使你能夠專註於最關鍵的部分。
如果你曾使用過分析器,那麼你一定記得曾經你是多麼驚訝於一下就找到了代碼的哪些部分產生了性能問題。
老實說,我第一次的猜測不止一次地導致我走錯了方向。
3.為整個應用程序創建性能測試套件 這是另一個通用技巧,可以幫助你避免在將性能改進部署到生產後經常會發生的許多意外問題。
你應該總是定義一個測試整個應用程序的性能測試套件,並在性能改進之前和之後運行它。
這些額外的測試運行將幫助你識別更改的功能和性能副作用,並確保不會導致弊大於利的更新。
如果你工作於被應用程序若干不同部分使用的組件,如數據庫或緩存,那麼這一點就尤其重要。
java 編譯優化問題
java編譯的結果是位元組碼而不是二進制,所以在運行時vm的優化才是重要的,包括VM的回收策略、分配給VM內存的大小都能在一定程度上影響性能。Sun的VM支持熱點編譯,對高頻執行的代碼段翻譯的2進制會進行緩存,這也是VM的一種優化。
IBM JVM處理數學運算速度最快,BEA JVM處理大量線程和網絡socket性能最好,而Sun JVM處理通常的商業邏輯性能最好。不過Hotspot的Server mode被報告有穩定性的問題。
Java 的最大優勢不是體現在執行速度上,所以對Compiler的要求並不如c++那樣高,代碼級的優化還需要程序員本身的功底。
貼個java的運行參數:
Usage: java [-options] class [args…]
(to execute a class)
or java [-options] -jar jarfile [args…]
(to execute a jar file)
where options include:
-client to select the “client” VM
-server to select the “server” VM
-hotspot is a synonym for the “client” VM [deprecated]
The default VM is client.
-cp class search path of directories and zip/jar files
-classpath class search path of directories and zip/jar files
A ; separated list of directories, JAR archives,
and ZIP archives to search for class files.
-Dname=value
set a system property
-verbose[:class|gc|jni]
enable verbose output
-version print product version and exit
-version:value
require the specified version to run
-showversion print product version and continue
-jre-restrict-search | -jre-no-restrict-search
include/exclude user private JREs in the version search
-? -help print this help message
-X print help on non-standard options
-ea[:packagename…|:classname]
-enableassertions[:packagename…|:classname]
enable assertions
-da[:packagename…|:classname]
-disableassertions[:packagename…|:classname]
disable assertions
-esa | -enablesystemassertions
enable system assertions
-dsa | -disablesystemassertions
disable system assertions
-agentlib:libname[=options]
load native agent library libname, e.g. -agentlib:hprof
see also, -agentlib:jdwp=help and -agentlib:hprof=help
-agentpath:pathname[=options]
load native agent library by full pathname
-javaagent:jarpath[=options]
load Java programming language agent, see
java.lang.instrument
-Xmixed mixed mode execution (default)
-Xint interpreted mode execution only
-Xbootclasspath:directories and zip/jar files separated by ;
set search path for bootstrap classes and resources
-Xbootclasspath/a:directories and zip/jar files separated by ;
append to end of bootstrap class path
-Xbootclasspath/p:directories and zip/jar files separated by ;
prepend in front of bootstrap class path
-Xnoclassgc disable class garbage collection
-Xincgc enable incremental garbage collection
-Xloggc:file log GC status to a file with time stamps
-Xbatch disable background compilation
-Xmssize set initial Java heap size
-Xmxsize set maximum Java heap size
-Xsssize set java thread stack size
-Xprof output cpu profiling data
-Xfuture enable strictest checks, anticipating future default
-Xrs reduce use of OS signals by Java/VM (see
documentation)
-Xcheck:jni perform additional checks for JNI functions
-Xshare:off do not attempt to use shared class data
-Xshare:auto use shared class data if possible (default)
-Xshare:on require using shared class data, otherwise fail.
Java虛擬機(JVM)參數配置說明
在Java、J2EE大型應用中,JVM非標準參數的配置直接關係到整個系統的性能。
JVM非標準參數指的是JVM底層的一些配置參數,這些參數在一般開發中默認即可,不需
要任何配置。但是在生產環境中,為了提高性能,往往需要調整這些參數,以求系統達
到最佳新能。
另外這些參數的配置也是影響系統穩定性的一個重要因素,相信大多數Java開發人員都
見過「OutOfMemory」類型的錯誤。呵呵,這其中很可能就是JVM參數配置不當或者就沒
有配置沒意識到配置引起的。
為了說明這些參數,還需要說說JDK中的命令行工具一些知識做鋪墊。
首先看如何獲取這些命令配置信息說明:
假設你是windows平台,你安裝了J2SDK,那麼現在你從cmd控制台窗口進入J2SDK安裝目
錄下的bin目錄,然後運行java命令,出現如下結果,這些就是包括java.exe工具的和
JVM的所有命令都在裏面。
———————————————————————–
D:\j2sdk15\binjava
Usage: java [-options] class [args…]
(to execute a class)
or java [-options] -jar jarfile [args…]
(to execute a jar file)
where options include:
-client to select the “client” VM
-server to select the “server” VM
-hotspot is a synonym for the “client” VM [deprecated]
The default VM is client.
-cp class search path of directories and zip/jar files
-classpath class search path of directories and zip/jar files
A ; separated list of directories, JAR archives,
and ZIP archives to search for class files.
-Dname=value
set a system property
-verbose[:class|gc|jni]
enable verbose output
-version print product version and exit
-version:value
require the specified version to run
-showversion print product version and continue
-jre-restrict-search | -jre-no-restrict-search
include/exclude user private JREs in the version search
-? -help print this help message
-X print help on non-standard options
-ea[:packagename…|:classname]
-enableassertions[:packagename…|:classname]
enable assertions
-da[:packagename…|:classname]
-disableassertions[:packagename…|:classname]
disable assertions
-esa | -enablesystemassertions
enable system assertions
-dsa | -disablesystemassertions
disable system assertions
-agentlib:libname[=options]
load native agent library libname, e.g. -agentlib:hprof
see also, -agentlib:jdwp=help and -agentlib:hprof=help
-agentpath:pathname[=options]
load native agent library by full pathname
-javaagent:jarpath[=options]
load Java programming language agent, see
java.lang.instrument
———————————————————————–
在控制台輸出信息中,有個-X(注意是大寫)的命令,這個正是查看JVM配置參數的命
令。
其次,用java -X 命令查看JVM的配置說明:
運行後如下結果,這些就是配置JVM參數的秘密武器,這些信息都是英文的,為了方便
閱讀,我根據自己的理解翻譯成中文了(不準確的地方還請各位博友斧正)
———————————————————————–
D:\j2sdk15\binjava -X
-Xmixed mixed mode execution (default)
-Xint interpreted mode execution only
-Xbootclasspath:directories and zip/jar files separated by ;
set search path for bootstrap classes and resources
-Xbootclasspath/a:directories and zip/jar files separated by ;
append to end of bootstrap class path
-Xbootclasspath/p:directories and zip/jar files separated by ;
prepend in front of bootstrap class path
-Xnoclassgc disable class garbage collection
-Xincgc enable incremental garbage collection
-Xloggc:file log GC status to a file with time stamps
-Xbatch disable background compilation
-Xmssize set initial Java heap size
-Xmxsize set maximum Java heap size
-Xsssize set java thread stack size
-Xprof output cpu profiling data
-Xfuture enable strictest checks, anticipating future default
-Xrs reduce use of OS signals by Java/VM (see
documentation)
-Xcheck:jni perform additional checks for JNI functions
-Xshare:off do not attempt to use shared class data
-Xshare:auto use shared class data if possible (default)
-Xshare:on require using shared class data, otherwise fail.
The -X options are non-standard and subject to change without notice.
———————————————————————–
JVM配置參數中文說明:
———————————————————————–
1、-Xmixed mixed mode execution (default)
混合模式執行
2、-Xint interpreted mode execution only
解釋模式執行
3、-Xbootclasspath:directories and zip/jar files separated by ;
set search path for bootstrap classes and resources
設置zip/jar資源或者類(.class文件)存放目錄路徑
3、-Xbootclasspath/a:directories and zip/jar files separated by ;
append to end of bootstrap class path
追加zip/jar資源或者類(.class文件)存放目錄路徑
4、-Xbootclasspath/p:directories and zip/jar files separated by ;
prepend in front of bootstrap class path
預先加載zip/jar資源或者類(.class文件)存放目錄路徑
5、-Xnoclassgc disable class garbage collection
關閉類垃圾回收功能
6、-Xincgc enable incremental garbage collection
開啟類的垃圾回收功能
7、-Xloggc:file log GC status to a file with time stamps
記錄垃圾回日誌到一個文件。
8、-Xbatch disable background compilation
關閉後台編譯
9、-Xmssize set initial Java heap size
設置JVM初始化堆內存大小
10、-Xmxsize set maximum Java heap size
設置JVM最大的堆內存大小
11、-Xsssize set java thread stack size
設置JVM棧內存大小
12、-Xprof output cpu profiling data
輸入CPU概要表數據
13、-Xfuture enable strictest checks, anticipating future default
執行嚴格的代碼檢查,預測可能出現的情況
14、-Xrs reduce use of OS signals by Java/VM (see
documentation)
通過JVM還原操作系統信號
15、-Xcheck:jni perform additional checks for JNI functions
對JNI函數執行檢查
16、-Xshare:off do not attempt to use shared class data
儘可能不去使用共享類的數據
17、-Xshare:auto use shared class data if possible (default)
儘可能的使用共享類的數據
18、-Xshare:on require using shared class data, otherwise fail.
儘可能的使用共享類的數據,否則運行失敗
The -X options are non-standard and subject to change without notice.
JVM性能調優-G1
本篇是對Java官網G1收集器調優的精簡版。針對G1垃圾的收集階段可能出現的問題,非合理內存分配,大對象佔用,Full GC等問題作出解決方式和操作參數。
G1是一個吞吐量和時間延遲之間相互平衡的收集器。目標是高吞吐量下提供相對較小、統一的暫停。
所以如果是交互性強的應用程序,使用G1時需要基於時延優先進行考慮。
虛擬機從操作系統內存中分配或歸還內存可能會導致不必要的延遲。通過使用選項-Xms和-Xmx將最小和最大堆大小設置為相同的值,並使用 – XX:+AlwaysPreTouch 預觸摸所有內存,以將這項工作移到VM啟動階段,從而避免延遲。
並行處理 Reference對象,ParallelRefProcEnabled默認值false,若 GC log 里出現 Reference 處理時間較長的日誌,可以開啟此參數- XX:+ParalleRefProcEnabled 。開啟後會使用jvm可用的線程數進行處理,但官網上提到的-XX:ReferencesPerThread參數在jdk17的版本中沒有找到,猜測可能是jvm內部控制不再作可調試的參數。
年輕代收集所花費的時間大致與年輕代的大小成正比。官網給出的兩個參數- XX:G1NewSizePercent ,-XX: G1MaxNewSizePercent 在jdk17中沒有找到,在沒有固定年輕代大小時,G1會進行動態調整,所以這個調優的參考性不大,可以忽略。
減少老年代regions暫停時間
RS是一個抽象的數據結構,具體的實現由table card完成。一般會把記憶集和卡表放在一起討論。簡單來講就是所有對象引用關係的一個集合,GCRoot時掃描的不是去實際的內存區域,否則跨代引用時從新生代到老年代會是一個漫長的過程。RS很好的解決了跨代引用的問題。由於RS會動態更新,垃圾收集必須先等RS更新完畢後才去執行。所以RS更新如果耗時過長則會影響回收時間。
RS的大小跟堆空間是成正比的。
掃描RS時間也由G1為保持低存儲容量而執行的壓縮量決定。記憶的集合存儲在內存中越緊湊,在垃圾收集期間檢索存儲的值所花費的時間就越多。G1自動執行這種壓縮,稱為記憶集粗化,同時根據該區域記憶集的當前大小更新記憶集。特別是在最高壓縮級別時,檢索實際數據可能非常慢。
使用選項- XX:G1SummarizeRSetStatsPeriod 結合gc+remset=trace級別日誌顯示是否發生粗化。
解決方案
操作選項
原創文章,作者:小藍,如若轉載,請註明出處:https://www.506064.com/zh-hk/n/186660.html