JVM常用參數(shù)調(diào)優(yōu)方法是什么

本篇內(nèi)容介紹了“JVM常用參數(shù)調(diào)優(yōu)方法是什么”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

對于調(diào)優(yōu)這個事情來說，一般就是三個過程：

• 性能監(jiān)控：問題沒有發(fā)生，你并不知道你需要調(diào)優(yōu)什么。此時需要一些系統(tǒng)、應(yīng)用的監(jiān)控工具來發(fā)現(xiàn)問題。

• 性能分析：問題已經(jīng)發(fā)生，但是你并不知道問題到底出在哪里。此時就需要使用工具、經(jīng)驗對系統(tǒng)、應(yīng)用進行瓶頸分析，以求定位到問題原因。

• 性能調(diào)優(yōu)：經(jīng)過上一步的分析定位到了問題所在，需要對問題進行解決，使用代碼、配置等手段進行優(yōu)化。

Java調(diào)優(yōu)也不外乎這三步。

此外，本文所講的性能分析、調(diào)優(yōu)等是拋開以下因素的：

• 系統(tǒng)底層環(huán)境：硬件、操作系統(tǒng)等

• 數(shù)據(jù)結(jié)構(gòu)和算法的使用

• 外部系統(tǒng)如數(shù)據(jù)庫、緩存的使用

調(diào)優(yōu)準備

調(diào)優(yōu)是需要做好準備工作的，畢竟每一個應(yīng)用的業(yè)務(wù)目標都不盡相同，性能瓶頸也不會總在同一個點上。在業(yè)務(wù)應(yīng)用層面，我們需要：

• 需要了解系統(tǒng)的總體架構(gòu)，明確壓力方向。比如系統(tǒng)的哪一個接口、模塊是使用率最高的，面臨高并發(fā)的挑戰(zhàn)。

• 需要構(gòu)建測試環(huán)境來測試應(yīng)用的性能，使用ab、loadrunner、jmeter都可以。

• 對關(guān)鍵業(yè)務(wù)數(shù)據(jù)量進行分析，這里主要指的是對一些數(shù)據(jù)的量化分析，如數(shù)據(jù)庫一天的數(shù)據(jù)量有多少；緩存的數(shù)據(jù)量有多大等

• 了解系統(tǒng)的響應(yīng)速度、吞吐量、TPS、QPS等指標需求，比如秒殺系統(tǒng)對響應(yīng)速度和QPS的要求是非常高的。

• 了解系統(tǒng)相關(guān)軟件的版本、模式和參數(shù)等，有時候限于應(yīng)用依賴服務(wù)的版本、模式等，性能也會受到一定的影響。

性能分析

在系統(tǒng)層面能夠影響應(yīng)用性能的一般包括三個因素：CPU、內(nèi)存和IO，可以從這三方面進行程序的性能瓶頸分析。

CPU分析

當程序響應(yīng)變慢的時候，首先使用top、vmstat、ps等命令查看系統(tǒng)的cpu使用率是否有異常，從而可以判斷出是否是cpu繁忙造成的性能問題。其中，主要通過us（用戶進程所占的%）這個數(shù)據(jù)來看異常的進程信息。當us接近100%甚至更高時，可以確定是cpu繁忙造成的響應(yīng)緩慢。一般說來，cpu繁忙的原因有以下幾個：

• 線程中有無限空循環(huán)、無阻塞、正則匹配或者單純的計算

• 發(fā)生了頻繁的gc

• 多線程的上下文切換

確定好cpu使用率最高的進程之后就可以使用jstack來打印出異常進程的堆棧信息：

jstack [pid]

接下來需要注意的一點是，Linux下所有線程最終還是以輕量級進程的形式存在系統(tǒng)中的，而使用jstack只能打印出進程的信息，這些信息里面包含了此進程下面所有線程（輕量級進程-LWP）的堆棧信息。因此，進一步的需要確定是哪一個線程耗費了大量CPU，此時可以使用top -p [processId] -H來查看，也可以直接通過ps -Le來顯示所有進程,包括LWP的資源耗費信息。最后，通過在jstack的輸出文件中查找對應(yīng)的LWP的id即可以定位到相應(yīng)的堆棧信息。其中需要注意的是線程的狀態(tài)：RUNNABLE、WAITING等。對于Runnable的進程需要注意是否有耗費cpu的計算。對于Waiting的線程一般是鎖的等待操作。

