jvm怎麼配置

A. jvm - 常用調優啟動參數配置

可以看到堆內存為2G，新生代為768M老年代為1280M，新生代採用ParNew收集器
-XX:+UseConcMarkSweepGC:新生代使用ParNew回收器，老年代使用CMS
線程棧為512k（默認1024k調小可以增加創建線程數，增加並發量）
同時列印 GC 詳細信息和列印 GC 發生時間，當發生OOM時，Dump文件到指定路徑

棧空間參數設置
-Xss: 設置線程的最大棧空間，棧空間越大，方法的遞歸深度越大

方法區參數設置（方法區大小的參數設置跟jdk版本相關）
jdk1.6,jdk1.7設置方法區永久代的大小
-XX:PermSize=5M
-XX:MaxPermSize=5M 最大永久代的大小默認是64M
jdk1.8及以上，永久代被移除，取而代之的是元數據區，元數據區是一塊堆外的直接內存
如果不指定大小，那麼會耗盡所有可用的系統內存
-XX:MaxMetaspaceSize=60M 設置最大元數據的大小

堆設置
-Xms：初始堆大小
-Xmx：最大堆大小
-Xmn：設置新生代大小，設置較大的新生代大小會減小老年代大小，新生代的大小一般為堆空間的1/3
-XX:NewSize=n： 設置年輕代大小
-XX:NewRatio=n：設置年輕代和年老代的比值(老年代/新生代)。如:為3，表示年輕代與年老代比值為1：3
年輕代占整個年輕代年老代和的1/4
-XX:SurvivorRatio=n：年輕代中Eden區與兩個Survivor區的比值。注意Survivor區有兩個。

-Xmn，-XX:NewSize/-XX:MaxNewSize，-XX:NewRatio 3組參數都可以影響年輕代的大小，混合使用的情況下，優先順序是什麼？

1.高優先順序：-XX:NewSize/-XX:MaxNewSize
2.中優先順序：-Xmn（默認等效 -Xmn=-XX:NewSize=-XX:MaxNewSize=?）
3.低優先順序：-XX:NewRatio
推薦使用-Xmn參數，原因是這個參數簡潔，相當於一次設定 NewSize/MaxNewSIze而且兩者相等，適用於生產環境。
-Xmn 配合 -Xms/-Xmx，即可將堆內存布局完成 -Xmn參數是在JDK 1.4 開始支持

下面兩個參數配合使用，當系統發生堆空間不足時，會導出整個堆的信息，且導出到指定的文件中去,後面用MAT工具分析
-XX:HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=d:/a.mp
直接內存配置
-XX:MaxDirectMemorySize
設置直接內存大小，如果不設置，默認值為最大堆空間,即-Xmx指定的大小，當達到指定值時，
會觸發垃圾回收，如果回收後也無法釋放空間，那麼將會拋出OOM

-XX:+UseSerialGC:新生代，老年代都使用串列收集器
-XX:+UseParNewGC:新生代使用ParNew收集器，老年代使用串列收集器Serial
(jdk9,10已經廢除，因為ParNew只能和CMS收集器配合使用，而jdk9,10使用的默認收集器是G1)
-XX:+UseParallelGC:新生代使用ParallelGC,老年代使用串列收集器Serial

-XX:+UseParallelGC:新生代使用ParallelGC回收器，老年代使用串列回收器Serial
-XX:+UseParallelOldGC:新生代使用ParallelGC回收器，老年代使用ParallelOldGc回收器

兩個重要參數
-XX:MaxGCPasuseMillis:設置最大垃圾回收停頓時間，設置的過小，可能導致垃圾回收頻率加大
-XX:GCTimeRatio:設置吞吐量大小，取值范圍為0-100，系統回收垃圾的停頓時間花費不超過1/(1+n)%

設置線程數量
-XX:ParallelGCThreads

-XX:+UseConcMarkSweepGC:新生代使用ParNew回收器，老年代使用CMS
CMS默認啟動的並發線程數量為（parallelGCTheads+3）/4

設置並發線程數
-XX:ConcGCThreads=n
-XX:ParallelGCThreads=n

設置老年代空間使用率達到多少時執行CMS垃圾回收
-XX: 默認值為68

碎片整理參數，如果碎片不整理，可能造成沒達到閾值就會觸發老年代垃圾回收
-XX:+UseCMSCompactAtFullCollection :在CMS垃圾收集完成之後，進行一次內存碎片整理
-XX:+CMSFullGCsBeforeCompaction=n :在n次CMS回收後進行一次內存碎片整理

使用CMS回收方法去的perm區,默認情況下，還需要觸發一次FullGC
-XX:+CMSClassUnloadingEnabled

XX:UseG1GC 開啟G1垃圾收集器

