javajvm設置

A. 如何設置JVM參數

設置eclipse jvm參數

打開Eclipse 或者 MyEclipse

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

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

解釋：

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

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

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

B. 關於設置Java虛擬機(JVM)的內存問題

最近做畢設時 遇到了一點小問題 在解析dblp xml文件時（該文件很大 最新版本為 MB） 老是報錯

java lang OutOfMemoryError: Java heap space

最後通過查資料才知道 這是由於JVM堆內存不足造成的 JVM在啟動動的時候一般會設置JVM Heap的值

其初始空間（即 Xms）是物理內存的 / 最大空間（ Xmx）不可超過物理內存 在JVM中如果 ％的時間是用於GC 且可用的Heap size 不足 ％的時候將拋出此異常信息 出現這種問題可以通過修改JVM heap大小解決

如

點擊（此處）折疊或打開

java Xms M Xmx M className

以上設置JVM初始化堆內存為 M 最大可用堆內存為 M

（ ）在命令行中設置的方法就如上面所述

（ ）在Eclipse中可以這樣設置

在eclipse的 Run >Run Configurations >Arguments下的VM Arguments中設置

Xms M Xmx M

另外可以使用 java X查看其它JVM參數情況

點擊（此處）折疊或打開

D:work>java X

Xmixed mixed mode execution （default）

Xint interpreted mode execution only

Xbootclasspath:<directories and zip/jar files separated by ;>

set search path for bootstrap classes and resources

Xbootclasspath/a:<directories and zip/jar files separated by ;>

append to end of bootstrap class path

Xbootclasspath/p:<directories and zip/jar files separated by ;>

prepend in front of bootstrap class path

Xnoclassgc disable class garbage collection

Xincgc enable incremental garbage collection

Xloggc:<file> log GC status to a file with time stamps

Xbatch disable background pilation

Xms<size> set initial Java heap size

Xmx<size> set maximum Java heap size

Xss<size> set java thread stack size

Xprof output cpu profiling data

Xfuture enable strictest checks anticipating future default

Xrs rece use of OS signals by Java/VM （see documentation）

Xcheck:jni perform additional checks for JNI functions

Xshare:off do not attempt to use shared class data

Xshare:auto use shared class data if possible （default）

Xshare:on require using shared class data otherwise fail

The X options are non standard and subject to change without notice

可以通過java lang Runtime的一些方法查看jvm的內存使用情況

點擊（此處）折疊或打開

System out println（ Total Memory: + Runtime getRuntime（） totalMemory（） / （ * + MB ）

System out println（ Free Memory: + Runtime getRuntime（） freeMemory（） / （ * ） + MB ）

System out println（ Max Memory: + Runtime getRuntime（） maxMemory（） / （ * ） + MB ）

maxMemory（）這個方法返回的是java虛擬機（這個進程）能構從操作系統那裡挖到的最大的內存 以位元組為單位

totalMemory（）這個方法返回的是java虛擬機現在已經從操作系統那裡挖過來的內存大小 也就是java虛擬機這個進程當時所佔用的所有內存

freeMemory為當前jvm中沒有使用的內存

附 jvm參數說明 （轉自）

server:一定要作為第一個參數 在多個CPU時性能佳

Xms java Heap初始大小 默認是物理內存的 /

Xmx java heap最大值 建議均設為物理內存的一半 不可超過物理內存

XX:PermSize:設定內存的永久保存區初始大小 預設值為 M （我用visualvm exe查看的）

XX:MaxPermSize:設定內存的永久保存區最大 大小 預設值為 M （我用visualvm exe查看的）

XX:SurvivorRatio= :生還者池的大小 默認是 如果垃圾回收變成了瓶頸 您可以嘗試定製生成池設置

XX:NewSize: 新生成的池的初始大小 預設值為 M

XX:MaxNewSize: 新生成的池的最大大小 預設值為 M

如果 JVM 的堆大小大於 GB 則應該使用值 XX:newSize= m XX:MaxNewSize= m XX:SurvivorRatio= 或者將堆的總大小的 % 到 % 分配給新生成的池 調大新對象區 減少Full GC次數

+XX:AggressiveHeap 會使得 Xms沒有意義 這個參數讓jvm忽略Xmx參數 瘋狂地吃完一個G物理內存 再吃盡一個G的swap

Xss 每個線程的Stack大小 Xss 這使得JBoss每增加一個線程（thread）就會立即消耗 M內存 而最佳值應該是 K 默認值好像是 k

verbose:gc 現實垃圾收集信息

Xloggc:gc log 指定垃圾收集日誌文件

Xmn young generation的heap大小 一般設置為Xmx的 分之一

XX:+UseParNewGC 縮短minor收集的時間

XX:+UseConcMarkSweepGC 縮短major收集的時間 此選項在Heap Size 比較大而且Major收集時間較長的情況下使用更合適

XX:userParNewGC 可用來設置並行收集【多CPU】

XX:ParallelGCThreads 可用來增加並行度【多CPU】

C. 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=… 為一個替代路徑。

D. 怎麼優化java 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區進行多次復制，這樣可以增加對象再年輕代的存活時間，增加在年輕代即被回收的概論。

E. java（jvm)內存怎麼設置。網上的看不懂啊。你還是告訴一步一步怎麼操作吧，在線等

java本身的內存是沒法設置的，只能設置java虛擬機或者運行java項目的伺服器的內存，而前者是在開發工具中設置的，後者是在伺服器的配置文件中進行設置的

你這個目測是啟動jvm的東西報的錯，應該是少了一個文件或者是文件路徑錯誤，使工具啟動jvm失敗，與jvm的內存沒有關系，如果有條件，推薦用eclipse

F. 如何設置Java虛擬機JVM啟動內存參數

-Xmx Java Heap最大值，默認值為物理內存的1/4，最佳設值應該視物理內存大小及計算機內其他內存開銷而定；
-Xms Java Heap初始值，Server端JVM最好將-Xms和-Xmx設為相同值，開發測試機JVM可以保留默認值；
-Xmn Java Heap Young區大小，不熟悉最好保留默認值；
-Xss 每個線程的Stack大小，不熟悉最好保留默認值；
2. 如何設置JVM內存分配：
（1）當在命令提示符下啟動並使用JVM時（只對當前運行的類Test生效）：
java -Xmx128m -Xms64m -Xmn32m -Xss16m Test
（2）當在集成開發環境下（如eclipse）啟動並使用JVM時：
a. 在eclipse根目錄下打開eclipse.ini，默認內容為（這里設置的是運行當前開發工具的JVM內存分配）

G. 如何設置Java虛擬機JVM啟動內存參數

設置Java虛擬機JVM啟動內存參數方法如下：
Tomcat修改TOMCAT_HOME/bin/catalina.bat，在[echo Using CATALINA_BASE: "%CATALINA_BASE%"] 上面加入，比如：

set JAVA_OPTS= -server -Xms1536m -Xmx1536m或者JAVA_OPTS="-server -Xms1536m -Xmx1536m"，
伺服器模式參數-server不加也可以 ，就變成
set JAVA_OPTS= -Xms1536m -Xmx1536m或者JAVA_OPTS=" -Xms1536m -Xmx1536m"，

H. java代碼怎麼設定啟動時的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值。