也可以使用jstat來查看對應(yīng)進程的gc信息，以判斷是否是gc造成了cpu繁忙。

jstat -gcutil [pid]

還可以通過vmstat，通過觀察內(nèi)核狀態(tài)的上下文切換(cs)次數(shù)，來判斷是否是上下文切換造成的cpu繁忙。

vmstat 1 5

此外，有時候可能會由jit引起一些cpu飚高的情形，如大量方法編譯等。這里可以使用-XX:+PrintCompilation這個參數(shù)輸出jit編譯情況，以排查jit編譯引起的cpu問題。

內(nèi)存分析

對Java應(yīng)用來說，內(nèi)存主要是由堆外內(nèi)存和堆內(nèi)內(nèi)存組成。

1. 堆外內(nèi)存

   堆外內(nèi)存主要是JNI、Deflater/Inflater、DirectByteBuffer（nio中會用到）使用的。對于這種堆外內(nèi)存的分析，還是需要先通過vmstat、sar、top、pidstat(這里的sar,pidstat以及iostat都是 sysstat軟件套件的一部分，需要單獨安裝)等查看swap和物理內(nèi)存的消耗狀況再做判斷的。此外，對于JNI、Deflater這種調(diào)用可以通過 Google-preftools來追蹤資源使用狀況。

2. 堆內(nèi)內(nèi)存

   此部分內(nèi)存為Java應(yīng)用主要的內(nèi)存區(qū)域。通常與這部分內(nèi)存性能相關(guān)的有：

   以上使用不當很容易造成：

   排查堆內(nèi)存問題的常用工具是jmap，是jdk自帶的。一些常用用法如下：

   此外，不管是使用jmap還是在OOM時產(chǎn)生的dump文件，可以使用Eclipse的MAT(MEMORY ANALYZER TOOL)來分析，可以看到具體的堆棧和內(nèi)存中對象的信息。當然jdk自帶的jhat也能夠查看dump文件(啟動web端口供開發(fā)者使用瀏覽器瀏覽堆內(nèi)對象的信息)。此外，VisualVM也能夠打開hprof文件，使用它的heap walker查看堆內(nèi)存信息。

   

• 查看jvm內(nèi)存使用狀況：jmap -heap

• 查看jvm內(nèi)存存活的對象：jmap -histo:live

• 把heap里所有對象都dump下來，無論對象是死是活：jmap -dump:format=b,file=xxx.hprof

• 先做一次full GC，再dump，只包含仍然存活的對象信息：jmap -dump:format=b,live,file=xxx.hprof

• Heap space：堆內(nèi)存不足

• PermGen space：永久代內(nèi)存不足

• Native thread：本地線程沒有足夠內(nèi)存可分配

• 頻繁GC -> Stop the world，使你的應(yīng)用響應(yīng)變慢

• OOM，直接造成內(nèi)存溢出錯誤使得程序退出。OOM又可以分為以下幾種：

• 創(chuàng)建的對象：這個是存儲在堆中的，需要控制好對象的數(shù)量和大小，尤其是大的對象很容易進入老年代

• 全局集合：全局集合通常是生命周期比較長的，因此需要特別注意全局集合的使用

• 緩存：緩存選用的數(shù)據(jù)結(jié)構(gòu)不同，會很大程序影響內(nèi)存的大小和gc

• ClassLoader：主要是動態(tài)加載類容易造成永久代內(nèi)存不足

• 多線程：線程分配會占用本地內(nèi)存，過多的線程也會造成內(nèi)存不足

IO分析

通常與應(yīng)用性能相關(guān)的包括：文件IO和網(wǎng)絡(luò)IO。

1. 文件IO

   可以使用系統(tǒng)工具pidstat、iostat、vmstat來查看io的狀況。這里可以看一張使用vmstat的結(jié)果圖。

   

   這里主要注意bi和bo這兩個值，分別表示塊設(shè)備每秒接收的塊數(shù)量和塊設(shè)備每秒發(fā)送的塊數(shù)量，由此可以判定io繁忙狀況。進一步的可以通過使用strace工具定位對文件io的系統(tǒng)調(diào)用。通常，造成文件io性能差的原因不外乎：

