JVM常用參數(shù)調(diào)優(yōu)方法是什么-創(chuàng)新互聯(lián)

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

成都創(chuàng)新互聯(lián)是一家專(zhuān)注于成都網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)與策劃設(shè)計(jì),涇源網(wǎng)站建設(shè)哪家好?成都創(chuàng)新互聯(lián)做網(wǎng)站,專(zhuān)注于網(wǎng)站建設(shè)十余年,網(wǎng)設(shè)計(jì)領(lǐng)域的專(zhuān)業(yè)建站公司;建站業(yè)務(wù)涵蓋:涇源等地區(qū)。涇源做網(wǎng)站價(jià)格咨詢:18982081108

對(duì)于調(diào)優(yōu)這個(gè)事情來(lái)說(shuō)，一般就是三個(gè)過(guò)程：

性能監(jiān)控：?jiǎn)栴}沒(méi)有發(fā)生，你并不知道你需要調(diào)優(yōu)什么。此時(shí)需要一些系統(tǒng)、應(yīng)用的監(jiān)控工具來(lái)發(fā)現(xiàn)問(wèn)題。
性能分析：?jiǎn)栴}已經(jīng)發(fā)生，但是你并不知道問(wèn)題到底出在哪里。此時(shí)就需要使用工具、經(jīng)驗(yàn)對(duì)系統(tǒng)、應(yīng)用進(jìn)行瓶頸分析，以求定位到問(wèn)題原因。
性能調(diào)優(yōu)：經(jīng)過(guò)上一步的分析定位到了問(wèn)題所在，需要對(duì)問(wèn)題進(jìn)行解決，使用代碼、配置等手段進(jìn)行優(yōu)化。

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

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

系統(tǒng)底層環(huán)境：硬件、操作系統(tǒng)等
數(shù)據(jù)結(jié)構(gòu)和算法的使用
外部系統(tǒng)如數(shù)據(jù)庫(kù)、緩存的使用

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

調(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)境來(lái)測(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)行程序的性能瓶頸分析。

CPU分析

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

線程中有無(wú)限空循環(huán)、無(wú)阻塞、正則匹配或者單純的計(jì)算
發(fā)生了頻繁的gc
多線程的上下文切換

確定好cpu使用率最高的進(jìn)程之后就可以使用jstack來(lái)打印出異常進(jìn)程的堆棧信息：

jstack [pid]

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

