本篇內(nèi)容介紹了“JVM常用參數(shù)調(diào)優(yōu)方法是什么”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！
成都創(chuàng)新互聯(lián)公司自成立以來，一直致力于為企業(yè)提供從網(wǎng)站策劃、網(wǎng)站設(shè)計(jì)、成都做網(wǎng)站、成都網(wǎng)站設(shè)計(jì)、電子商務(wù)、網(wǎng)站推廣、網(wǎng)站優(yōu)化到為企業(yè)提供個(gè)性化軟件開發(fā)等基于互聯(lián)網(wǎng)的全面整合營(yíng)銷服務(wù)。公司擁有豐富的網(wǎng)站建設(shè)和互聯(lián)網(wǎng)應(yīng)用系統(tǒng)開發(fā)管理經(jīng)驗(yàn)、成熟的應(yīng)用系統(tǒng)解決方案、優(yōu)秀的網(wǎng)站開發(fā)工程師團(tuán)隊(duì)及專業(yè)的網(wǎng)站設(shè)計(jì)師團(tuán)隊(duì)。
對(duì)于調(diào)優(yōu)這個(gè)事情來說，一般就是三個(gè)過程：
性能監(jiān)控：?jiǎn)栴}沒有發(fā)生，你并不知道你需要調(diào)優(yōu)什么。此時(shí)需要一些系統(tǒng)、應(yīng)用的監(jiān)控工具來發(fā)現(xiàn)問題。
性能分析：?jiǎn)栴}已經(jīng)發(fā)生，但是你并不知道問題到底出在哪里。此時(shí)就需要使用工具、經(jīng)驗(yàn)對(duì)系統(tǒng)、應(yīng)用進(jìn)行瓶頸分析，以求定位到問題原因。
性能調(diào)優(yōu)：經(jīng)過上一步的分析定位到了問題所在，需要對(duì)問題進(jìn)行解決，使用代碼、配置等手段進(jìn)行優(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ù)庫(kù)、緩存的使用
調(diào)優(yōu)是需要做好準(zhǔn)備工作的，畢竟每一個(gè)應(yīng)用的業(yè)務(wù)目標(biāo)都不盡相同，性能瓶頸也不會(huì)總在同一個(gè)點(diǎn)上。在業(yè)務(wù)應(yīng)用層面，我們需要：
需要了解系統(tǒng)的總體架構(gòu)，明確壓力方向。比如系統(tǒng)的哪一個(gè)接口、模塊是使用率最高的，面臨高并發(fā)的挑戰(zhàn)。
需要構(gòu)建測(cè)試環(huán)境來測(cè)試應(yīng)用的性能，使用ab、loadrunner、jmeter都可以。
對(duì)關(guān)鍵業(yè)務(wù)數(shù)據(jù)量進(jìn)行分析，這里主要指的是對(duì)一些數(shù)據(jù)的量化分析，如數(shù)據(jù)庫(kù)一天的數(shù)據(jù)量有多少；緩存的數(shù)據(jù)量有多大等
了解系統(tǒng)的響應(yīng)速度、吞吐量、TPS、QPS等指標(biāo)需求，比如秒殺系統(tǒng)對(duì)響應(yīng)速度和QPS的要求是非常高的。
了解系統(tǒng)相關(guān)軟件的版本、模式和參數(shù)等，有時(shí)候限于應(yīng)用依賴服務(wù)的版本、模式等，性能也會(huì)受到一定的影響。
在系統(tǒng)層面能夠影響應(yīng)用性能的一般包括三個(gè)因素：CPU、內(nèi)存和IO，可以從這三方面進(jìn)行程序的性能瓶頸分析。
當(dāng)程序響應(yīng)變慢的時(shí)候，首先使用top、vmstat、ps等命令查看系統(tǒng)的cpu使用率是否有異常，從而可以判斷出是否是cpu繁忙造成的性能問題。其中，主要通過us（用戶進(jìn)程所占的%）這個(gè)數(shù)據(jù)來看異常的進(jìn)程信息。當(dāng)us接近100%甚至更高時(shí)，可以確定是cpu繁忙造成的響應(yīng)緩慢。一般說來，cpu繁忙的原因有以下幾個(gè)：
線程中有無(wú)限空循環(huán)、無(wú)阻塞、正則匹配或者單純的計(jì)算
發(fā)生了頻繁的gc
多線程的上下文切換
確定好cpu使用率最高的進(jìn)程之后就可以使用jstack來打印出異常進(jìn)程的堆棧信息：
jstack [pid]
接下來需要注意的一點(diǎn)是，Linux下所有線程最終還是以輕量級(jí)進(jìn)程的形式存在系統(tǒng)中的，而使用jstack只能打印出進(jìn)程的信息，這些信息里面包含了此進(jìn)程下面所有線程（輕量級(jí)進(jìn)程-LWP）的堆棧信息。因此，進(jìn)一步的需要確定是哪一個(gè)線程耗費(fèi)了大量CPU，此時(shí)可以使用top -p [processId] -H來查看，也可以直接通過ps -Le來顯示所有進(jìn)程,包括LWP的資源耗費(fèi)信息。最后，通過在jstack的輸出文件中查找對(duì)應(yīng)的LWP的id即可以定位到相應(yīng)的堆棧信息。其中需要注意的是線程的狀態(tài)：RUNNABLE、WAITING等。對(duì)于Runnable的進(jìn)程需要注意是否有耗費(fèi)cpu的計(jì)算。對(duì)于Waiting的線程一般是鎖的等待操作。
也可以使用jstat來查看對(duì)應(yīng)進(jìn)程的gc信息，以判斷是否是gc造成了cpu繁忙。
jstat -gcutil [pid]
還可以通過vmstat，通過觀察內(nèi)核狀態(tài)的上下文切換(cs)次數(shù)，來判斷是否是上下文切換造成的cpu繁忙。
vmstat 1 5
此外，有時(shí)候可能會(huì)由jit引起一些cpu飚高的情形，如大量方法編譯等。這里可以使用-XX:+PrintCompilation這個(gè)參數(shù)輸出jit編譯情況，以排查jit編譯引起的cpu問題。
對(duì)Java應(yīng)用來說，內(nèi)存主要是由堆外內(nèi)存和堆內(nèi)內(nèi)存組成。
堆外內(nèi)存
堆外內(nèi)存主要是JNI、Deflater/Inflater、DirectByteBuffer（nio中會(huì)用到）使用的。對(duì)于這種堆外內(nèi)存的分析，還是需要先通過vmstat、sar、top、pidstat(這里的sar,pidstat以及iostat都是 sysstat軟件套件的一部分，需要單獨(dú)安裝)等查看swap和物理內(nèi)存的消耗狀況再做判斷的。此外，對(duì)于JNI、Deflater這種調(diào)用可以通過 Google-preftools來追蹤資源使用狀況。
堆內(nèi)內(nèi)存
此部分內(nèi)存為Java應(yīng)用主要的內(nèi)存區(qū)域。通常與這部分內(nèi)存性能相關(guān)的有：
以上使用不當(dāng)很容易造成：
排查堆內(nèi)存問題的常用工具是jmap，是jdk自帶的。一些常用用法如下：
此外，不管是使用jmap還是在OOM時(shí)產(chǎn)生的dump文件，可以使用Eclipse的MAT(MEMORY ANALYZER TOOL)來分析，可以看到具體的堆棧和內(nèi)存中對(duì)象的信息。當(dāng)然jdk自帶的jhat也能夠查看dump文件(啟動(dòng)web端口供開發(fā)者使用瀏覽器瀏覽堆內(nèi)對(duì)象的信息)。此外，VisualVM也能夠打開hprof文件，使用它的heap walker查看堆內(nèi)存信息。
查看jvm內(nèi)存使用狀況：jmap -heap
查看jvm內(nèi)存存活的對(duì)象：jmap -histo:live
把heap里所有對(duì)象都dump下來，無(wú)論對(duì)象是死是活：jmap -dump:format=b,file=xxx.hprof
先做一次full GC，再dump，只包含仍然存活的對(duì)象信息：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)存溢出錯(cuò)誤使得程序退出。OOM又可以分為以下幾種：
創(chuàng)建的對(duì)象：這個(gè)是存儲(chǔ)在堆中的，需要控制好對(duì)象的數(shù)量和大小，尤其是大的對(duì)象很容易進(jìn)入老年代
全局集合：全局集合通常是生命周期比較長(zhǎng)的，因此需要特別注意全局集合的使用
緩存：緩存選用的數(shù)據(jù)結(jié)構(gòu)不同，會(huì)很大程序影響內(nèi)存的大小和gc
ClassLoader：主要是動(dòng)態(tài)加載類容易造成永久代內(nèi)存不足
多線程：線程分配會(huì)占用本地內(nèi)存，過多的線程也會(huì)造成內(nèi)存不足
通常與應(yīng)用性能相關(guān)的包括：文件IO和網(wǎng)絡(luò)IO。
文件IO
可以使用系統(tǒng)工具pidstat、iostat、vmstat來查看io的狀況。這里可以看一張使用vmstat的結(jié)果圖。
這里主要注意bi和bo這兩個(gè)值，分別表示塊設(shè)備每秒接收的塊數(shù)量和塊設(shè)備每秒發(fā)送的塊數(shù)量，由此可以判定io繁忙狀況。進(jìn)一步的可以通過使用strace工具定位對(duì)文件io的系統(tǒng)調(diào)用。通常，造成文件io性能差的原因不外乎：
大量的隨機(jī)讀寫
設(shè)備慢
文件太大
網(wǎng)絡(luò)IO
查看網(wǎng)絡(luò)io狀況，一般使用的是netstat工具?？梢圆榭此羞B接的狀況、數(shù)目、端口信息等。例如：當(dāng)time_wait或者close_wait連接過多時(shí)，會(huì)影響應(yīng)用的相應(yīng)速度。
netstat -anp
此外，還可以使用tcpdump來具體分析網(wǎng)絡(luò)io的數(shù)據(jù)。當(dāng)然，tcpdump出的文件直接打開是一堆二進(jìn)制的數(shù)據(jù)，可以使用wireshark閱讀具體的連接以及其中數(shù)據(jù)的內(nèi)容。
tcpdump -i eth0 -w tmp.cap -tnn dst port 8080 #監(jiān)聽8080端口的網(wǎng)絡(luò)請(qǐng)求并打印日志到tmp.cap中
還可以通過查看/proc/interrupts來獲取當(dāng)前系統(tǒng)使用的中斷的情況。
各個(gè)列依次是：
irq的序號(hào)， 在各自cpu上發(fā)生中斷的次數(shù)，可編程中斷控制器，設(shè)備名稱（request_irq的dev_name字段）
通過查看網(wǎng)卡設(shè)備的終端情況可以判斷網(wǎng)絡(luò)io的狀況。
上面分別針對(duì)CPU、內(nèi)存以及IO講了一些系統(tǒng)/JDK自帶的分析工具。除此之外，還有一些綜合分析工具或者框架可以更加方便我們對(duì)Java應(yīng)用性能的排查、分析、定位等。
VisualVM
這個(gè)工具應(yīng)該是Java開發(fā)者們非常熟悉的一款java應(yīng)用監(jiān)測(cè)工具，原理是通過jmx接口來連接jvm進(jìn)程，從而能夠看到j(luò)vm上的線程、內(nèi)存、類等信息。
如果想進(jìn)一步查看gc情況，可以安裝visual gc插件。此外，visualvm也有btrace的插件，可以可視化直觀的編寫btrace代碼并查看輸出日志。 與VisualVm類似的，jconsole也是通過jmx查看遠(yuǎn)程jvm信息的一款工具，更進(jìn)一步的，通過它還可以顯示具體的線程堆棧信息以及內(nèi)存中各個(gè)年代的占用情況，也支持直接遠(yuǎn)程執(zhí)行MBEAN。當(dāng)然，visualvm通過安裝jconsole插件也可以擁有這些功能。
但由于這倆工具都是需要ui界面的，因此一般都是通過本地遠(yuǎn)程連接服務(wù)器jvm進(jìn)程。服務(wù)器環(huán)境下，一般并不用此種方式。
Java Mission Control(jmc)
此工具是jdk7 u40開始自帶的，原來是JRockit上的工具，是一款采樣型的集診斷、分析和監(jiān)控與一體的非常強(qiáng)大的工具:
https://docs.oracle.com/javacomponents/jmc-5-5/jmc-user-guide/toc.htm。但是此工具是基于JFR(jcmd
Btrace
這里不得不提的是btrace這個(gè)神器，它使用java attach api+ java agent + instrument api能夠?qū)崿F(xiàn)jvm的動(dòng)態(tài)追蹤。在不重啟應(yīng)用的情況下可以加入攔截類的方法以打印日志等。具體的用法可以參考 Btrace入門到熟練小工完全指南。
Jwebap
Jwebap是一款JavaEE性能檢測(cè)框架，基于asm增強(qiáng)字節(jié)碼實(shí)現(xiàn)。支持：http請(qǐng)求、jdbc連接、method的調(diào)用軌跡跟蹤以及次數(shù)、耗時(shí)的統(tǒng)計(jì)。由此可以獲取最耗時(shí)的請(qǐng)求、方法，并可以查看jdbc連接的次數(shù)、是否關(guān)閉等。但此項(xiàng)目是2006年的一個(gè)項(xiàng)目，已經(jīng)將近10年沒有更新。根據(jù)筆者使用，已經(jīng)不支持jdk7編譯的應(yīng)用。如果要使用，建議基于原項(xiàng)目二次開發(fā)，同時(shí)也可以加入對(duì)redis連接的軌跡跟蹤。當(dāng)然，基于字節(jié)碼增強(qiáng)的原理，也可以實(shí)現(xiàn)自己的JavaEE性能監(jiān)測(cè)框架。
上圖來自筆者公司二次開發(fā)過的jwebap，已經(jīng)支持jdk8和redis連接追蹤。
useful-scripts
這里有一個(gè)本人參與的開源的項(xiàng)目： https://github.com/superhj1987/useful-scripts，封裝了很多常用的性能分析命令，比如上文講的打印繁忙java線程堆棧信息，只需要執(zhí)行一個(gè)腳本即可。
與性能分析相對(duì)應(yīng)，性能調(diào)優(yōu)同樣分為三部分。
不要存在一直運(yùn)行的線程(無(wú)限while循環(huán))，可以使用sleep休眠一段時(shí)間。這種情況普遍存在于一些pull方式消費(fèi)數(shù)據(jù)的場(chǎng)景下，當(dāng)一次pull沒有拿到數(shù)據(jù)的時(shí)候建議sleep一下，再做下一次pull。
輪詢的時(shí)候可以使用wait/notify機(jī)制
避免循環(huán)、正則表達(dá)式匹配、計(jì)算過多，包括使用String的format、split、replace方法(可以使用apache的commons-lang里的StringUtils對(duì)應(yīng)的方法)，使用正則去判斷郵箱格式(有時(shí)候會(huì)造成死循環(huán))、序列/反序列化等。
結(jié)合jvm和代碼，避免產(chǎn)生頻繁的gc，尤其是full GC。
此外，使用多線程的時(shí)候，還需要注意以下幾點(diǎn)：
使用線程池，減少線程數(shù)以及線程的切換
多線程對(duì)于鎖的競(jìng)爭(zhēng)可以考慮減小鎖的粒度(使用ReetrantLock)、拆分鎖(類似ConcurrentHashMap分bucket上鎖), 或者使用CAS、ThreadLocal、不可變對(duì)象等無(wú)鎖技術(shù)。此外，多線程代碼的編寫最好使用jdk提供的并發(fā)包、Executors框架以及ForkJoin等，此外 Discuptor和 Actor在合適的場(chǎng)景也可以使用。
內(nèi)存的調(diào)優(yōu)主要就是對(duì)jvm的調(diào)優(yōu)。
合理設(shè)置各個(gè)代的大小。避免新生代設(shè)置過小(不夠用，經(jīng)常minor gc并進(jìn)入老年代)以及過大(會(huì)產(chǎn)生碎片)，同樣也要避免Survivor設(shè)置過大和過小。
選擇合適的GC策略。需要根據(jù)不同的場(chǎng)景選擇合適的gc策略。這里需要說的是，cms并非全能的。除非特別需要再設(shè)置，畢竟cms的新生代回收策略parnew并非最快的，且cms會(huì)產(chǎn)生碎片。此外，G1直到j(luò)dk8的出現(xiàn)也并沒有得到廣泛應(yīng)用，并不建議使用。
jvm啟動(dòng)參數(shù)配置-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:[log_path]，以記錄gc日志，便于排查問題。
其中，對(duì)于第一點(diǎn)，具體的還有一點(diǎn)建議：
年輕代大小選擇：響應(yīng)時(shí)間優(yōu)先的應(yīng)用，盡可能設(shè)大，直到接近系統(tǒng)的最低響應(yīng)時(shí)間限制（根據(jù)實(shí)際情況選擇）。在此種情況下，年輕代收集發(fā)生gc的頻率是最小的。同時(shí)，也能夠減少到達(dá)年老代的對(duì)象。吞吐量?jī)?yōu)先的應(yīng)用，也盡可能的設(shè)置大，因?yàn)閷?duì)響應(yīng)時(shí)間沒有要求，垃圾收集可以并行進(jìn)行，建議適合8CPU以上的應(yīng)用使用。
年老代大小選擇：響應(yīng)時(shí)間優(yōu)先的應(yīng)用，年老代一般都是使用并發(fā)收集器，所以其大小需要小心設(shè)置，一般要考慮并發(fā)會(huì)話率和會(huì)話持續(xù)時(shí)間等一些參數(shù)。如果堆設(shè)置小了，會(huì)造成內(nèi)存碎片、高回收頻率以及應(yīng)用暫停而使用傳統(tǒng)的標(biāo)記清除方式；如果堆大了，則需要較長(zhǎng)的收集時(shí)間。最優(yōu)化的方案，一般需要參考以下數(shù)據(jù)獲得：
一般吞吐量?jī)?yōu)先的應(yīng)用都應(yīng)該有一個(gè)很大的年輕代和一個(gè)較小的年老代。這樣可以盡可能回收掉大部分短期對(duì)象，減少中期的對(duì)象，而年老代存放長(zhǎng)期存活對(duì)象。
并發(fā)垃圾收集信息
持久代并發(fā)收集次數(shù)
傳統(tǒng)GC信息
花在年輕代和年老代回收上的時(shí)間比例
此外，較小堆引起的碎片問題：因?yàn)槟昀洗牟l(fā)收集器使用標(biāo)記、清除算法，所以不會(huì)對(duì)堆進(jìn)行壓縮。當(dāng)收集器回收時(shí)，會(huì)把相鄰的空間進(jìn)行合并，這樣可以分配給較大的對(duì)象。但是，當(dāng)堆空間較小時(shí)，運(yùn)行一段時(shí)間以后，就會(huì)出現(xiàn)“碎片”，如果并發(fā)收集器找不到足夠的空間，那么并發(fā)收集器將會(huì)停止，然后使用傳統(tǒng)的標(biāo)記、清除方式進(jìn)行回收。如果出現(xiàn)“碎片”，可能需要進(jìn)行如下配置：-XX:+UseCMSCompactAtFullCollection，使用并發(fā)收集器時(shí)，開啟對(duì)年老代的壓縮。同時(shí)使用-XX:CMSFullGCsBeforeCompaction=xx設(shè)置多少次Full GC后，對(duì)年老代進(jìn)行壓縮。
其余對(duì)于jvm的優(yōu)化問題可見后面JVM參數(shù)進(jìn)階一節(jié)。
代碼上，也需要注意：
避免保存重復(fù)的String對(duì)象，同時(shí)也需要小心String.subString()與String.intern()的使用，尤其是后者其底層數(shù)據(jù)結(jié)構(gòu)為StringTable，當(dāng)字符串大量不重復(fù)時(shí)，會(huì)使得StringTable非常大(一個(gè)固定大小的hashmap，可以由參數(shù)-XX:StringTableSize=N設(shè)置大小)，從而影響young gc的速度。在jackson和fastjson中使用了此方法，某些場(chǎng)景下會(huì)引起gc問題: YGC越來越慢，為什么。
盡量不要使用finalizer
釋放不必要的引用：ThreadLocal使用完記得釋放以防止內(nèi)存泄漏，各種stream使用完也記得close。
使用對(duì)象池避免無(wú)節(jié)制創(chuàng)建對(duì)象，造成頻繁gc。但不要隨便使用對(duì)象池，除非像連接池、線程池這種初始化/創(chuàng)建資源消耗較大的場(chǎng)景，
緩存失效算法，可以考慮使用SoftReference、WeakReference保存緩存對(duì)象
謹(jǐn)慎熱部署/加載的使用，尤其是動(dòng)態(tài)加載類等
不要用Log4j輸出文件名、行號(hào)，因?yàn)長(zhǎng)og4j通過打印線程堆棧實(shí)現(xiàn)，生成大量String。此外，使用log4j時(shí)，建議此種經(jīng)典用法，先判斷對(duì)應(yīng)級(jí)別的日志是否打開，再做操作，否則也會(huì)生成大量String。
重慶分公司
重慶分公司
if (logger.isInfoEnabled()) {
logger.info(msg);
}文件IO上需要注意：
考慮使用異步寫入代替同步寫入，可以借鑒redis的aof機(jī)制。
利用緩存，減少隨機(jī)讀
盡量批量寫入，減少io次數(shù)和尋址
使用數(shù)據(jù)庫(kù)代替文件存儲(chǔ)
網(wǎng)絡(luò)IO上需要注意：
和文件IO類似，使用異步IO、多路復(fù)用IO/事件驅(qū)動(dòng)IO代替同步阻塞IO
批量進(jìn)行網(wǎng)絡(luò)IO,減少IO次數(shù)
使用緩存，減少對(duì)網(wǎng)絡(luò)數(shù)據(jù)的讀取
使用協(xié)程: Quasar
算法、邏輯上是程序性能的首要，遇到性能問題，應(yīng)該首先優(yōu)化程序的邏輯處理
優(yōu)先考慮使用返回值而不是異常表示錯(cuò)誤
查看自己的代碼是否對(duì)內(nèi)聯(lián)是友好的: 你的Java代碼對(duì)JIT編譯友好么？
此外，jdk7、8在jvm的性能上做了一些增強(qiáng)：
通過-XX:+TieredCompilation開啟JDK7的 多層編譯（tiered compilation）支持。多層編譯結(jié)合了客戶端C1編譯器和服務(wù)端C2編譯器的優(yōu)點(diǎn)(客戶端編譯能夠快速啟動(dòng)和及時(shí)優(yōu)化，服務(wù)器端編譯可以提供更多的高級(jí)優(yōu)化)，是一個(gè)非常高效利用資源的切面方案。在開始時(shí)先進(jìn)行低層次的編譯，同時(shí)收集信息，在后期再進(jìn)一步進(jìn)行高層次的編譯進(jìn)行高級(jí)優(yōu)化。需要注意的一點(diǎn)：這個(gè)參數(shù)會(huì)消耗比較多的內(nèi)存資源，因?yàn)橥粋€(gè)方法被編譯了多次，存在多份native內(nèi)存拷貝，建議把code cache調(diào)大一點(diǎn)兒（-XX:+ReservedCodeCacheSize，InitialCodeCacheSize）。否則有可能由于code cache不足，jit編譯的時(shí)候不停的嘗試清理code cache，丟棄無(wú)用方法，消耗大量資源在jit線程上。
Compressed Oops：壓縮指針在jdk7中的server模式下已經(jīng)默認(rèn)開啟。
Zero-Based Compressed Ordinary Object Pointers：當(dāng)使用了上述的壓縮指針時(shí)，在64位jvm上，會(huì)要求操作系統(tǒng)保留從一個(gè)虛擬地址0開始的內(nèi)存。如果操作系統(tǒng)支持這種請(qǐng)求，那么就開啟了Zero-Based Compressed Oops。這樣可以使得無(wú)須在java堆的基地址添加任何地址補(bǔ)充即可把一個(gè)32位對(duì)象的偏移解碼成64位指針。
逃逸分析(Escape Analysis): Server模式的編譯器會(huì)根據(jù)代碼的情況，來判斷相關(guān)對(duì)象的逃逸類型，從而決定是否在堆中分配空間，是否進(jìn)行標(biāo)量替換(在棧上分配原子類型局部變量)。此外，也可以根據(jù)調(diào)用情況來決定是否自動(dòng)消除同步控制，如StringBuffer。這個(gè)特性從Java SE 6u23開始就默認(rèn)開啟。
NUMA Collector Enhancements：這個(gè)重要針對(duì)的是The Parallel Scavenger垃圾回收器。使其能夠利用NUMA (Non Uniform Memory Access，即每一個(gè)處理器核心都有本地內(nèi)存，能夠低延遲、高帶寬訪問) 架構(gòu)的機(jī)器的優(yōu)勢(shì)來更快的進(jìn)行g(shù)c?？梢酝ㄟ^-XX:+UseNUMA開啟支持。
此外，網(wǎng)上還有很多過時(shí)的建議，不要再盲目跟隨:
變量用完設(shè)置為null，加快內(nèi)存回收，這種用法大部分情況下并沒有意義。一種情況除外：如果有個(gè)Java方法沒有被JIT編譯但里面仍然有代碼會(huì)執(zhí)行比較長(zhǎng)時(shí)間，那么在那段會(huì)執(zhí)行長(zhǎng)時(shí)間的代碼前顯式將不需要的引用類型局部變量置null是可取的。具體的可以見R大的解釋： https://www.zhihu.com/question/48059457/answer/113538171
方法參數(shù)設(shè)置為final，這種用法也沒有太大的意義，尤其在jdk8中引入了effective final，會(huì)自動(dòng)識(shí)別final變量。
jvm的參數(shù)設(shè)置一直是比較理不清的地方，很多時(shí)候都搞不清都有哪些參數(shù)可以配置，參數(shù)是什么意思，為什么要這么配置等。這里主要針對(duì)這些做一些常識(shí)性的說明以及對(duì)一些容易讓人進(jìn)入陷阱的參數(shù)做一些解釋。
以下所有都是針對(duì)Oracle/Sun JDK 6來講
啟動(dòng)參數(shù)默認(rèn)值
Java有很多的啟動(dòng)參數(shù)，而且很多版本都并不一樣。但是現(xiàn)在網(wǎng)上充斥著各種資料，如果不加辨別的全部使用，很多是沒有效果或者本來就是默認(rèn)值的。一般的，我們可以通過使用java -XX:+PrintFlagsInitial來查看所有可以設(shè)置的參數(shù)以及其默認(rèn)值。也可以在程序啟動(dòng)的時(shí)候加入-XX:+PrintCommandLineFlags來查看與默認(rèn)值不相同的啟動(dòng)參數(shù)。如果想查看所有啟動(dòng)參數(shù)(包括和默認(rèn)值相同的)，可以使用-XX:+PrintFlagsFinal。
輸出里“=”表示使用的是初始默認(rèn)值，而“:=”表示使用的不是初始默認(rèn)值，可能是命令行傳進(jìn)來的參數(shù)、配置文件里的參數(shù)或者是 ergonomics自動(dòng)選擇了別的值。
此外，還可以使用jinfo命令顯示啟動(dòng)的參數(shù)。
這里需要指出的是，當(dāng)你配置jvm參數(shù)時(shí)，最好是先通過以上命令查看對(duì)應(yīng)參數(shù)的默認(rèn)值再確定是否需要設(shè)置。也最好不要配置你搞不清用途的參數(shù)，畢竟默認(rèn)值的設(shè)置是有它的合理之處的。
jinfo -flags [pid] #查看目前啟動(dòng)使用的有效參數(shù)
jinfo -flag [flagName] [pid] #查看對(duì)應(yīng)參數(shù)的值
動(dòng)態(tài)設(shè)置參數(shù)
當(dāng)Java應(yīng)用啟動(dòng)后，定位到了是GC造成的性能問題，但是你啟動(dòng)的時(shí)候并沒有加入打印gc的參數(shù)，很多時(shí)候的做法就是重新加參數(shù)然后重啟應(yīng)用。但這樣會(huì)造成一定時(shí)間的服務(wù)不可用。最佳的做法是能夠在不重啟應(yīng)用的情況下，動(dòng)態(tài)設(shè)置參數(shù)。使用jinfo可以做到這一點(diǎn)(本質(zhì)上還是基于jmx的)。
jinfo -flag [+/-][flagName] [pid] #啟用/禁止某個(gè)參數(shù) jinfo -flag [flagName=value] [pid] #設(shè)置某個(gè)參數(shù)
對(duì)于上述的gc的情況，就可以使用以下命令打開heap dump并設(shè)置dump路徑。
jinfo -flag +HeapDumpBeforeFullGC [pid] jinfo -flag +HeapDumpAfterFullGC [pid] jinfo -flag HeapDumpPath=/home/dump/dir [pid]
同樣的也可以動(dòng)態(tài)關(guān)閉。
jinfo -flag -HeapDumpBeforeFullGC [pid] jinfo -flag -HeapDumpAfterFullGC [pid]
其他的參數(shù)設(shè)置類似。
-verbose:gc 與 -XX:+PrintGCDetails
很多gc推薦設(shè)置都同時(shí)設(shè)置了這兩個(gè)參數(shù)，其實(shí)，只要打開了-XX:+PrintGCDetails，前面的選項(xiàng)也會(huì)同時(shí)打開，無(wú)須重復(fù)設(shè)置。
-XX:+DisableExplicitGC
這個(gè)參數(shù)的作用就是使得system.gc變?yōu)榭照{(diào)用，很多推薦設(shè)置里面都是建議開啟的。但是，如果你用到了NIO或者其他使用到堆外內(nèi)存的情況，使用此選項(xiàng)會(huì)造成oom?？梢杂肵X:+ExplicitGCInvokesConcurrent或XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses(配合CMS使用，使得system.gc觸發(fā)一次并發(fā)gc)代替。
此外，還有一個(gè)比較有意思的地方。如果你不設(shè)置此選項(xiàng)的話，當(dāng)你使用了RMI的時(shí)候，會(huì)周期性地來一次full gc。這個(gè)現(xiàn)象是由于分布式gc造成的，為RMI服務(wù)。
此參數(shù)是設(shè)置的堆外內(nèi)存的上限值。當(dāng)不設(shè)置的時(shí)候?yàn)?1，此值為-Xmx減去一個(gè)survivor space的預(yù)留大小。
由于遺留原因，作用相同的參數(shù)
-Xss 與 -XX:ThreadStackSize
-Xmn 與 -XX:NewSize，此外這里需要注意的是設(shè)置了-Xmn的話，NewRatio就沒作用了。
-XX:MaxTenuringThreshold
使用工具查看此值默認(rèn)值為15，但是選擇了CMS的時(shí)候，此值會(huì)變成4。當(dāng)此值設(shè)置為0時(shí)，所有eden里的活對(duì)象在經(jīng)歷第一次minor GC的時(shí)候就會(huì)直接晉升到old gen，survivor space直接就沒用。還有值得注意的一點(diǎn)，當(dāng)使用并行回收器時(shí)，此值是沒有作用的，并行回收器默認(rèn)是自動(dòng)調(diào)整這些參數(shù)以求達(dá)到吞吐量最大的。此外，即使是使用CMS等回收器，晉升到老年代的age也不是不變的，當(dāng)某一age的對(duì)象的大小達(dá)到年輕代的50%時(shí)，這個(gè)age會(huì)被動(dòng)態(tài)調(diào)整為晉升年齡。
-XX:HeapDumpPath
使用此參數(shù)可以指定-XX:+HeapDumpBeforeFullGC、-XX:+HeapDumpAfterFullGC、-XX:+HeapDumpOnOutOfMemoryError觸發(fā)heap dump文件的存儲(chǔ)位置。
-XX:+UseAdaptiveSizePolicy
此參數(shù)在并行回收器時(shí)是默認(rèn)開啟的，會(huì)根據(jù)應(yīng)用運(yùn)行狀況做自我調(diào)整，如MaxTenuringThreshold、survivor區(qū)大小等。其中第一次晉升老年代的年齡以InitialTenuringThreshold（默認(rèn)為7）開始，后續(xù)會(huì)自動(dòng)調(diào)整。如果希望跟蹤每次minor GC后新的存活周期的閾值，可在啟動(dòng)參數(shù)上增加：-XX:+PrintTenuringDistribution。如果想要可以配置這些參數(shù)，可以關(guān)閉此選項(xiàng)，但paralle的性能很難達(dá)到最佳。其他垃圾回收期則慎重開啟此開關(guān)。
“JVM常用參數(shù)調(diào)優(yōu)方法是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！