• 大量的隨機讀寫

• 設(shè)備慢

• 文件太大

2. 網(wǎng)絡(luò)IO

   查看網(wǎng)絡(luò)io狀況，一般使用的是netstat工具?？梢圆榭此羞B接的狀況、數(shù)目、端口信息等。例如：當time_wait或者close_wait連接過多時，會影響應(yīng)用的相應(yīng)速度。

    netstat -anp

   

   此外，還可以使用tcpdump來具體分析網(wǎng)絡(luò)io的數(shù)據(jù)。當然，tcpdump出的文件直接打開是一堆二進制的數(shù)據(jù)，可以使用wireshark閱讀具體的連接以及其中數(shù)據(jù)的內(nèi)容。

    tcpdump -i eth0 -w tmp.cap -tnn dst port 8080 #監(jiān)聽8080端口的網(wǎng)絡(luò)請求并打印日志到tmp.cap中

   還可以通過查看/proc/interrupts來獲取當前系統(tǒng)使用的中斷的情況。

   

   各個列依次是：

    irq的序號， 在各自cpu上發(fā)生中斷的次數(shù)，可編程中斷控制器，設(shè)備名稱（request_irq的dev_name字段）

   通過查看網(wǎng)卡設(shè)備的終端情況可以判斷網(wǎng)絡(luò)io的狀況。

其他分析工具

上面分別針對CPU、內(nèi)存以及IO講了一些系統(tǒng)/JDK自帶的分析工具。除此之外，還有一些綜合分析工具或者框架可以更加方便我們對Java應(yīng)用性能的排查、分析、定位等。

• VisualVM

  這個工具應(yīng)該是Java開發(fā)者們非常熟悉的一款java應(yīng)用監(jiān)測工具，原理是通過jmx接口來連接jvm進程，從而能夠看到j(luò)vm上的線程、內(nèi)存、類等信息。 如果想進一步查看gc情況，可以安裝visual gc插件。此外，visualvm也有btrace的插件，可以可視化直觀的編寫btrace代碼并查看輸出日志。 與VisualVm類似的，jconsole也是通過jmx查看遠程jvm信息的一款工具，更進一步的，通過它還可以顯示具體的線程堆棧信息以及內(nèi)存中各個年代的占用情況，也支持直接遠程執(zhí)行MBEAN。當然，visualvm通過安裝jconsole插件也可以擁有這些功能。 但由于這倆工具都是需要ui界面的，因此一般都是通過本地遠程連接服務(wù)器jvm進程。服務(wù)器環(huán)境下，一般并不用此種方式。

• Java Mission Control(jmc)

  此工具是jdk7 u40開始自帶的，原來是JRockit上的工具，是一款采樣型的集診斷、分析和監(jiān)控與一體的非常強大的工具: https://docs.oracle.com/javacomponents/jmc-5-5/jmc-user-guide/toc.htm。但是此工具是基于JFR(jcmdJFR.start name=test duration=60s settings=template.jfc filename=output.jfr)的，而開啟JFR需要商業(yè)證書：jcmdVM.unlock_commercial_features。

  

• Btrace

  這里不得不提的是btrace這個神器，它使用java attach api+ java agent + instrument api能夠?qū)崿F(xiàn)jvm的動態(tài)追蹤。在不重啟應(yīng)用的情況下可以加入攔截類的方法以打印日志等。具體的用法可以參考 Btrace入門到熟練小工完全指南。

• Jwebap

  Jwebap是一款JavaEE性能檢測框架，基于asm增強字節(jié)碼實現(xiàn)。支持：http請求、jdbc連接、method的調(diào)用軌跡跟蹤以及次數(shù)、耗時的統(tǒng)計。由此可以獲取最耗時的請求、方法，并可以查看jdbc連接的次數(shù)、是否關(guān)閉等。但此項目是2006年的一個項目，已經(jīng)將近10年沒有更新。根據(jù)筆者使用，已經(jīng)不支持jdk7編譯的應(yīng)用。如果要使用，建議基于原項目二次開發(fā)，同時也可以加入對redis連接的軌跡跟蹤。當然，基于字節(jié)碼增強的原理，也可以實現(xiàn)自己的JavaEE性能監(jiān)測框架。

  

  上圖來自筆者公司二次開發(fā)過的jwebap，已經(jīng)支持jdk8和redis連接追蹤。

