JVM堆配置小于8G的参数一套
在测试环境部署应用时, 收到邮件提示: 推荐我配置如下:
JVM堆配置小于8G,推荐开启CMS垃圾收集器，开启方法：在env中的APP_OPTS中增加JVM参数：
-XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=80
-XX:+UseParNewGC
#缺省#
设置年轻代为并行收集。可与CMS收集同时使用。 JDK5.0以上，JVM会根据系统配置自行设置，所以无需再设置此值。
-XX:+UseConcMarkSweepGC
#年老代使用并发标记清除GC#
设置年老代为CMS并发收集。
CMS流程：
-- 初始标记(CMS-initial-mark)
-- 并发标记(CMS-concurrent-mark)
-- 重新标记(CMS-remark)
-- 并发清除(CMS-concurrent-sweep)
并发重设状态等待下次CMS的触发(CMS-concurrent-reset)。
老年代使用CMS垃圾收集器:
- 特点:以最短回收停顿时间为目标, B/S, 互联网java应用, 重视服务响应速度场景
- 收集算法: MS=Mark Sweep
- 四步骤:
- 初始标记(STW) - initMark
- 并发标记 - concurrentMark
- 重新标记(STW) - remark
- 并发清除 - concurrentSweep
-XX:+CMSParallelRemarkEnabled
降低标记停顿
CMS开启并行remark
在使用UseParNewGC的情况下，尽量减少mark的时间
-XX:+UseCMSCompactAtFullCollection
#在Full收集时使用CMS压缩#
[kəmˈpækt]v. 把……压实；使简洁；使紧密，压缩；
标记-清除的算法, 在收集结束时, 会有大量碎片空间, 碎片过多, 将会给大内存分配造成麻烦, 不得不提前出发一次 FullGC;
CMS收集器提供了个参数: UseCMSCompactAtFullCollection开关参数(默认即开启), 用于在CMS收集器顶不住要进行FullGC时,开启内存碎片的合并整理过程(无法并发).
这样, 空间碎片虽然没有了, 但是STW停顿不得不变长(但是减少了一次FullGC呀!)
打开对年老代的压缩。可能会影响性能，但是可以消除碎片
-XX:+UseCMSInitiatingOccupancyOnly
#仅使用CMS启动占用#
[ˈɑːkjəpənsi]n. 居住/占有/占用
[ɪˈnɪʃieɪt]vt. 开始/创始/发起
表示 CMS GC 只基于 CMSInitiatingOccupancyFraction 触发，
如果未设置该参数则: JVM只会根据 CMSInitiatingOccupancyFraction
触发第一次CMS GC，后续还是会自动触发。
建议同时设置这两个参数。
-XX:CMSInitiatingOccupancyFraction=80
#CMS启动占用分数#
默认老年代使用了68%内存空间以后就会激活, 比较保守, (若应用中老年代增长不是太快), 可以适当调高参数, 以降低内存回收次数从而获得好的性能;
也可根据实际情况，使用G1作为垃圾收集器：-XX:+UseG1GC；
其他相关:
-XX:+CMSScavengeBeforeRemark
强制remark之前开始一次minor gc，减少remark的暂停时间。
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