接下來(lái)需要注意的一點(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來(lái)查看，也可以直接通過(guò)ps -Le來(lái)顯示所有進(jìn)程,包括LWP的資源耗費(fèi)信息。最后，通過(guò)在jstack的輸出文件中查找對(duì)應(yīng)的LWP的id即可以定位到相應(yīng)的堆棧信息。其中需要注意的是線程的狀態(tài)：RUNNABLE、WAITING等。對(duì)于Runnable的進(jìn)程需要注意是否有耗費(fèi)cpu的計(jì)算。對(duì)于Waiting的線程一般是鎖的等待操作。

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

jstat -gcutil [pid]

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

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

vmstat 1 5

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

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

內(nèi)存分析

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

堆外內(nèi)存
堆外內(nèi)存主要是JNI、Deflater/Inflater、DirectByteBuffer（nio中會(huì)用到）使用的。對(duì)于這種堆外內(nèi)存的分析，還是需要先通過(guò)vmstat、sar、top、pidstat(這里的sar,pidstat以及iostat都是 sysstat軟件套件的一部分，需要單獨(dú)安裝)等查看swap和物理內(nèi)存的消耗狀況再做判斷的。此外，對(duì)于JNI、Deflater這種調(diào)用可以通過(guò) Google-preftools來(lái)追蹤資源使用狀況。
堆內(nèi)內(nèi)存
此部分內(nèi)存為Java應(yīng)用主要的內(nèi)存區(qū)域。通常與這部分內(nèi)存性能相關(guān)的有：
以上使用不當(dāng)很容易造成：
排查堆內(nèi)存問(wèn)題的常用工具是jmap，是jdk自帶的。一些常用用法如下：
此外，不管是使用jmap還是在OOM時(shí)產(chǎn)生的dump文件，可以使用Eclipse的MAT(MEMORY ANALYZER TOOL)來(lái)分析，可以看到具體的堆棧和內(nèi)存中對(duì)象的信息。當(dāng)然jdk自帶的jhat也能夠查看dump文件(啟動(dòng)web端口供開(kāi)發(fā)者使用瀏覽器瀏覽堆內(nèi)對(duì)象的信息)。此外，VisualVM也能夠打開(kāi)hprof文件，使用它的heap walker查看堆內(nèi)存信息。

查看jvm內(nèi)存使用狀況：jmap -heap
查看jvm內(nèi)存存活的對(duì)象：jmap -histo:live
把heap里所有對(duì)象都dump下來(lái)，無(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：本地線程沒(méi)有足夠內(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)加載類(lèi)容易造成永久代內(nèi)存不足
多線程：線程分配會(huì)占用本地內(nèi)存，過(guò)多的線程也會(huì)造成內(nèi)存不足

IO分析

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

文件IO
可以使用系統(tǒng)工具pidstat、iostat、vmstat來(lái)查看io的狀況。這里可以看一張使用vmstat的結(jié)果圖。
這里主要注意bi和bo這兩個(gè)值，分別表示塊設(shè)備每秒接收的塊數(shù)量和塊設(shè)備每秒發(fā)送的塊數(shù)量，由此可以判定io繁忙狀況。進(jìn)一步的可以通過(guò)使用strace工具定位對(duì)文件io的系統(tǒng)調(diào)用。通常，造成文件io性能差的原因不外乎：

大量的隨機(jī)讀寫(xiě)
設(shè)備慢
文件太大

網(wǎng)絡(luò)IO
查看網(wǎng)絡(luò)io狀況，一般使用的是netstat工具?？梢圆榭此羞B接的狀況、數(shù)目、端口信息等。例如：當(dāng)time_wait或者close_wait連接過(guò)多時(shí)，會(huì)影響應(yīng)用的相應(yīng)速度。
```
 netstat -anp
```
此外，還可以使用tcpdump來(lái)具體分析網(wǎng)絡(luò)io的數(shù)據(jù)。當(dāng)然，tcpdump出的文件直接打開(kāi)是一堆二進(jìn)制的數(shù)據(jù)，可以使用wireshark閱讀具體的連接以及其中數(shù)據(jù)的內(nèi)容。
```
 tcpdump -i eth0 -w tmp.cap -tnn dst port 8080 #監(jiān)聽(tīng)8080端口的網(wǎng)絡(luò)請(qǐng)求并打印日志到tmp.cap中
```
還可以通過(guò)查看/proc/interrupts來(lái)獲取當(dāng)前系統(tǒng)使用的中斷的情況。
各個(gè)列依次是：
```
 irq的序號(hào)， 在各自cpu上發(fā)生中斷的次數(shù)，可編程中斷控制器，設(shè)備名稱(chēng)（request_irq的dev_name字段）
```
通過(guò)查看網(wǎng)卡設(shè)備的終端情況可以判斷網(wǎng)絡(luò)io的狀況。

其他分析工具

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

VisualVM
這個(gè)工具應(yīng)該是Java開(kāi)發(fā)者們非常熟悉的一款java應(yīng)用監(jiān)測(cè)工具，原理是通過(guò)jmx接口來(lái)連接jvm進(jìn)程，從而能夠看到j(luò)vm上的線程、內(nèi)存、類(lèi)等信息。如果想進(jìn)一步查看gc情況，可以安裝visual gc插件。此外，visualvm也有btrace的插件，可以可視化直觀的編寫(xiě)btrace代碼并查看輸出日志。與VisualVm類(lèi)似的，jconsole也是通過(guò)jmx查看遠(yuǎn)程jvm信息的一款工具，更進(jìn)一步的，通過(guò)它還可以顯示具體的線程堆棧信息以及內(nèi)存中各個(gè)年代的占用情況，也支持直接遠(yuǎn)程執(zhí)行MBEAN。當(dāng)然，visualvm通過(guò)安裝jconsole插件也可以擁有這些功能。但由于這倆工具都是需要ui界面的，因此一般都是通過(guò)本地遠(yuǎn)程連接服務(wù)器jvm進(jìn)程。服務(wù)器環(huán)境下，一般并不用此種方式。
Java Mission Control(jmc)
此工具是jdk7 u40開(kāi)始自帶的，原來(lái)是JRockit上的工具，是一款采樣型的集診斷、分析和監(jiān)控與一體的非常強(qiáng)大的工具: 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)的，而開(kāi)啟JFR需要商業(yè)證書(shū)：jcmdVM.unlock_commercial_features。
Btrace
這里不得不提的是btrace這個(gè)神器，它使用java attach api+ java agent + instrument api能夠?qū)崿F(xiàn)jvm的動(dòng)態(tài)追蹤。在不重啟應(yīng)用的情況下可以加入攔截類(lèi)的方法以打印日志等。具體的用法可以參考 Btrace入門(mén)到熟練小工完全指南。
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年沒(méi)有更新。根據(jù)筆者使用，已經(jīng)不支持jdk7編譯的應(yīng)用。如果要使用，建議基于原項(xiàng)目二次開(kāi)發(fā)，同時(shí)也可以加入對(duì)redis連接的軌跡跟蹤。當(dāng)然，基于字節(jié)碼增強(qiáng)的原理，也可以實(shí)現(xiàn)自己的JavaEE性能監(jiān)測(cè)框架。
上圖來(lái)自筆者公司二次開(kāi)發(fā)過(guò)的jwebap，已經(jīng)支持jdk8和redis連接追蹤。
useful-scripts
這里有一個(gè)本人參與的開(kāi)源的項(xiàng)目： https://github.com/superhj1987/useful-scripts，封裝了很多常用的性能分析命令，比如上文講的打印繁忙java線程堆棧信息，只需要執(zhí)行一個(gè)腳本即可。

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

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

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