• useful-scripts

  這里有一個本人參與的開源的項目： https://github.com/superhj1987/useful-scripts，封裝了很多常用的性能分析命令，比如上文講的打印繁忙java線程堆棧信息，只需要執(zhí)行一個腳本即可。

性能調(diào)優(yōu)

與性能分析相對應(yīng)，性能調(diào)優(yōu)同樣分為三部分。

CPU調(diào)優(yōu)

• 不要存在一直運行的線程(無限while循環(huán))，可以使用sleep休眠一段時間。這種情況普遍存在于一些pull方式消費數(shù)據(jù)的場景下，當一次pull沒有拿到數(shù)據(jù)的時候建議sleep一下，再做下一次pull。

• 輪詢的時候可以使用wait/notify機制

• 避免循環(huán)、正則表達式匹配、計算過多，包括使用String的format、split、replace方法(可以使用apache的commons-lang里的StringUtils對應(yīng)的方法)，使用正則去判斷郵箱格式(有時候會造成死循環(huán))、序列/反序列化等。

• 結(jié)合jvm和代碼，避免產(chǎn)生頻繁的gc，尤其是full GC。

此外，使用多線程的時候，還需要注意以下幾點：

• 使用線程池，減少線程數(shù)以及線程的切換

• 多線程對于鎖的競爭可以考慮減小鎖的粒度(使用ReetrantLock)、拆分鎖(類似ConcurrentHashMap分bucket上鎖), 或者使用CAS、ThreadLocal、不可變對象等無鎖技術(shù)。此外，多線程代碼的編寫最好使用jdk提供的并發(fā)包、Executors框架以及ForkJoin等，此外 Discuptor和 Actor在合適的場景也可以使用。

內(nèi)存調(diào)優(yōu)

內(nèi)存的調(diào)優(yōu)主要就是對jvm的調(diào)優(yōu)。

• 合理設(shè)置各個代的大小。避免新生代設(shè)置過小(不夠用，經(jīng)常minor gc并進入老年代)以及過大(會產(chǎn)生碎片)，同樣也要避免Survivor設(shè)置過大和過小。

• 選擇合適的GC策略。需要根據(jù)不同的場景選擇合適的gc策略。這里需要說的是，cms并非全能的。除非特別需要再設(shè)置，畢竟cms的新生代回收策略parnew并非最快的，且cms會產(chǎn)生碎片。此外，G1直到j(luò)dk8的出現(xiàn)也并沒有得到廣泛應(yīng)用，并不建議使用。

• jvm啟動參數(shù)配置-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:[log_path]，以記錄gc日志，便于排查問題。

其中，對于第一點，具體的還有一點建議：

• 年輕代大小選擇：響應(yīng)時間優(yōu)先的應(yīng)用，盡可能設(shè)大，直到接近系統(tǒng)的最低響應(yīng)時間限制（根據(jù)實際情況選擇）。在此種情況下，年輕代收集發(fā)生gc的頻率是最小的。同時，也能夠減少到達年老代的對象。吞吐量優(yōu)先的應(yīng)用，也盡可能的設(shè)置大，因為對響應(yīng)時間沒有要求，垃圾收集可以并行進行，建議適合8CPU以上的應(yīng)用使用。

• 年老代大小選擇：響應(yīng)時間優(yōu)先的應(yīng)用，年老代一般都是使用并發(fā)收集器，所以其大小需要小心設(shè)置，一般要考慮并發(fā)會話率和會話持續(xù)時間等一些參數(shù)。如果堆設(shè)置小了，會造成內(nèi)存碎片、高回收頻率以及應(yīng)用暫停而使用傳統(tǒng)的標記清除方式；如果堆大了，則需要較長的收集時間。最優(yōu)化的方案，一般需要參考以下數(shù)據(jù)獲得：

  一般吞吐量優(yōu)先的應(yīng)用都應(yīng)該有一個很大的年輕代和一個較小的年老代。這樣可以盡可能回收掉大部分短期對象，減少中期的對象，而年老代存放長期存活對象。

• 并發(fā)垃圾收集信息

• 持久代并發(fā)收集次數(shù)

