本文目录一览:
JVM常用参数
-Xmx4g 初始堆大小 4g
-Xms4g 更大堆大小4g
-Xmn512m 年轻代大小(1.4or lator)整个JVM内存大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m,所以增大年轻代后,将会减小年老代大小。此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8
-XX:MetaspaceSize=256m 设置元空间初始大小为256m
-XX:MaxMetaspaceSize=512m 设置元空间更大可分配大小512m
-Xss256k 每个线程的堆栈大小256k
-XX:+ExplicitGCInvokesConcurrent 降低每次Full GC的时间,其实就是启用多线程去执行
-XX:+UseConcMarkSweepGC 启用CMS做为垃圾收集
-XX:+UseCMSInitiatingOccupancyOnly 只有开启了这个参数,CMSInitiatingOccupancyFraction这个参数才会生效
-XX:CMSInitiatingOccupancyFraction=70 CMS垃圾收集器,当老年代达到70%时,触发CMS垃圾回收。
-XX:ParallelGCThreads=4 选项指定在默认垃圾收集器的并行操作期间使用的线程数为4
-XX:-UseBiasedLocking 关闭用户偏向锁
-XX:AutoBoxCacheMax=20000 参数是设置Integer缓存上限的参数,在VM初始化期间java.lang.Integer.IntegerCache.high属性可以被设置和保存在私有的系统属性sun.misc.VM class中。理论上讲,当系统需要频繁使用Integer时,或者说堆内存中存在大量的Integer对象时,可以考虑提高Integer缓存上限,避免JVM重复创造对象,提高内存的使用率,减少GC的频率,从而提高系统的性能。
-XX:MaxTenuringThreshold=6 设置的是年龄阈值,默认15(对象被复制的次数),这里设置成了6次
-XX:+PrintGCApplicationStoppedTime 打印垃圾收集时 , 系统的停顿时间
-XX:+PrintGCDateStamps 打印CG发生的时间戳
-XX:+PrintGCDetails 来打印详细的GC日志来查看
-XX:+PrintCodeCache 会打印Code Cache区的使用情况。
-Xloggc:/dev/shm/gc.log 指定gc的log日志所在位置/dev/shm/gc.log
-XX:+UseGCLogFileRotation 打开或关闭GC日志滚动记录功能,要求必须设置 -Xloggc参数
-XX:NumberOfGCLogFiles=2 设置滚动日志文件的个数,必须大于1
日志文件命名策略是,filename.0, filename.1, ..., filename.n-1,其中n是该参数的值
-XX:GCLogFileSize=10m 设置滚动日志文件的大小,必须大于8k
当前写日志文件大小超过该参数值时,日志将写入下一个文件
-XX:+HeapDumpOnOutOfMemoryError 表示当JVM发生OOM时,自动生成DUMP文件。
-XX:HeapDumpPath=/root/logs/ 发生了 内存溢出错误 dump路径为root/logs/ (一般与HeapDumpOnOutOfMemoryError参数一块使用)
java jvm内存可以设置多少
-Xmx Java Heap更大值,默认值为物理内存的1/4,更佳设值应该视物理内存大小及计算机内其他内存开销而定;
-Xms Java Heap初始值,Server端JVM更好将-Xms和-Xmx设为相同值,开发测试机JVM可以保留默认值;
-Xmn Java Heap Young区大小,不熟悉更好保留默认值; -Xss 每个线程的Stack大小,不熟悉更好保留默认值;
2
2. 如何分配JVM内存设置:
(1)当在命令提示符下启动并使用JVM时(只对当前运行的类Test生效): java -Xmx128m -Xms64m -Xmn32m -Xss16m Test (2)当在集成开发环境下(如eclipse)启动并使用JVM时:
a. 在eclipse根目录下打开eclipse.ini,默认内容为(这里设置的是运行当前开发工具的JVM内存分配): -vmargs -Xms40m -Xmx256m
-vmargs表示以下为虚拟机设置参数,可修改其中的参数值,也可添加-Xmn,-Xss,另外,eclipse.ini内还可以设置非堆内存,如:-XX:PermSize=56m,-XX:MaxPermSize=128m.
此处设置的参数值可以通过以下配置在开发工具的状态栏显示: 在eclipse根目录下创建文件options,文件内容为:org.eclipse.ui/perf/showHeapStatus=true
修改eclipse根目录下的eclipse.ini文件,在开头处添加如下内容: -debug options -vm javaw.exe
重新启动eclipse,就可以看到下方状态条多了JVM信息.
b. 打开eclipse-窗口-首选项-Java-已安装的JRE(对在当前开发环境中运行的java程序皆生效)
编辑当前使用的JRE,在缺省VM参数中输入:-Xmx128m -Xms64m -Xmn32m -Xss16m
c. 打开eclipse-运行-运行-Java应用程序(只对所设置的java类生效) 选定需设置内存分配的类-自变量,在VM自变量中输入:-Xmx128m -Xms64m
选定需设置内存分配的类-自变量,在VM自变量中输入:-Xmx128m -Xms64m -Xmn32m -Xss16m
注:如果在同一开发环境中同时进行了b和c设置,则b设置生效,c设置无效,如:
开发环境的设置为:-Xmx256m,而类Test的设置为:-Xmx128m -Xms64m,则运行Test时生效的设置为: -Xmx256m -Xms64m
(3)当在服务器环境下(如Tomcat)启动并使用JVM时(对当前服务器环境下所以Java程序生效): a. 设置环境变量: 变量名:CATALINA_OPTS
变量值:-Xmx128m -Xms64m -Xmn32m -Xss16m
3
b. 打开Tomcat根目录下的bin文件夹,编辑catalina.bat,将其中
的%CATALINA_OPTS%(共有四处)替换为:-Xmx128m -Xms64m -Xmn32m -Xss16m
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.dump
直接内存配置
-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:CMSInitiatingOccupancyFraction 默认值为68
碎片整理参数,如果碎片不整理,可能造成没达到阈值就会触发老年代垃圾回收
-XX:+UseCMSCompactAtFullCollection :在CMS垃圾收集完成之后,进行一次内存碎片整理
-XX:+CMSFullGCsBeforeCompaction=n :在n次CMS回收后进行一次内存碎片整理
使用CMS回收 *** 去的perm区,默认情况下,还需要触发一次FullGC
-XX:+CMSClassUnloadingEnabled
XX:UseG1GC 开启G1垃圾收集器
两个重要的参数
-XX:MaxGcPasuseMillis :指定目标更大停顿时间,如果停顿的时间过小,一次收集的区域数量也会变小
就会增加FullGC的可能
-XX:parallelGCThreads :设置并行回收的GC线程数量
-XX:InitiatingHeapOccupancyPercent :设置整个堆使用率达到多少时,触发并发标记的执行,默认是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:+PrintGCApplicationConcurrentTime 打印应用程序的执行时间
-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:
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内存设置多大合适?Xmx和Xmn如何设置?
问题:
新上线一个java服务,或者是RPC或者是WEB站点, 内存的设置该怎么设置呢?设置成多大比较合适,既不浪费内存,又不影响性能呢?
分析:
依据的原则是根据Java Performance里面的推荐公式来进行设置。
具体来讲:
Java整个堆大小设置,Xmx 和 Xms设置为老年代存活对象的3-4倍,即FullGC之后的老年代内存占用的3-4倍
永久代 PermSize和MaxPermSize设置为老年代存活对象的1.2-1.5倍。
年轻代Xmn的设置为老年代存活对象的1-1.5倍。
老年代的内存大小设置为老年代存活对象的2-3倍。
*** W:
1、Sun官方建议年轻代的大小为整个堆的3/8左右, 所以按照上述设置的方式,基本符合Sun的建议。
2、堆大小=年轻代大小+年老代大小, 即xmx=xmn+老年代大小 。 Permsize不影响堆大小。
3、为什么要按照上面的来进行设置呢? 没有具体的说明,但应该是根据多种调优之后得出的一个结论。
如何确认老年代存活对象大小?
方式1(推荐/比较稳妥):
JVM参数中添加GC日志,GC日志中会记录每次FullGC之后各代的内存大小,观察老年代GC之后的空间大小。可观察一段时间内(比如2天)的FullGC之后的内存情况,根据多次的FullGC之后的老年代的空间大小数据来预估FullGC之后老年代的存活对象大小(可根据多次FullGC之后的内存大小取平均值)
方式2:(强制触发FullGC, 会影响线上服务,慎用)
方式1的方式比较可行,但需要更改JVM参数,并分析日志。同时,在使用CMS回收器的时候,有可能不能触发FullGC(只发生CMS GC),所以日志中并没有记录FullGC的日志。在分析的时候就比较难处理。
*** W:使用jstat -gcutil工具来看FullGC的时候, CMS GC是会造成2次的FullGC次数增加。 具体可参见之前写的一篇关于jstat使用的文章
所以,有时候需要强制触发一次FullGC,来观察FullGC之后的老年代存活对象大小。
注:强制触发FullGC,会造成线上服务停顿(STW),要谨慎,建议的操作方式为,在强制FullGC前先把服务节点摘除,FullGC之后再将服务挂回可用节点,对外提供服务
在不同时间段触发FullGC,根据多次FullGC之后的老年代内存情况来预估FullGC之后的老年代存活对象大小
如何触发FullGC ?
使用jmap工具可触发FullGC
jmap -dump:live,format=b,file=heap.bin pid 将当前的存活对象dump到文件,此时会触发FullGC
jmap -histo:live pid 打印每个class的实例数目,内存占用,类全名信息.live子参数加上后,只统计活的对象数量. 此时会触发FullGC
具体操作实例:
以我司的一个RPC服务为例。
*** W:刚上线的新服务,不知道该设置多大的内存的时候,可以先多设置一点内存,然后根据GC之后的情况来进行分析。
初始JVM内存参数设置为: Xmx=2G Xms=2G xmn=1G
使用jstat 查看当前的GC情况。如下图:
YGC平均耗时: 173.825s/15799=11ms
FGC平均耗时:0.817s/41=19.9ms
平均大约10-20s会产生一次YGC
看起来似乎不错,YGC触发的频率不高,FGC的耗时也不高,但这样的内存设置是不是有些浪费呢?
为了快速看数据,我们使用了方式2,产生了几次FullGC,FullGC之后,使用的jmap -heap 来看的当前的堆内存情况(也可以根据GC日志来看)
heap情况如下图:(命令 : jmap -heap pid)
上图中的concurrent mark-sweep generation即为老年代的内存描述。
老年代的内存占用为100M左右。 按照整个堆大小是老年代(FullGC)之后的3-4倍计算的话,设置各代的内存情况如下:
Xmx=512m Xms=512m Xmn=128m PermSize=128m 老年代的大小为 (512-128=384m)为老年代存活对象大小的3倍左右
调整之后的,heap情况
GC情况如下:
YGC 差不多在10s左右触发一次。每次YGC平均耗时大约9.41ms。可接受。
FGC平均耗时:0.016s/2=8ms
整体的GC耗时减少。但GC频率比之前的2G时的要多了一些。
注: 看上述GC的时候,发现YGC的次数突然会增多很多个,比如 从1359次到了1364次。具体原因是?
总结:
在内存相对紧张的情况下,可以按照上述的方式来进行内存的调优, 找到一个在GC频率和GC耗时上都可接受的一个内存设置,可以用较小的内存满足当前的服务需要
但当内存相对宽裕的时候,可以相对给服务多增加一点内存,可以减少GC的频率,GC的耗时相应会增加一些。 一般要求低延时的可以考虑多设置一点内存, 对延时要求不高的,可以按照上述方式设置较小内存。
补充:
永久代( *** 区)并不在堆内,所以之前有看过一篇文章中描述的 整个堆大小=年轻代+年老代+永久代的描述是不正确的。
转自:
-verbose:gc 现实垃圾收集信息
-Xloggc:gc.log 指定垃圾收集日志文件
-Xmn:young generation的heap大小,一般设置为Xmx的3、4分之一
-XX:SurvivorRatio=2 :生还者池的大小,默认是2,如果垃圾回收变成了瓶颈,您可以尝试定制生成池设置
-XX:NewSize: 新生成的池的初始大小。 缺省值为2M。
-XX:MaxNewSize: 新生成的池的更大大小。 缺省值为32M。
+XX:AggressiveHeap 会使得 Xms没有意义。这个参数让jvm忽略Xmx参数,疯狂地吃完一个G物理内存,再吃尽一个G的swap。
-Xss:每个线程的Stack大小,“-Xss 15120” 这使得JBoss每增加一个线程(thread)就会立即消耗15M内存,而更佳值应该是128K,默认值好像是512k.