兩個重要的參數
-XX:MaxGcPasuseMillis :指定目標最大停頓時間，如果停頓的時間過小，一次收集的區域數量也會變小
就會增加FullGC的可能

-XX:parallelGCThreads :設置並行回收的GC線程數量

-XX: :設置整個堆使用率達到多少時，觸發並發標記的執行，默認是45

-XX:+PrintGC 在程序運行期間，只要遇到GC，就會列印GC情況
佔用大小->gc後大小 GC消耗時間
jdk9，jdk10默認使用G1收集器，所以列印GC參數不同
-Xlog:gc

-XX:+PrintGCDetails 列印GC詳細信息(JDK8,9,10建議使用-Xlog:gc*)
-XX:+PrintGCTimeStamps 列印分析GC發生的時間
-XX:+ 列印應用程序的執行時間
-XX：+PrintGCApplicationStoppedTime 列印GC產生停頓的時間
-Xloggc:/usr/local/log/gc.log 讓gc日誌列印在log文件夾下的gc文件中，因為默認情況下gc日誌在控制台輸出

棧上分配，逃逸分析（方法內的變數被外部引用）
允許對象直接在棧上進行分配，隨線程停止而銷毀，這樣做可以加快分配速度，減少GC次數
棧空間較小，所以不適合大對象的棧上分配

-XX:+DoEscapeAnalysis 啟用逃逸分析
-XX：+EliminateAllocations 開啟標量替換(默認打開),允許對象打散分配在棧上
比如對象擁有id和name兩個欄位，那麼這兩個欄位將會被視為兩個獨立的變數進行分配。
對象晉升
-MaxTenuringThreshold=n ,當對象經歷了多少次GC次數後進入老年代
注意：大對象直接晉升到老年代
-PretenureSizeThreshold=n 這里的單位是位元組，新生對象大於這個值的時候，會直接分配到老年代

1、對存活對象標注時間過長：比如重載了Object類的Finalize方法，導致標注Final Reference耗時過長；或者String.intern方法使用不當，導致YGC掃描StringTable時間過長。

2、長周期對象積累過多：比如本地緩存使用不當，積累了太多存活對象；或者鎖競爭嚴重導致線程阻塞，局部變數的生命周期變長

當Eden區空間不足時，就會觸發YGC。結合新生代對象的內存分配看下詳細過程：

1、新對象會先嘗試在棧上分配，如果不行則嘗試在TLAB分配，否則再看是否滿足大對象條件要在老年代分配，最後才考慮在Eden區申請空間。

2、如果Eden區沒有合適的空間，則觸發YGC。

3、YGC時，對Eden區和From Survivor區的存活對象進行處理，如果滿足動態年齡判斷的條件或者To Survivor區空間不夠則直接進入老年代，如果老年代空間也不夠了，則會發生promotion failed，觸發老年代的回收。否則將存活對象復制到To Survivor區。

4、此時Eden區和From Survivor區的剩餘對象均為垃圾對象，可直接抹掉回收。

此外，老年代如果採用的是CMS回收器，為了減少CMS Remark階段的耗時，也有可能會觸發一次YGC，這里不作展開。

大多數情況下，對象直接在年輕代中的Eden區進行分配，如果Eden區域沒有足夠的空間，那麼就會觸發YGC（Minor GC），YGC處理的區域只有新生代。因為大部分對象在短時間內都是可收回掉的，因此YGC後只有極少數的對象能存活下來，而被移動到S0區（採用的是復制演算法）。當觸發下一次YGC時，會將Eden區和S0區的存活對象移動到S1區，同時清空Eden區和S0區。當再次觸發YGC時，這時候處理的區域就變成了Eden區和S1區（即S0和S1進行角色交換）。每經過一次YGC，存活對象的年齡就會加1。

下面4種情況，對象會進入到老年代中：

當晉升到老年代的對象大於了老年代的剩餘空間時，就會觸發FGC（Major GC），FGC處理的區域同時包括新生代和老年代。除此之外，還有以下4種情況也會觸發FGC：

B. ElasticSearch JVM配置

Elasticsearch是基於java構建的，需要至少 Java8 來運行它。只支持Oracle的Java和OpenJDK。所有Elasticsearch節點和客戶機都應該使用相同的JVM版本。

我們推薦您安裝Java1.8.0_131版本或者Java 8發行版系列的後續版本。我們推薦您使用 LTS JAVA 版本。如果使用了已知的糟糕的Java版本，Elasticsearch將拒絕啟動。

Elasticsearch將使用的Java版本可以通過設置JAVA_HOME環境變數進行配置。

默認情況下，Elasticsearch告訴JVM使用最小和最大大小為1 GB的堆。 在轉移到生產環境時，重要的是配置堆大小，以確保Elasticsearch有足夠的可用堆。