• 傳統(tǒng)GC信息

• 花在年輕代和年老代回收上的時間比例

此外，較小堆引起的碎片問題：因為年老代的并發(fā)收集器使用標記、清除算法，所以不會對堆進行壓縮。當收集器回收時，會把相鄰的空間進行合并，這樣可以分配給較大的對象。但是，當堆空間較小時，運行一段時間以后，就會出現(xiàn)“碎片”，如果并發(fā)收集器找不到足夠的空間，那么并發(fā)收集器將會停止，然后使用傳統(tǒng)的標記、清除方式進行回收。如果出現(xiàn)“碎片”，可能需要進行如下配置：-XX:+UseCMSCompactAtFullCollection，使用并發(fā)收集器時，開啟對年老代的壓縮。同時使用-XX:CMSFullGCsBeforeCompaction=xx設(shè)置多少次Full GC后，對年老代進行壓縮。

其余對于jvm的優(yōu)化問題可見后面JVM參數(shù)進階一節(jié)。

代碼上，也需要注意：

• 避免保存重復的String對象，同時也需要小心String.subString()與String.intern()的使用，尤其是后者其底層數(shù)據(jù)結(jié)構(gòu)為StringTable，當字符串大量不重復時，會使得StringTable非常大(一個固定大小的hashmap，可以由參數(shù)-XX:StringTableSize=N設(shè)置大小)，從而影響young gc的速度。在jackson和fastjson中使用了此方法，某些場景下會引起gc問題: YGC越來越慢，為什么。

• 盡量不要使用finalizer

• 釋放不必要的引用：ThreadLocal使用完記得釋放以防止內(nèi)存泄漏，各種stream使用完也記得close。

• 使用對象池避免無節(jié)制創(chuàng)建對象，造成頻繁gc。但不要隨便使用對象池，除非像連接池、線程池這種初始化/創(chuàng)建資源消耗較大的場景，

• 緩存失效算法，可以考慮使用SoftReference、WeakReference保存緩存對象

• 謹慎熱部署/加載的使用，尤其是動態(tài)加載類等

• 不要用Log4j輸出文件名、行號，因為Log4j通過打印線程堆棧實現(xiàn)，生成大量String。此外，使用log4j時，建議此種經(jīng)典用法，先判斷對應(yīng)級別的日志是否打開，再做操作，否則也會生成大量String。

    if (logger.isInfoEnabled()) {
        logger.info(msg);
    }

IO調(diào)優(yōu)

文件IO上需要注意：

• 考慮使用異步寫入代替同步寫入，可以借鑒redis的aof機制。

• 利用緩存，減少隨機讀

• 盡量批量寫入，減少io次數(shù)和尋址

• 使用數(shù)據(jù)庫代替文件存儲

網(wǎng)絡(luò)IO上需要注意：

• 和文件IO類似，使用異步IO、多路復用IO/事件驅(qū)動IO代替同步阻塞IO

• 批量進行網(wǎng)絡(luò)IO,減少IO次數(shù)

• 使用緩存，減少對網(wǎng)絡(luò)數(shù)據(jù)的讀取

• 使用協(xié)程: Quasar

其他優(yōu)化建議

• 算法、邏輯上是程序性能的首要，遇到性能問題，應(yīng)該首先優(yōu)化程序的邏輯處理

• 優(yōu)先考慮使用返回值而不是異常表示錯誤

• 查看自己的代碼是否對內(nèi)聯(lián)是友好的: 你的Java代碼對JIT編譯友好么？

此外，jdk7、8在jvm的性能上做了一些增強：

• 通過-XX:+TieredCompilation開啟JDK7的 多層編譯（tiered compilation）支持。多層編譯結(jié)合了客戶端C1編譯器和服務(wù)端C2編譯器的優(yōu)點(客戶端編譯能夠快速啟動和及時優(yōu)化，服務(wù)器端編譯可以提供更多的高級優(yōu)化)，是一個非常高效利用資源的切面方案。在開始時先進行低層次的編譯，同時收集信息，在后期再進一步進行高層次的編譯進行高級優(yōu)化。需要注意的一點：這個參數(shù)會消耗比較多的內(nèi)存資源，因為同一個方法被編譯了多次，存在多份native內(nèi)存拷貝，建議把code cache調(diào)大一點兒（-XX:+ReservedCodeCacheSize，InitialCodeCacheSize）。否則有可能由于code cache不足，jit編譯的時候不停的嘗試清理code cache，丟棄無用方法，消耗大量資源在jit線程上。

