❶ tomcat最大連接數和jvm參數怎麼配置比較合理
jvm內存有好幾種呢 windows下修改JVM內存大小: 情況一:解壓版本的Tomcat, 要通過startup.bat啟動tomcat才能載入配置 要添加在tomcat 的bin 下catalina.bat 里 rem Guess CATALINA_HOME if not defined set CURRENT_DIR=%cd%後面添加,紅色的為新添加的. set JAVA_OPTS=-Xms256m -Xmx512m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m -Djava.awt.headless=true 情況二:安裝版的Tomcat下沒有catalina.bat windows服務執行的是bin\tomcat.exe.他讀取注冊表中的值,而不是catalina.bat的設置. 修改注冊表HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Tomcat Service Manager\Tomcat5\Parameters\JavaOptions 原值為 -Dcatalina.home="C:\ApacheGroup\Tomcat 5.0" -Djava.endorsed.dirs="C:\ApacheGroup\Tomcat 5.0\common\endorsed" -Xrs 加入 -Xms300m -Xmx350m 重起tomcat服務,設置生效 jvm參數說明： -server 一定要作為第一個參數，啟用JDK的server版本，在多個CPU時性能佳 -Xms java Heap初始大小。 默認是物理內存的1/64。 -Xmx java heap最大值。建議均設為物理內存的80%。不可超過物理內存。 -Xmn java heap最小值，一般設置為Xmx的3、4分之一。 -XX:PermSize 設定內存的永久保存區初始大小，預設值為64M。 -XX:MaxPermSize 設定內存的永久保存區最大大小，預設值為64M。 -XX:SurvivorRatio=2 生還者池的大小，默認是2。如 -XX:NewSize 新生成的池的初始大小。 預設值為2M。 -XX:MaxNewSize 新生成的池的最大大小。 預設值為32M。 +XX:AggressiveHeap 讓jvm忽略Xmx參數，瘋狂地吃完一個G物理內存，再吃盡一個G的swap。 -Xss 每個線程的Stack大小 -verbose:gc 現實垃圾收集信息 -Xloggc:gc.log 指定垃圾收集日誌文件 -XX:+UseParNewGC 縮短minor收集的時間 -XX:+UseConcMarkSweepGC 縮短major收集的時間 -XX:userParNewGC 可用來設置並行收集(多CPU) -XX:ParallelGCThreads 可用來增加並行度(多CPU) -XX:UseParallelGC 設置後可以使用並行清除收集器(多CPU)
❷ 怎麼查看GC 及jvm配置
JVisualVM是JDK 6 update 7之後推出的一個工具，它類似於JProfiler的工具，基於此工具可查看內存的消耗情況、線程的執行狀況及程序中消耗CPU、內存的動作。
❸ jvm調優如何做
Jvm調優依次參考如下
如果沒有必要，請不要做調優
如果沒有必要，請不要做調優。沒有萬能的調優，只有根據使用場景選擇合適的手段，初始默認指定堆大小，元空間大小（jdk8）即可
確認性能問題由JVM再考慮調優，如fullGC頻繁，GC時間較長，內存使用不正常，OOM等。開啟JVM監控，記錄GC日誌，分析GC情況
JVM調優的目標是減少/避免老年代GC
對於追求響應時間的如web系統使用並發垃圾回收器（jdk8開啟G1，低版本使用CMS）
根據JVM內存使用情況，可以考慮手動設置年輕代大小，survivor區大小，減少/避免垃圾進入老年代（注意jdk8默認開啟自適應調節，需關閉）
影響GC時間的還有GC線程數等等，需要結合GC日誌分析GC過程可能存在的問題
❹ jvm內存大小怎麼設
如果你的程序是可運行的jar包的話，可以使用：
java -server -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0 myJarName.jar
如果是tomcat的話：
修改TOMCAT_HOME/bin/catalina.sh
位置cygwin=false前。
JAVA_OPTS=" -server -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0"
下面是參數說明：
-Xmx5g：設置JVM最大可用內存為5G。
-Xms5g：設置JVM初始內存為5G。此值可以設置與-Xmx相同，以避免每次垃圾回收完成後JVM重新分配內存。
-Xmn2g：設置年輕代大小為2G。整個堆內存大小 = 年輕代大小 + 年老代大小 + 持久代大小 。持久代一般固定大小為64m，所以增大年輕代後，將會減小年老代大小。此值對系統性能影響較大，Sun官方推薦配置為整個堆的3/8。
-XX:+UseParNewGC：設置年輕代為並行收集。可與CMS收集同時使用。JDK5.0以上，JVM會根據系統配置自行設置，所以無需再設置此值。
-XX:ParallelGCThreads=8：配置並行收集器的線程數，即：同時多少個線程一起進行垃圾回收。此值最好配置與處理器數目相等。
-XX:SurvivorRatio=6：設置年輕代中Eden區與Survivor區的大小比值。根據經驗設置為6，則兩個Survivor區與一個Eden區的比值為2:6，一個Survivor區占整個年輕代的1/8。
-XX:MaxTenuringThreshold=30： 設置垃圾最大年齡（次數）。如果設置為0的話，則年輕代對象不經過Survivor區直接進入年老代。對於年老代比較多的應用，可以提高效率。如果將此值 設置為一個較大值，則年輕代對象會在Survivor區進行多次復制，這樣可以增加對象再年輕代的存活時間，增加在年輕代即被回收的概率。設置為30表示 一個對象如果在Survivor空間移動30次還沒有被回收就放入年老代。
-XX:+UseConcMarkSweepGC：設置年老代為並發收集。測試配置這個參數以後，參數-XX:NewRatio=4就失效了，所以，此時年輕代大小最好用-Xmn設置，因此這個參數不建議使用。
❺ JVM GC 日誌詳解
本文採用的JDK版本：
設置JVM GC格式日誌的主要參數包括如下8個：
本文假設讀者已經熟悉JVM 內存結構。
如果想開啟GC日誌的信息，可以通過設置如下的參數任一參數：
如果只設置 -XX:+PrintGC 那麼列印的日誌如下所示：
1、 GC 表示是一次YGC（Young GC）
2、 Allocation Failure 表示是失敗的類型
3、 68896K->5080K 表示年輕代從68896K降為5080K
4、 256000K 表示整個堆的大小
5、 0.0041139 secs 表示這次GC總計所用的時間
在JDK 8中， -verbose:gc 是 -XX:+PrintGC 一個別稱，日誌格式等價與： -XX:+PrintGC ，。
不過在 JDK 9 中 -XX:+PrintGC被標記為 deprecated 。
-verbose:gc 是一個標準的選項， -XX:+PrintGC 是一個實驗的選項，建議使用 -verbose:gc 替代 -XX:+PrintGC
參考： Difference between -XX:+PrintGC and -verbose:gc
1、 GC 表示是一次YGC（Young GC）
2、 Allocation Failure 表示是失敗的類型
3、PSYoungGen 表示年輕代大小
4、 53248K->2176K 表示年輕代佔用從 53248K 降為 2176K
5、 59392K 表示年輕帶的大小
6、 58161K->7161K 表示整個堆佔用從 53248K 降為 2176K
7、 256000K 表示整個堆的大小
8、 0.0039189 secs 表示這次GC總計所用的時間
9、 [Times: user=0.02 sys=0.01, real=0.00 secs] 分別表示，用戶態佔用時長，內核用時，真實用時。
時間保留兩位小數，四捨五入。
如果加上 -XX:+PrintGCTimeStamps 那麼日誌僅僅比1.1介紹的最前面多了一個時間戳： 1.963 ， 表示從JVM啟動到列印GC時刻用了1.963秒。
如果加上 -XX:+PrintGCDateStamps 那麼日誌僅僅比1.1介紹的最前面多了一個日期時間： 2019-03-05T16:56:15.108+0800 ， 表示列印GC的時刻的時間是 2019-03-05T16:56:15.108+0800 。+0800表示是東8區。
這個參數開啟後，
使用如下參數 -verbose:gc -XX:+PrintHeapAtGC -Xmn64M -Xms256M -Xmx256M
列印日誌如下：
由此可以看出在，列印如下日誌前後
詳細列印出了日誌信息
invocations 表示GC的次數，每次GC增加一次，每次GC前後的invocations相等
1、 Heap before GC invocations=1 表示是第1次GC調用之前的堆內存狀況
2、 {Heap before GC invocations=1 (full 0): 表示是第1次GC調用之後的堆內存狀況
如果使用該參數 -Xloggc 則默認開啟如下兩個參數
如果啟動參數如下： -Xloggc:gc.log -Xmn64M -Xms256M -Xmx256M 則日誌格式如下所示
gc.log 也可以指定絕對的路徑。
在gc.log最前面還會默認列印系統的JDK版本與啟動的參數
此設置 -XX:+PrintReferenceGC可以列印出SoftReference，WeakReference，FinalReference，PhantomReference，JNI Weak Reference幾種引用的數量，以及清理所用的時長，該參數在進行YGC調優時可以排上用場。
具體可以參考佔小狼的一篇實戰： 一次 Young GC 的優化實踐（FinalReference 相關）
CMS日誌分為兩個STW(stop the world)
分別是 init remark （1） 與 remark （7）兩個階段。一般耗時比YGC長約10倍（個人經驗）。
（1）、 [GC (CMS Initial Mark) [1 CMS-initial-mark: 19498K(32768K)] 36184K(62272K), 0.0018083 secs][Times: user=0.01 sys=0.00, real=0.01 secs]
會STO(Stop The World)，這時候的老年代容量為 32768K， 在使用到 19498K 時開始初始化標記。耗時短。
（2）、 [CMS-concurrent-mark-start]
並發標記階段開始
（3）、 [CMS-concurrent-mark: 0.011/0.011 secs] [Times: user=0.02 sys=0.00, real=0.00 secs]
並發標記階段花費時間。
（4）、 [CMS-concurrent-preclean-start]
並發預清理階段，也是與用戶線程並發執行。虛擬機查找在執行並發標記階段新進入老年代的對象(可能會有一些對象從 新生代 晉升到老年代， 或者有一些對象被分配到老年代)。通過重新掃描，減少下一個階段」重新標記」的工作，因為下一個階段會Stop The World。
（5）、 [CMS-concurrent-preclean: 0.001/0.001 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
並發預清理階段花費時間。
（6）、 [CMS-concurrent-abortable-preclean-start] CMS: abort preclean e to time [CMS-concurrent-abortable-preclean: 0.558/5.093 secs][Times: user=0.57 sys=0.00, real=5.09 secs]
並發可中止預清理階段，運行在並行預清理和重新標記之間，直到獲得所期望的eden空間佔用率。增加這個階段是為了避免在重新標記階段後緊跟著發生一次垃圾清除
（7）、 [GC (CMS Final Remark) [YG occupancy: 16817 K (29504 K)][Rescan (parallel) , 0.0021918 secs][weak refs processing, 0.0000245 secs][class unloading, 0.0044098 secs][scrub symbol table, 0.0029752 secs][scrub string table, 0.0006820 secs][1 CMS-remark: 19498K(32768K)] 36316K(62272K), 0.0104997 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]
會STW(Stop The World)，收集階段，這個階段會標記老年代全部的存活對象，包括那些在並發標記階段更改的或者新創建的引用對象
（8）、 [CMS-concurrent-sweep-start]
並發清理階段開始，與用戶線程並發執行。
（9）、 [CMS-concurrent-sweep: 0.007/0.007 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
並發清理階段結束，所用的時間。
（10）、 [CMS-concurrent-reset-start]
開始並發重置。在這個階段，與CMS相關數據結構被重新初始化，這樣下一個周期可以正常進行。
（11）、 [CMS-concurrent-reset: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
並發重置所用結束，所用的時間。
參考：
Geek-Yan : JVM 學習筆記(四) CMS GC日誌詳解
設置JVM GC 性能的有如下參數
新生代大小官網推薦的大小是 3/8 , 如果設置太小，比如 1/10會 導致 Minor GC 與 Major GC 次數增多。
其中n的大小為區間為[0,15],如果高於15，JDK7 會默認15，JDK 8會啟動報錯
發生在CMS GC運行期間，詳情參考：
JVM 調優 —— GC 長時間停頓問題及解決方法
GC的悲觀策略
發生在Minor GC期間
❻ 如何設置jvm啟動參數
不管是YGC還是Full GC,GC過程中都會對導致程序運行中中斷,正確的選擇不同的GC策略,調整JVM、GC的參數，可以極大的減少由於GC工作，而導致的程序運行中斷方面的問題，進而適當的提高Java程序的工作效率。但是調整GC是以個極為復雜的過程，由於各個程序具備不同的特點，如：web和GUI程序就有很大區別（Web可以適當的停頓，但GUI停頓是客戶無法接受的），而且由於跑在各個機器上的配置不同（主要cup個數，內存不同），所以使用的GC種類也會不同(如何選擇見GC種類及如何選擇)。本文將注重介紹JVM、GC的一些重要參數的設置來提高系統的性能。
GC性能方面的考慮
對於GC的性能主要有2個方面的指標：吞吐量throughput（工作時間不算gc的時間占總的時間比）和暫停pause（gc發生時app對外顯示的無法響應）。
1. Total Heap
默認情況下，vm會增加/減少heap大小以維持free space在整個vm中占的比例，這個比例由MinHeapFreeRatio和MaxHeapFreeRatio指定。
一般而言，server端的app會有以下規則：
對vm分配盡可能多的memory；
將Xms和Xmx設為一樣的值。如果虛擬機啟動時設置使用的內存比較小，這個時候又需要初始化很多對象，虛擬機就必須重復地增加內存。
處理器核數增加，內存也跟著增大。
2. The Young Generation
另外一個對於app流暢性運行影響的因素是young generation的大小。young generation越大，minor collection越少；但是在固定heap size情況下，更大的young generation就意味著小的tenured generation，就意味著更多的major collection(major collection會引發minor collection)。
NewRatio反映的是young和tenured generation的大小比例。NewSize和MaxNewSize反映的是young generation大小的下限和上限，將這兩個值設為一樣就固定了young generation的大小（同Xms和Xmx設為一樣）。
如果希望，SurvivorRatio也可以優化survivor的大小，不過這對於性能的影響不是很大。SurvivorRatio是eden和survior大小比例。
一般而言，server端的app會有以下規則：
首先決定能分配給vm的最大的heap size，然後設定最佳的young generation的大小；
如果heap size固定後，增加young generation的大小意味著減小tenured generation大小。讓tenured generation在任何時候夠大，能夠容納所有live的data（留10%-20%的空餘）。
經驗&&規則
年輕代大小選擇
響應時間優先的應用:盡可能設大,直到接近系統的最低響應時間限制(根據實際情況選擇).在此種情況下,年輕代收集發生的頻率也是最小的.同時,減少到達年老代的對象.
吞吐量優先的應用:盡可能的設置大,可能到達Gbit的程度.因為對響應時間沒有要求,垃圾收集可以並行進行,一般適合8CPU以上的應用.
避免設置過小.當新生代設置過小時會導致:1.YGC次數更加頻繁 2.可能導致YGC對象直接進入舊生代,如果此時舊生代滿了,會觸發FGC.
年老代大小選擇
響應時間優先的應用:年老代使用並發收集器,所以其大小需要小心設置,一般要考慮並發會話率和會話持續時間等一些參數.如果堆設置小了,可以會造成內存碎 片,高回收頻率以及應用暫停而使用傳統的標記清除方式;如果堆大了,則需要較長的收集時間.最優化的方案,一般需要參考以下數據獲得:
並發垃圾收集信息、持久代並發收集次數、傳統GC信息、花在年輕代和年老代回收上的時間比例。
吞吐量優先的應用:一般吞吐量優先的應用都有一個很大的年輕代和一個較小的年老代.原因是,這樣可以盡可能回收掉大部分短期對象,減少中期的對象,而年老代盡存放長期存活對象.
較小堆引起的碎片問題
因為年老代的並發收集器使用標記,清除演算法,所以不會對堆進行壓縮.當收集器回收時,他會把相鄰的空間進行合並,這樣可以分配給較大的對象.但是,當堆空間較小時,運行一段時間以後,就會出現"碎片",如果並發收集器找不到足夠的空間,那麼並發收集器將會停止,然後使用傳統的標記,清除方式進行回收.如果出現"碎片",可能需要進行如下配置:
-XX:+UseCMSCompactAtFullCollection:使用並發收集器時,開啟對年老代的壓縮.
-XX:CMSFullGCsBeforeCompaction=0:上面配置開啟的情況下,這里設置多少次Full GC後,對年老代進行壓縮
用64位操作系統，Linux下64位的jdk比32位jdk要慢一些，但是吃得內存更多，吞吐量更大
XMX和XMS設置一樣大，MaxPermSize和MinPermSize設置一樣大，這樣可以減輕伸縮堆大小帶來的壓力
使用CMS的好處是用盡量少的新生代，經驗值是128M－256M， 然後老生代利用CMS並行收集， 這樣能保證系統低延遲的吞吐效率。 實際上cms的收集停頓時間非常的短，2G的內存， 大約20－80ms的應用程序停頓時間
系統停頓的時候可能是GC的問題也可能是程序的問題，多用jmap和jstack查看，或者killall -3 java，然後查看java控制台日誌，能看出很多問題。(相關工具的使用方法將在後面的blog中介紹)
仔細了解自己的應用，如果用了緩存，那麼年老代應該大一些，緩存的HashMap不應該無限制長，建議採用LRU演算法的Map做緩存，LRUMap的最大長度也要根據實際情況設定。
採用並發回收時，年輕代小一點，年老代要大，因為年老大用的是並發回收，即使時間長點也不會影響其他程序繼續運行，網站不會停頓
JVM參數的設置(特別是 –Xmx –Xms –Xmn -XX:SurvivorRatio -XX:MaxTenuringThreshold等參數的設置沒有一個固定的公式，需要根據PV old區實際數據 YGC次數等多方面來衡量。為了避免promotion faild可能會導致xmn設置偏小，也意味著YGC的次數會增多，處理並發訪問的能力下降等問題。每個參數的調整都需要經過詳細的性能測試，才能找到特定應用的最佳配置。
promotion failed:
垃圾回收時promotion failed是個很頭痛的問題，一般可能是兩種原因產生，第一個原因是救助空間不夠，救助空間里的對象還不應該被移動到年老代，但年輕代又有很多對象需要放入救助空間；第二個原因是年老代沒有足夠的空間接納來自年輕代的對象；這兩種情況都會轉向Full GC，網站停頓時間較長。
解決方方案一：
第一個原因我的最終解決辦法是去掉救助空間，設置-XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0即可，第二個原因我的解決辦法是設置為某個值（假設70），這樣年老代空間到70%時就開始執行CMS，年老代有足夠的空間接納來自年輕代的對象。
解決方案一的改進方案：
又有改進了，上面方法不太好，因為沒有用到救助空間，所以年老代容易滿，CMS執行會比較頻繁。我改善了一下，還是用救助空間，但是把救助空間加大，這樣也不會有promotion failed。具體操作上，32位Linux和64位Linux好像不一樣，64位系統似乎只要配置MaxTenuringThreshold參數，CMS還是有暫停。為了解決暫停問題和promotion failed問題，最後我設置-XX:SurvivorRatio=1 ，並把MaxTenuringThreshold去掉，這樣即沒有暫停又不會有promotoin failed，而且更重要的是，年老代和永久代上升非常慢（因為好多對象到不了年老代就被回收了），所以CMS執行頻率非常低，好幾個小時才執行一次，這樣，伺服器都不用重啟了。
-Xmx4000M -Xms4000M -Xmn600M -XX:PermSize=500M -XX:MaxPermSize=500M -Xss256K -XX:+DisableExplicitGC -XX:SurvivorRatio=1 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:LargePageSizeInBytes=128M -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:=80 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log
值與Xmn的關系公式
上面介紹了promontion faild產生的原因是EDEN空間不足的情況下將EDEN與From survivor中的存活對象存入To survivor區時,To survivor區的空間不足，再次晉升到old gen區，而old gen區內存也不夠的情況下產生了promontion faild從而導致full gc.那可以推斷出：eden+from survivor < old gen區剩餘內存時，不會出現promontion faild的情況，即：
(Xmx-Xmn)*(1-/100)>=(Xmn-Xmn/(SurvivorRatior+2)) 進而推斷出：
<=((Xmx-Xmn)-(Xmn-Xmn/(SurvivorRatior+2)))/(Xmx-Xmn)*100
例如：
當xmx=128 xmn=36 SurvivorRatior=1時 <=((128.0-36)-(36-36/(1+2)))/(128-36)*100 =73.913
當xmx=128 xmn=24 SurvivorRatior=1時 <=((128.0-24)-(24-24/(1+2)))/(128-24)*100=84.615…
當xmx=3000 xmn=600 SurvivorRatior=1時 <=((3000.0-600)-(600-600/(1+2)))/(3000-600)*100=83.33
低於70% 需要調整xmn或SurvivorRatior值。
❼ JVM 性能調優方法
JVM性能調優有很多設置,這個參考JVM參數即可.
主要調優的目的:
控制GC的行為.GC是一個後台處理,但是它也是會消耗系統性能的,因此經常會根據系統運行的程序的特性來更改GC行為
控制JVM堆棧大小.一般來說,JVM在內存分配上不需要你修改,(舉例)但是當你的程序新生代對象在某個時間段產生的比較多的時候,就需要控制新生代的堆大小.同時,還要需要控制總的JVM大小避免內存溢出
控制JVM線程的內存分配.如果是多線程程序,產生線程和線程運行所消耗的內存也是可以控制的,需要通過一定時間的觀測後,配置最優結果。
❽ JVM性能調優（2） —— 內存設置和查看GC日誌
1）JVM內存分配有如下一些參數：
一般 -Xms 和 -Xmx 設置一樣的大小，-XX:MetaspaceSize 和 -XX:MaxMetaspaceSize 設置一樣的大小。-Xms 等價於 -XX:InitialHeapSize，-Xmx等價於-XX:MaxHeapSize；-Xmn等價於-XX:MaxNewSize。
2）在IDEA中可以按照如下方式設置JVM參數：
3）命令行啟動時可以按照如下格式設置：
1）設置GC參數：
可以在啟動時加上如下參數來查看GC日誌：
例如，我在IDEA中添加了如下JVM啟動參數：
啟動程序之後列印出了如下的一些日誌：
從第三行 CommandLine flags 可以得到如下的信息：
2）查看默認參數：
如果要查看JVM的默認參數，就可以通過給JVM加列印GC日誌的參數，就可以在GC日誌中看到JVM的默認參數了。
還可以在啟動參數中添加 -XX:+PrintFlagsFinal 參數，將會列印系統的所有參數，就可以看到自己配置的參數或系統的默認參數了：
3）GC日誌：
之後的日誌就是每次垃圾回收時產生的日誌，每行日誌說明了這次GC的執行情況，例如第四行GC日誌：
詳細內容如下：
2020-09-25T13:00:41.631+0800：GC發生的時間點。
4.013：系統運行多久之後發生的GC，單位秒，這里就是系統運行 4.013 秒後發生了一次GC。
GC (Allocation Failure)：說明了觸發GC的原因，這里是指對象分配失敗導致的GC。
PSYoungGen：指觸發的是年輕代的垃圾回收，使用的是 Parallel Scavenge 垃圾回收器。
419840K->20541K：對年輕代執行了一次GC，GC之前年輕代使用了 419840K，GC之後有 20541K 的對象活下來了。
(472064K)：年輕代可用空間是 472064K，即 461 M，為什麼是461M呢？因為新生代大小為 512M，Eden 區占 409.6M，兩塊 Survivor 區各占 51.2M，所以年輕代的可用空間為 Eden+1個Survivor的大小，即460.8M，約為461M。
419840K->20573K：GC前整個堆內存使用了 419840K，GC之後堆內存使用了 20573K。
(996352K)：整個堆的大小是 996352K，即 973M，其實就是年輕代的 461M + 老年代的 512 M
0.0118345 secs：本次GC耗費的時間
Times: user=0.00 sys=0.00, real=0.01 secs：本次GC耗費的時間
4）JVM退出時的GC情況：
程序結束運行後，還會列印一些日誌，就是第12行之後的日誌，這部分展示的是當前堆內存的使用情況：
詳細內容如下：
❾ Linux裡面JVM內存怎麼設置
一、堆內存相關配置
設置堆初始值
指令1：-Xms2g
指令2：-XX:InitialHeapSize=2048m
設置堆區最大值
指令1：`-Xmx2g`
指令2： -XX:MaxHeapSize=2048m
縮小堆內存的時機
-XX:MaxHeapFreeRatio=70//堆內存使用率大於70時擴張堆內存，xms=xmx時該參數無效，默認值70
擴張堆內存的時機
-XX:MinHeapFreeRatio=40//堆內存使用率小於40時縮減堆內存，xms=xmx時該參數無效，默認值40
新生代內存配置
指令1：-Xmn512m
指令2：-XX:MaxNewSize=512m
2個survivor區和Eden區大小比率
指令：-XX:SurvivorRatio=6 //S區和Eden區佔新生代比率為1:6,兩個S區2:6
新生代和老年代的佔比
-XX:NewRatio=4 //表示新生代:老年代 = 1:4 即老年代占整個堆的4/5；默認值=2
二、方法區內存配置常用參數
初始化的Metaspace大小，
-XX:MetaspaceSize ：
Metaspace最大值
-XX:MaxMetaspaceSize
三、線程棧內存配置常用參數
每個線程棧最大值
指令1：-Xss256k
指令2：-XX:ThreadStackSize=256k
注意：
棧設置太大，會導致線程創建減少。
棧設置小，會導致深入不夠，深度的遞歸會導致棧溢出。
建議棧深度設置在3000-5000
四、配置垃圾收集器
Serial垃圾收集器（新生代）
開啟：-XX:+UseSerialGC
關閉：-XX:-UseSerialGC
//新生代使用Serial 老年代則使用SerialOld
ParNew垃圾收集器（新生代）
開啟 -XX:+UseParNewGC
關閉 -XX:-UseParNewGC
//新生代使用功能ParNew 老年代則使用功能CMS
Parallel Scavenge收集器（新生代）
開啟 -XX:+UseParallelOldGC
關閉 -XX:-UseParallelOldGC
//新生代使用功能Parallel Scavenge 老年代將會使用Parallel Old收集器
ParallelOl垃圾收集器（老年代）
開啟 -XX:+UseParallelGC
關閉 -XX:-UseParallelGC
//新生代使用功能Parallel Scavenge 老年代將會使用Parallel Old收集器
CMS垃圾收集器（老年代）
開啟 -XX:+UseConcMarkSweepGC
關閉 -XX:-UseConcMarkSweepGC
G1垃圾收集器
開啟 -XX:+UseG1GC
關閉 -XX:-UseG1GC
五、GC策略配置
GC並行執行線程數
-XX:ParallelGCThreads=16
新生代可容納的最大對象
-XX:PretenureSizeThreshold=1000000 //大於此值的對象直接會分配到老年代，設置為0則沒有限制。 //避免在Eden區和Survivor區發生大量的內存復制，該參數只對Serial和ParNew收集器有效，Parallel Scavenge並不認識該參數
進入老年代的GC年齡
進入老年代最小的GC年齡
-XX:InitialTenuringThreshol=7 //年輕代對象轉換為老年代對象最小年齡值，默認值7，對象在堅持過一次Minor GC之後，年齡就加1，每個對象在堅持過一次Minor GC之後，年齡就增加1
進入老年代最大的GC年齡
-XX:MaxTenuringThreshold=15 //年輕代對象轉換為老年代對象最大年齡值，默認值15
六、GC日誌信息配置
配置GC文件路徑
-Xloggc:/data/gclog/gc.log//固定路徑名稱生成 -Xloggc:/home/GCEASY/gc-%t.log //根據時間生成
滾動生成日誌
日誌文件達到一定大小後，生成另一個文件。須配置Xloggc
開啟 -XX:+UseGCLogFileRotation
關閉 -XX:-UseGCLogFileRotation
-XX:NumberOfGCLogFiles=4 //滾動GC日誌文件數，默認0，不滾動 -XX:GCLogFileSize=100k //GC文件滾動大小，需配置UseGCLogFileRotation，設置為0表示僅通過jcmd命令觸發