Elasticsearch將通過Xms(最小堆大小)和Xmx(最大堆大小)設置分配在jvm.options文件中指定的整個堆。

這些設置的值取決於伺服器上可用RAM的數量。好的經驗法則是：

顯示啟用了從零開始的壓縮oops而不是：

下面是如何通過jvm.options文件設置堆大小的例子：

還可以通過環境變數設置堆大小。這可以通過注釋掉jvm.options文件中的Xms和Xmx設置來實現並通過ES_JAVA_OPTS設置這些值：

注意： 為Windows服務配置堆與上述配置不同。Windows服務最初填充的值可以如上配置，但在安裝服務之後會有所不同。有關更多細節，請參閱 Windows服務文檔 。

默認情況下，Elasticsearch配置JVM將堆從內存溢出異常轉儲到默認數據目錄（/var/lib/elasticsearch是針對RPM和Debian包發行版的，Elasticsearch安裝根目錄下的data目錄是針對tar和zip存檔發行版的）如果此路徑不適合接收堆轉儲，則應修改條目 -XX:HeapDumpPath=… 在jvm.options文件中。如果指定目錄，JVM將根據運行實例的PID為堆轉儲生成一個文件名。如果指定的是固定文件名而不是目錄，那麼當JVM需要對內存溢出異常執行堆轉儲時，文件必須不存在，否則堆轉儲將失敗。

默認情況下，Elasticsearch啟用GC日誌。這些都是在jvm.options中配置的和默認設置到與Elasticsearch日誌相同的默認位置。默認配置每64 MB旋轉日誌一次，最多可以消耗2 GB的磁碟空間。

默認情況下，Elasticsearch配置JVM將致命錯誤日誌寫入默認日誌目錄(/var/log/elasticsearch是RPM和Debian包發行版的，Elasticsearch安裝根目錄下的logs目錄是針對tar和zip存檔發行版的)。這些日誌是JVM遇到致命錯誤(例如，分割錯誤)時生成的。如果這個路徑不適合接收日誌，您應該在jvm.options文件中修改條目 -XX:ErrorFile=… 為一個替代路徑。

C. 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命令觸發

D. 如何設置JVM參數

設置eclipse jvm參數

打開Eclipse 或者 MyEclipse

打開 Windows -> Preferences -> Java -> Installed JREs

在 Default VM Arguments輸入框內輸入： -Xms512m -Xmx512m

解釋：

-Xms是設置java虛擬機的最小分配內存；-Xmx則是最大分配內存；512m為內存空間

一般-Xmx設置為你電腦物理內存的1/4，而把-Xms和 -Xmx設置為一樣，

其實你可以設置得更大一些，只要系統能分配足夠的內存就可以了，如果設置過大系統會提示你的。

E. 常用jvm參數配置

● 查看gc基本信息
○ jdk9 之前使用 -XX:+PrintGC
○ jdk9 之後使用-Xlog:gc
● 查看gc詳細信息
○ jdk9 之前使用 -XX:+PrintGCDetails
○ jdk9 之後使用-Xlog:gc*
● 查看GC前後堆、方法區可用容量變化
○ jdk9 之前使用 -XX:+PrintHeapAtGC
○ jdk9 之後使用-Xlog:gc+heap = debug
● 查看GC過程中用戶線程並發時間以及停頓時間
○ jdk9 之前使用 -XX:+ 以及 -XX:+PrintGCApplicationStoppedTime
○ jdk9 之後使用-Xlog:safepoint
● 查看收集器Ergonomics機制
○ jdk9 之前使用 -XX:+PrintAdaptiveSizePolicy
○ jdk9 之後使用-Xlog:gc+ergo*=trace
● 查看熬過收集後剩餘對象的年齡分布信息
○ jdk9 之前使用 -XX:+PrintTenuringDistribution
○ jdk9 之後使用-Xlog:gc+age=trace

● 還是分代，不過分代都融入到了region，每個region都會根據實際情況調整功能
● 大對象不屬於新生代也不屬於老年代，這點和之前分代不同，G1 認為大於region的一半就為大對象
● G1的大多數行為都把Humongous Region作為老年代的一部分來進行看待
● 回收最有價值的（每個region都會有價值計算），回收時會把存活的復制到一個新的region中，單個region較小，根據停頓時間能控制回收影響

● Minor Gcc 模式
○ Young Gc，Eden區滿了以後，就會觸發
● Mixed Gc 模式
○ 老年代占整個堆的（默認45%） 比例時，就會觸發Mixed Gc
○ 回收所有的年輕代Region+部分老年代的Region
● full Gc 模式
○ 當Mixed Gc的回收速度趕不上對象的生成速度時觸發
○ 一旦由Mixed Gc降級到full Gc，將使用Serial GC收集器進行回收