不要存在一直運(yùn)行的線程(無(wú)限while循環(huán))，可以使用sleep休眠一段時(shí)間。這種情況普遍存在于一些pull方式消費(fèi)數(shù)據(jù)的場(chǎng)景下，當(dāng)一次pull沒(méi)有拿到數(shù)據(jù)的時(shí)候建議sleep一下，再做下一次pull。
輪詢的時(shí)候可以使用wait/notify機(jī)制
避免循環(huán)、正則表達(dá)式匹配、計(jì)算過(guò)多，包括使用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)、拆分鎖(類(lèi)似ConcurrentHashMap分bucket上鎖), 或者使用CAS、ThreadLocal、不可變對(duì)象等無(wú)鎖技術(shù)。此外，多線程代碼的編寫(xiě)最好使用jdk提供的并發(fā)包、Executors框架以及ForkJoin等，此外 Discuptor和 Actor在合適的場(chǎng)景也可以使用。

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

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

合理設(shè)置各個(gè)代的大小。避免新生代設(shè)置過(guò)小(不夠用，經(jīng)常minor gc并進(jìn)入老年代)以及過(guò)大(會(huì)產(chǎn)生碎片)，同樣也要避免Survivor設(shè)置過(guò)大和過(guò)小。
選擇合適的GC策略。需要根據(jù)不同的場(chǎng)景選擇合適的gc策略。這里需要說(shuō)的是，cms并非全能的。除非特別需要再設(shè)置，畢竟cms的新生代回收策略parnew并非最快的，且cms會(huì)產(chǎn)生碎片。此外，G1直到j(luò)dk8的出現(xiàn)也并沒(méi)有得到廣泛應(yīng)用，并不建議使用。
jvm啟動(dòng)參數(shù)配置-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:[log_path]，以記錄gc日志，便于排查問(wèn)題。

其中，對(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í)間沒(méi)有要求，垃圾收集可以并行進(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í)間比例

此外，較小堆引起的碎片問(wèn)題：因?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í)，開(kāi)啟對(duì)年老代的壓縮。同時(shí)使用-XX:CMSFullGCsBeforeCompaction=xx設(shè)置多少次Full GC后，對(duì)年老代進(jìn)行壓縮。

其余對(duì)于jvm的優(yōu)化問(wèn)題可見(jiàn)后面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問(wèn)題: YGC越來(lái)越慢，為什么。
盡量不要使用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)加載類(lèi)等
不要用Log4j輸出文件名、行號(hào)，因?yàn)長(zhǎng)og4j通過(guò)打印線程堆棧實(shí)現(xiàn)，生成大量String。此外，使用log4j時(shí)，建議此種經(jīng)典用法，先判斷對(duì)應(yīng)級(jí)別的日志是否打開(kāi)，再做操作，否則也會(huì)生成大量String。
```
  if (logger.isInfoEnabled()) {
      logger.info(msg);
  }
```

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

文件IO上需要注意：