• Compressed Oops：壓縮指針在jdk7中的server模式下已經(jīng)默認開啟。

• Zero-Based Compressed Ordinary Object Pointers：當使用了上述的壓縮指針時，在64位jvm上，會要求操作系統(tǒng)保留從一個虛擬地址0開始的內(nèi)存。如果操作系統(tǒng)支持這種請求，那么就開啟了Zero-Based Compressed Oops。這樣可以使得無須在java堆的基地址添加任何地址補充即可把一個32位對象的偏移解碼成64位指針。

• 逃逸分析(Escape Analysis): Server模式的編譯器會根據(jù)代碼的情況，來判斷相關(guān)對象的逃逸類型，從而決定是否在堆中分配空間，是否進行標量替換(在棧上分配原子類型局部變量)。此外，也可以根據(jù)調(diào)用情況來決定是否自動消除同步控制，如StringBuffer。這個特性從Java SE 6u23開始就默認開啟。

• NUMA Collector Enhancements：這個重要針對的是The Parallel Scavenger垃圾回收器。使其能夠利用NUMA (Non Uniform Memory Access，即每一個處理器核心都有本地內(nèi)存，能夠低延遲、高帶寬訪問) 架構(gòu)的機器的優(yōu)勢來更快的進行g(shù)c。可以通過-XX:+UseNUMA開啟支持。

此外，網(wǎng)上還有很多過時的建議，不要再盲目跟隨:

• 變量用完設(shè)置為null，加快內(nèi)存回收，這種用法大部分情況下并沒有意義。一種情況除外：如果有個Java方法沒有被JIT編譯但里面仍然有代碼會執(zhí)行比較長時間，那么在那段會執(zhí)行長時間的代碼前顯式將不需要的引用類型局部變量置null是可取的。具體的可以見R大的解釋： https://www.zhihu.com/question/48059457/answer/113538171

• 方法參數(shù)設(shè)置為final，這種用法也沒有太大的意義，尤其在jdk8中引入了effective final，會自動識別final變量。

JVM參數(shù)進階

jvm的參數(shù)設(shè)置一直是比較理不清的地方，很多時候都搞不清都有哪些參數(shù)可以配置，參數(shù)是什么意思，為什么要這么配置等。這里主要針對這些做一些常識性的說明以及對一些容易讓人進入陷阱的參數(shù)做一些解釋。

以下所有都是針對Oracle/Sun JDK 6來講

1. 啟動參數(shù)默認值

   Java有很多的啟動參數(shù)，而且很多版本都并不一樣。但是現(xiàn)在網(wǎng)上充斥著各種資料，如果不加辨別的全部使用，很多是沒有效果或者本來就是默認值的。一般的，我們可以通過使用java -XX:+PrintFlagsInitial來查看所有可以設(shè)置的參數(shù)以及其默認值。也可以在程序啟動的時候加入-XX:+PrintCommandLineFlags來查看與默認值不相同的啟動參數(shù)。如果想查看所有啟動參數(shù)(包括和默認值相同的)，可以使用-XX:+PrintFlagsFinal。

   輸出里“=”表示使用的是初始默認值，而“:=”表示使用的不是初始默認值，可能是命令行傳進來的參數(shù)、配置文件里的參數(shù)或者是 ergonomics自動選擇了別的值。

   此外，還可以使用jinfo命令顯示啟動的參數(shù)。

   這里需要指出的是，當你配置jvm參數(shù)時，最好是先通過以上命令查看對應(yīng)參數(shù)的默認值再確定是否需要設(shè)置。也最好不要配置你搞不清用途的參數(shù)，畢竟默認值的設(shè)置是有它的合理之處的。

• jinfo -flags [pid] #查看目前啟動使用的有效參數(shù)

• jinfo -flag [flagName] [pid] #查看對應(yīng)參數(shù)的值