● ZGC的Region具有動態性，動態創建和小會，以及動態的區域容量大小；Region的分類：
○ 小型Region（Small Region）：容量固定2MB，用於存放<256kb的小對象
○ 中型Region（Medium Region）:容量固定為32MB，用於存放>=256KB,但小於4MB的對象；
○ 大型Region（Large Region）：容量不固定，可以動態變化，但必須是2MB的整數倍，用於放置>=4mb的大對象
● 採用染色指針技術實現並發整理演算法：
○ 將標記信息記在引用對象的指針上；
○ 可以說zgc的可達性分析是遍歷對象的「引用圖」；
○ 在linux下64位指針的高18位不能用來定址，zgc的染色體指針技術盯上了剩餘46位的指針寬度，將其高4位提取出來存儲四個標志信息（同時也壓縮了zgc能夠管理內存不能超過4TB~2的42次方）
○ 用來標志：對象的三色標記狀態、是否進入了重分配集、是否執行過finalize()方法。
染色指針的優勢：
○ Region的存活對象被移走，立即能夠被釋放和重用掉；
○ 減少在垃圾收集過程中的內存屏障的使用次數；zgc未使用任何的寫屏障，只用了讀屏障
○ 可擴展的存儲結構，方便日後進一步提升性能；
● 支持Numa架構

F. 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的命令參數，幫助查看堆信息

G. 2021-09-28 docker 配置JVM參數及常用命令使用

為什麼設置了 -Xmx 還是被 kill

宿主機內存如下，

默認情況下，JVM的Max Heap Size是系統內存的1/4，那麼JVM將的默認Heap≈4G。

參考這篇文章 被kill問題之2：Docker環境下Java應用的JVM設置（容器中的JVM資源該如何被安全的限制）

前文提到還有另外一種方法解決 JVM 內存超限的問題，這種方法可以讓 JVM 自動感知 docker 容器的 cgroup 限制，從而動態的調整堆內存大小，感覺挺不錯的。我們也來試一下這種方法，看看效果如何 ; )
查看下當前tomcat是否支持該參數
-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap

往下翻，找到了要配置的參數，表示當前jvm支持該參數，最終參數如下，/var/jvm/log目錄記得創建

加到Catalina.sh中

[root@localhost webapps]# docker commit -a "fengjian" -m "tomcat8+jdk8+jvm參數優化" cd50041ea188 tomcat:8.5.70-jdk8-jvmG1

進入到容器之後，想查看容器使用的內存情況，報錯如下

參考 Docker 中無法使用 JDK jmap之 Can't attach to the process: ptrace(PTRACE_ATTACH問題
在啟動容器時增加參數
docker run --cap-add=SYS_PTRACE
完整啟動如下
docker run --name central-kitchen-kxg -d -p 9093:8080 -v /home/dockerms/data/central-kitchen-kxg/webapps:/usr/local/tomcat/webapps -e TZ=Asia/Shanghai --cap-add=SYS_PTRACE tomcat:8.5.70-jdk8-jvmG1

H. JVM環境參數怎麼配置

典型JVM參數設置：

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k

-Xmx3550m：設置JVM最大可用內存為3550M。

-Xms3550m：設置JVM促使內存為3550m。此值可以設置與-Xmx相同，以避免每次垃圾回收完成後JVM重新分配內存。

-Xmn2g：設置年輕代大小為2G。整個堆大小=年輕代大小 + 年老代大小 + 持久代大小。持久代一般固定大小為64m，所以增大年輕代後，將會減小年老代大小。此值對系統性能影響較大，Sun官方推薦配置為整個堆的3/8。

-Xss128k：設置每個線程的堆棧大小。JDK5.0以後每個線程堆棧大小為1M，以前每個線程堆棧大小為256K。更具應用的線程所需內存大小進行調整。在相同物理內存下，減小這個值能生成更多的線程。但是操作系統對一個進程內的線程數還是有限制的，不能無限生成，經驗值在3000~5000左右。

java -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0

-XX:NewRatio=4:設置年輕代（包括Eden和兩個Survivor區）與年老代的比值（除去持久代）。設置為4，則年輕代與年老代所佔比值為1：4，年輕代占整個堆棧的1/5

-XX:SurvivorRatio=4：設置年輕代中Eden區與Survivor區的大小比值。設置為4，則兩個Survivor區與一個Eden區的比值為2:4，一個Survivor區占整個年輕代的1/6

-XX:MaxPermSize=16m:設置持久代大小為16m。

-XX:MaxTenuringThreshold=0：設置垃圾最大年齡。如果設置為0的話，則年輕代對象不經過Survivor區，直接進入年老代。對於年老代比較多的應用，可以提高效率。如果將此值設置為一個較大值，則年輕代對象會在Survivor區進行多次復制，這樣可以增加對象再年輕代的存活時間，增加在年輕代即被回收的概論。