考慮使用異步寫(xiě)入代替同步寫(xiě)入，可以借鑒redis的aof機(jī)制。
利用緩存，減少隨機(jī)讀
盡量批量寫(xiě)入，減少io次數(shù)和尋址
使用數(shù)據(jù)庫(kù)代替文件存儲(chǔ)

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

和文件IO類(lèi)似，使用異步IO、多路復(fù)用IO/事件驅(qū)動(dòng)IO代替同步阻塞IO
批量進(jìn)行網(wǎng)絡(luò)IO,減少I(mǎi)O次數(shù)
使用緩存，減少對(duì)網(wǎng)絡(luò)數(shù)據(jù)的讀取
使用協(xié)程: Quasar

其他優(yōu)化建議

算法、邏輯上是程序性能的首要，遇到性能問(wèn)題，應(yīng)該首先優(yōu)化程序的邏輯處理
優(yōu)先考慮使用返回值而不是異常表示錯(cuò)誤
查看自己的代碼是否對(duì)內(nèi)聯(lián)是友好的: 你的Java代碼對(duì)JIT編譯友好么？

此外，jdk7、8在jvm的性能上做了一些增強(qiáng)：

通過(guò)-XX:+TieredCompilation開(kāi)啟JDK7的多層編譯（tiered compilation）支持。多層編譯結(jié)合了客戶端C1編譯器和服務(wù)端C2編譯器的優(yōu)點(diǎn)(客戶端編譯能夠快速啟動(dòng)和及時(shí)優(yōu)化，服務(wù)器端編譯可以提供更多的高級(jí)優(yōu)化)，是一個(gè)非常高效利用資源的切面方案。在開(kāi)始時(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)開(kāi)啟。
Zero-Based Compressed Ordinary Object Pointers：當(dāng)使用了上述的壓縮指針時(shí)，在64位jvm上，會(huì)要求操作系統(tǒng)保留從一個(gè)虛擬地址0開(kāi)始的內(nèi)存。如果操作系統(tǒng)支持這種請(qǐng)求，那么就開(kāi)啟了Zero-Based Compressed Oops。這樣可以使得無(wú)須在java堆的基地址添加任何地址補(bǔ)充即可把一個(gè)32位對(duì)象的偏移解碼成64位指針。
逃逸分析(Escape Analysis): Server模式的編譯器會(huì)根據(jù)代碼的情況，來(lái)判斷相關(guān)對(duì)象的逃逸類(lèi)型，從而決定是否在堆中分配空間，是否進(jìn)行標(biāo)量替換(在棧上分配原子類(lèi)型局部變量)。此外，也可以根據(jù)調(diào)用情況來(lái)決定是否自動(dòng)消除同步控制，如StringBuffer。這個(gè)特性從Java SE 6u23開(kāi)始就默認(rèn)開(kāi)啟。
NUMA Collector Enhancements：這個(gè)重要針對(duì)的是The Parallel Scavenger垃圾回收器。使其能夠利用NUMA (Non Uniform Memory Access，即每一個(gè)處理器核心都有本地內(nèi)存，能夠低延遲、高帶寬訪問(wèn)) 架構(gòu)的機(jī)器的優(yōu)勢(shì)來(lái)更快的進(jìn)行g(shù)c?？梢酝ㄟ^(guò)-XX:+UseNUMA開(kāi)啟支持。

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

變量用完設(shè)置為null，加快內(nèi)存回收，這種用法大部分情況下并沒(méi)有意義。一種情況除外：如果有個(gè)Java方法沒(méi)有被JIT編譯但里面仍然有代碼會(huì)執(zhí)行比較長(zhǎng)時(shí)間，那么在那段會(huì)執(zhí)行長(zhǎng)時(shí)間的代碼前顯式將不需要的引用類(lèi)型局部變量置null是可取的。具體的可以見(jiàn)R大的解釋?zhuān)?https://www.zhihu.com/question/48059457/answer/113538171
方法參數(shù)設(shè)置為final，這種用法也沒(méi)有太大的意義，尤其在jdk8中引入了effective final，會(huì)自動(dòng)識(shí)別final變量。

JVM參數(shù)進(jìn)階

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

以下所有都是針對(duì)Oracle/Sun JDK 6來(lái)講

