关于JVM优化参数整理

-XX:+PrintGC = -verbose:gc
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps

-Xloggc:C:\Users\ligj\Downloads\gc.log

-Xmx3550m 堆最大

-Xms3550m 堆最小

-Xmn2g  新生代大小 

-Xss128k 虚拟机栈大小 

整个JVM内存大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m,所以增大年轻代后,将会减小年老代大小。此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8。

-XX:PermSize=64M 永久区大小

-XX:MaxPermSize=128M 永久区最大大小

-XX:MetaspaceSize=200m;-XX:MaxMetaspaceSize=256m; Java8在物理内存存放元数据。

-XX:+UseSerialGC 使用串行垃圾收集器

-XX:+UseParallelGC 使用并行收集器

-XX:+UseParallelOldGC 年老代使用并行收集器

-XX:+UseParNewGC -XX:+UseConcMarkSweepGC 开启CMS垃圾收集器

-XX:+HeapDumpOnOutOfMemoryError  -XX:HeapDumpPath=${目录}/${目录}/java_heapdump.hprof 
当发生内存错误的时候导出堆栈信息到文件

XX:+PrintReferenceGC 这个参数,这个参数会打印各种引用的处理时间

CMS收集器在Minor GC时会暂停所有的应用线程,并以多线程的方式进行垃圾回收。在Full GC时不再暂停应用线程,而是使用若干个后台线程定期的对老年代空间进行扫描,及时回收其中不再使用的对象。

-XX:+UseG1GC 使用G1垃圾收集器

G1收集器(或者垃圾优先收集器)的设计初衷是为了尽量缩短处理超大堆(大于4GB)时产生的停顿。相对于CMS的优势而言是内存碎片的产生率大大降低。

首先,G1的设计原则就是简单可行的性能调优

开发人员仅仅需要声明以下参数即可:

-XX:+UseG1GC -Xmx32g -XX:MaxGCPauseMillis=200

其中-XX:+UseG1GC为开启G1垃圾收集器,-Xmx32g 设计堆内存的最大内存为32G,-XX:MaxGCPauseMillis=200设置GC的最大暂停时间为200ms。如果我们需要调优,在内存大小一定的情况下,我们只需要修改最大暂停时间即可。

其次,G1将新生代,老年代的物理空间划分取消了。

这样我们再也不用单独的空间对每个代进行设置了,不用担心每个代内存是否足够。

取而代之的是,G1算法将堆划分为若干个区域(Region),它仍然属于分代收集器。不过,这些区域的一部分包含新生代,新生代的垃圾收集依然采用暂停所有应用线程的方式,将存活对象拷贝到老年代或者Survivor空间。老年代也分成很多区域,G1收集器通过将对象从一个区域复制到另外一个区域,完成了清理工作。这就意味着,在正常的处理过程中,G1完成了堆的压缩(至少是部分堆的压缩),这样也就不会有cms内存碎片问题的存在了。

在G1中,还有一种特殊的区域,叫Humongous区域。 如果一个对象占用的空间超过了分区容量50%以上,G1收集器就认为这是一个巨型对象。这些巨型对象,默认直接会被分配在年老代,但是如果它是一个短期存在的巨型对象,就会对垃圾收集器造成负面影响。为了解决这个问题,G1划分了一个Humongous区,它用来专门存放巨型对象。如果一个H区装不下一个巨型对象,那么G1会寻找连续的H分区来存储。为了能找到连续的H区,有时候不得不启动Full GC。

PS:在java 8中,持久代也移动到了普通的堆内存空间中,改为元空间。

引用自:http://blog.jobbole.com/109170/ 






猜你喜欢

转载自blog.csdn.net/wang252949/article/details/79784949