2. 動態(tài)設(shè)置參數(shù)

   當Java應(yīng)用啟動后，定位到了是GC造成的性能問題，但是你啟動的時候并沒有加入打印gc的參數(shù)，很多時候的做法就是重新加參數(shù)然后重啟應(yīng)用。但這樣會造成一定時間的服務(wù)不可用。最佳的做法是能夠在不重啟應(yīng)用的情況下，動態(tài)設(shè)置參數(shù)。使用jinfo可以做到這一點(本質(zhì)上還是基于jmx的)。

    jinfo -flag [+/-][flagName] [pid] #啟用/禁止某個參數(shù)
    jinfo -flag [flagName=value] [pid] #設(shè)置某個參數(shù)

   對于上述的gc的情況，就可以使用以下命令打開heap dump并設(shè)置dump路徑。

    jinfo -flag +HeapDumpBeforeFullGC [pid] 
    jinfo -flag +HeapDumpAfterFullGC [pid]
    jinfo -flag HeapDumpPath=/home/dump/dir [pid]

   同樣的也可以動態(tài)關(guān)閉。

    jinfo -flag -HeapDumpBeforeFullGC [pid] 
    jinfo -flag -HeapDumpAfterFullGC [pid]

   其他的參數(shù)設(shè)置類似。

3. -verbose:gc 與 -XX:+PrintGCDetails

   很多gc推薦設(shè)置都同時設(shè)置了這兩個參數(shù)，其實，只要打開了-XX:+PrintGCDetails，前面的選項也會同時打開，無須重復設(shè)置。

4. -XX:+DisableExplicitGC

   這個參數(shù)的作用就是使得system.gc變?yōu)榭照{(diào)用，很多推薦設(shè)置里面都是建議開啟的。但是，如果你用到了NIO或者其他使用到堆外內(nèi)存的情況，使用此選項會造成oom。可以用XX:+ExplicitGCInvokesConcurrent或XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses(配合CMS使用，使得system.gc觸發(fā)一次并發(fā)gc)代替。

   此外，還有一個比較有意思的地方。如果你不設(shè)置此選項的話，當你使用了RMI的時候，會周期性地來一次full gc。這個現(xiàn)象是由于分布式gc造成的，為RMI服務(wù)。

5. 此參數(shù)是設(shè)置的堆外內(nèi)存的上限值。當不設(shè)置的時候為-1，此值為-Xmx減去一個survivor space的預留大小。

6. 由于遺留原因，作用相同的參數(shù)

• -Xss 與 -XX:ThreadStackSize

• -Xmn 與 -XX:NewSize，此外這里需要注意的是設(shè)置了-Xmn的話，NewRatio就沒作用了。

7. -XX:MaxTenuringThreshold

   使用工具查看此值默認值為15，但是選擇了CMS的時候，此值會變成4。當此值設(shè)置為0時，所有eden里的活對象在經(jīng)歷第一次minor GC的時候就會直接晉升到old gen，survivor space直接就沒用。還有值得注意的一點，當使用并行回收器時，此值是沒有作用的，并行回收器默認是自動調(diào)整這些參數(shù)以求達到吞吐量最大的。此外，即使是使用CMS等回收器，晉升到老年代的age也不是不變的，當某一age的對象的大小達到年輕代的50%時，這個age會被動態(tài)調(diào)整為晉升年齡。

8. -XX:HeapDumpPath

   使用此參數(shù)可以指定-XX:+HeapDumpBeforeFullGC、-XX:+HeapDumpAfterFullGC、-XX:+HeapDumpOnOutOfMemoryError觸發(fā)heap dump文件的存儲位置。

9. -XX:+UseAdaptiveSizePolicy

   此參數(shù)在并行回收器時是默認開啟的，會根據(jù)應(yīng)用運行狀況做自我調(diào)整，如MaxTenuringThreshold、survivor區(qū)大小等。其中第一次晉升老年代的年齡以InitialTenuringThreshold（默認為7）開始，后續(xù)會自動調(diào)整。如果希望跟蹤每次minor GC后新的存活周期的閾值，可在啟動參數(shù)上增加：-XX:+PrintTenuringDistribution。如果想要可以配置這些參數(shù)，可以關(guān)閉此選項，但paralle的性能很難達到最佳。其他垃圾回收期則慎重開啟此開關(guān)。

“JVM常用參數(shù)調(diào)優(yōu)方法是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！