啟動(dòng)參數(shù)默認(rèn)值
Java有很多的啟動(dòng)參數(shù)，而且很多版本都并不一樣。但是現(xiàn)在網(wǎng)上充斥著各種資料，如果不加辨別的全部使用，很多是沒(méi)有效果或者本來(lái)就是默認(rèn)值的。一般的，我們可以通過(guò)使用java -XX:+PrintFlagsInitial來(lái)查看所有可以設(shè)置的參數(shù)以及其默認(rèn)值。也可以在程序啟動(dòng)的時(shí)候加入-XX:+PrintCommandLineFlags來(lái)查看與默認(rèn)值不相同的啟動(dòng)參數(shù)。如果想查看所有啟動(dòng)參數(shù)(包括和默認(rèn)值相同的)，可以使用-XX:+PrintFlagsFinal。
輸出里“=”表示使用的是初始默認(rèn)值，而“:=”表示使用的不是初始默認(rèn)值，可能是命令行傳進(jìn)來(lái)的參數(shù)、配置文件里的參數(shù)或者是 ergonomics自動(dòng)選擇了別的值。
此外，還可以使用jinfo命令顯示啟動(dòng)的參數(shù)。
這里需要指出的是，當(dāng)你配置jvm參數(shù)時(shí)，最好是先通過(guò)以上命令查看對(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造成的性能問(wèn)題，但是你啟動(dòng)的時(shí)候并沒(méi)有加入打印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的情況，就可以使用以下命令打開(kāi)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è)置類(lèi)似。
-verbose:gc 與 -XX:+PrintGCDetails
很多gc推薦設(shè)置都同時(shí)設(shè)置了這兩個(gè)參數(shù)，其實(shí)，只要打開(kāi)了-XX:+PrintGCDetails，前面的選項(xiàng)也會(huì)同時(shí)打開(kāi)，無(wú)須重復(fù)設(shè)置。
-XX:+DisableExplicitGC
這個(gè)參數(shù)的作用就是使得system.gc變?yōu)榭照{(diào)用，很多推薦設(shè)置里面都是建議開(kāi)啟的。但是，如果你用到了NIO或者其他使用到堆外內(nèi)存的情況，使用此選項(xiàng)會(huì)造成oom。可以用XX:+ExplicitGCInvokesConcurrent或XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses(配合CMS使用，使得system.gc觸發(fā)一次并發(fā)gc)代替。
此外，還有一個(gè)比較有意思的地方。如果你不設(shè)置此選項(xiàng)的話，當(dāng)你使用了RMI的時(shí)候，會(huì)周期性地來(lái)一次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就沒(méi)作用了。

-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直接就沒(méi)用。還有值得注意的一點(diǎn)，當(dāng)使用并行回收器時(shí)，此值是沒(méi)有作用的，并行回收器默認(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)開(kāi)啟的，會(huì)根據(jù)應(yīng)用運(yùn)行狀況做自我調(diào)整，如MaxTenuringThreshold、survivor區(qū)大小等。其中第一次晉升老年代的年齡以InitialTenuringThreshold（默認(rèn)為7）開(kāi)始，后續(xù)會(huì)自動(dòng)調(diào)整。如果希望跟蹤每次minor GC后新的存活周期的閾值，可在啟動(dòng)參數(shù)上增加：-XX:+PrintTenuringDistribution。如果想要可以配置這些參數(shù)，可以關(guān)閉此選項(xiàng)，但paralle的性能很難達(dá)到最佳。其他垃圾回收期則慎重開(kāi)啟此開(kāi)關(guān)。

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

本文題目：JVM常用參數(shù)調(diào)優(yōu)方法是什么-創(chuàng)新互聯(lián)
網(wǎng)頁(yè)網(wǎng)址：http://jinyejixie.com/article14/jgcde.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供App設(shè)計(jì)、網(wǎng)站內(nèi)鏈、建站公司、面包屑導(dǎo)航、手機(jī)網(wǎng)站建設(shè)、定制開(kāi)發(fā)

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源：創(chuàng)新互聯(lián)

猜你還喜歡下面的內(nèi)容

成人午夜视频全免费观看高清-秋霞福利视频一区二区三区-国产精品久久久久电影小说-亚洲不卡区三一区三区一区

JVM常用參數(shù)調(diào)優(yōu)方法是什么-創(chuàng)新互聯(lián)

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

性能分析

CPU分析

內(nèi)存分析

IO分析

其他分析工具

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

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

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

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

其他優(yōu)化建議

JVM參數(shù)進(jìn)階