目录
垃圾收集 (garbage collection) 机制是 java 的一大优势特性, 为充分榨取 jvm 性能, 避免系统因垃圾收集不及时导致的 oom (outofmemory, 内存溢出)问题, 或内存饱和出现无法响应用户请求的情况, 就需要根据服务器配置及应用复杂度对 gc 策略进行优化, 以确保系统正常运行.
jvm根据运行于其中的对象的生存时间, 将它们分为3种, 并分别存放在jvm的不同内存区域中. 这种对象存放空间的管理方式叫做 generation管理方式.
又叫 minor gc(次收集), young gc 经常发生, 且其每次消耗的时间较短 —— 它只对young generation 中的对象进行垃圾收集.
触发条件:
在 young generation(新生代)的 edne 区的空间不足以容纳新生成的对象时执行, 同时会将 eden 区与 from survivor 区中尚且存活的对象移动至空闲的 to survivor 区中.
—— 程序运行过程中, 始终有一个 survivor 区是完全处于空闲状态的, 如果不是, 说明应用程序出现故障了.
又叫 major gc(主收集), 是对整个 java heap 中的对象(不包括永久代/元空间)进行垃圾收集, 此 gc 操作耗时久, 对系统的性能影响较大, 因此在 jvm 的调优中, 很多工作是针对 full gc 的调优 —— 要尽可能减少 full gc 的频率.
full gc 是一种"昂贵"的垃圾收集方式, 它要对整个heap 进行垃圾收集, 并做一定的空间整理, 这会使 stop-the-world 的时间变长.
1) 年老代(tenured)空间不足:
- 通过 minor gc 后进入老年代的对象的体积大于老年代的可用空间;
- 由eden块、from space 块向 to space 复制存活对象时, 它们的体积大于 to space 的大小, 系统就会把这些对象转存到老年代, 而老年代的可用空间小于这些对象的体积.
2) system.gc() 被显式调用, 系统建议执行 full gc, 但并不会立即执行 —— 非常影响程序性能, 建议禁止使用;
3) 上一次 gc 之后 heap 各个区域空间的动态变化.
1) jvm 会试图为相关 java 对象在年轻代的 eden 区中初始化一块内存区域;
2) 当 eden 区空间足够时, 内存申请结束. 否则执行下一步;
3) jvm 试图释放在 eden 区中所有不活跃的对象(即 出发young gc), 释放后若eden空间仍然不足以放入新对象时, jvm 会试图将部分 eden 区中活跃的对象迁移至 survivor 区;
4) survivor 区被用来作为 eden 区及老年代的中间交换区域, 当老年代空间足够时, survivor 区中存活了一定次数的对象会被迁移到老年代;
5) 当年老代空间不够时, jvm会在老年代进行完全的垃圾回收(full gc);
6) full gc 后, 若 survivor 区及老年代仍然无法存放从 eden 区复制过来的对象, 则会导致 jvm 无法在 eden 区为新生成的对象申请内存, 即出现 "out of memory".
oom(out of memory)异常一般主要有如下2种原因:
1) 老年代溢出, 表现为: java.lang.outofmemoryerror:javaheapspace
这是最常见的情况, 产生的原因可能是: 设置的内存参数-xmx过小或程序的内存泄露及使用不当问题.
2) 持久代溢出，表现为: java.lang.outofmemoryerror:permgenspace
通常由于持久代设置过小, 动态加载了大量 java 类而导致溢出, 解决办法唯有将参数 -xx:maxpermsize 调大(一般256m能满足绝大多数应用程序需求).
只有一条gc线程, 运行时需要暂停用户程序(stop-the-world).
实现: serial(用于新生代, 采用复制算法)、serial old(用于老年代, 采用标记-整理算法).
有多条gc线程, 运行时也需要暂停用户程序(stop-the-world).
实现: parnew(用于新生代, 采用复制算法)、parallel scavenge(用于新生代, 采用复制算法)、parallel old(用于老年代, 采用标记-整理算法).
有一条或多条gc线程, 且需要在部分阶段暂停用户程序(stop-the-world), 部分阶段与用户程序并发执行.
实现: concurrent mark sweep(cms, 用于老年代, 采用标记-清除算法).
g1垃圾回收器在 oracle jdk 7 开始提供完整支持, 它是 server 型的 gc, 主要针对多核处理器和大内存的服务器, 能够以很高的概率 满足开发人员对停顿时间的要求, 同时还能保证高吞吐量.
与 cms 收集器相比, g1收集器的优势:
1) 基于标记-整理算法, 不会产生大量的内存碎片;
2) 可以更加精确地控制停顿时间, 在不牺牲吞吐量前提下, 实现低停顿垃圾回收.
g1收集器的实现原理:
g1收集器能够避免全区域的垃圾收集, 它把堆内存划分为大小固定的几个独立区域, 并跟踪这些区域的垃圾收集进度, 同时在后台维护一个优先级列表, 每次根据所允许的收集时间, 优先回收垃圾最多的区域.
—— 区域划分和优先级区域回收机制, 确保g1收集器可以在有限的时间内获得最高的垃圾收集效率.
g1的长期目标是取代cms (concurrent mark-sweep collector) 并发标记-清除收集器.
所有 jvm 都必须支持这些参数的功能, 而且向后兼容, 如:
-client : 设置 jvm 使用 client 模式, 特点是启动速度比较快, 但运行时性能和内存管理效率不高. 通常用于客户端应用程序或开发调试; 在32位环境下直接运行 java 程序默认启用该模式.
-server : 设置 jvm 使 server 模式, 特点是启动速度比较慢, 但运行时性能和内存管理效率很高, 适用于生产环境; 在具有64位能力的jdk环境下默认启用该模式.
各 jvm 厂商应该都实现这些参数的功能, 但是并不保证所有的 jvm 实现都满足, 且不保证向后兼容;
此类参数各个jvm实现会有所不同, 将来可能会不被支持, 需要慎重使用.
注意: 在"-xx:"后的参数若不需要赋值, 即只是用来配置开启或关闭相应选项, 则需要有 "+" (开启) 或 "-" (禁止) , 否则应用程序将在日志文件 (如 tomcat 的日志文件 catalina.out ) 中抛出如下错误:
missing +/- setting for vm option 'useconcmarksweepgc'. error: could not create the java virtual machine. error: a fatal exception has occurred. program will exit.
可以看出, 这里缺少了 "+/-" 符号, 导致虚拟机启动异常, 修改后即可正常启动.
-xx:+useserialgc # 使用 serial & serial old 串行收集器(jdk 5以前的主要收集方式), 是client模式的默认设置.
-xx:+useparnewgc # 使用 parnew & serial old 收集器, 即对新生代使用并行收集, 提高收集效率(缩短young gc的时间), 不推荐. -xx:+useparallelgc # 使用 parallel scavenge & parallel old 并行收集器, 吞吐量优先, 会消耗更多内存, 是server模式的默认设置. -xx:+useparalleloldgc # 对老年代使用 parallel old 并行收集器(jdk 6开始支持). -xx:parallelgcthreads=20 # 配置并行收集器的线程数, 即并行执行垃圾收集任务的线程个数. # 此值最好与cpu处理器的个数相同(默认即相同). -xx:gctimeratio=49 # 设置系统用作gc的时间比例, 如49, 则gc时间比为 1/(1+49) = 2%, 即java用2%的时间来做垃圾收集. # 如果此值设置过大, 即gc时间太少导致gc无法完成, jvm会压缩新生代的大小以适应此配置. -xx:maxgcpausemillis=100 # 设置每次新生代垃圾收集的最长毫秒值, 如果时间久而新生代的大小不足以支撑到此时间, # jvm会自动调整新生代的大小以满足此值. 若仍然无法满足, 则会调整gctimeratio. -xx:+useadaptivesizepolicy # 使并行收集器自动设定 eden 区的大小与相应的 survivor 区的比例, # 以达到目标系统规定的最低响应时间或收集频率等. 建议在使用并行收集器时始终开启此选项.
-xx:+useconcmarksweepgc # jdk 5开始提供支持, 以响应时间优先--即缩短full gc的时间. # jvm 会根据系统配置自行设置使用 parnewgc & cms(serial old作为替补)收集器. # 建议在 heap size 较大且 full gc 时间较长, 对响应时间的需求大于对吞吐量的需求, 能够承受垃圾回收线程和应用线程共享cpu资源等情况下使用. -xx:+usecmscompactatfullcollection # cms是不会移动内存的, 此参数设置在每次full gc后对老年代空间进行压缩整理, 会影响性能, 但是能减少内存碎片. -xx:cmsinitiatingoccupancyfraction=70 # 触发cms收集器的内存占用阈值, 默认为90%: 当老年代内存空间使用率达到90%时, 就开始对老年代进行cms并发垃圾收集. # 这个参数设置不当, 将发生promotion failed(晋升失败). -xx:cmsfullgcsbeforecompaction=10 # 由于并发收集器不对内存空间进行压缩整理, 所以运行一段时间后会产生"碎片", 使得运行效率降低. 此配置项用来设置在几次gc后触发一次内存整理. # 此配置项即将被移除(jdk 8已不建议使用).
-xx:+useg1gc # 使用g1收集器 -xx:maxgcpausemillis=200 # 设置回收器的最大停顿毫秒值, 这是一个概率目标, jvm将尽最大努力去实现它. -xx:g1reservepercent=15 # 设置堆的临时上限, 以防止因堆扩大失败而导致的异常. 默认值是10. -xx:g1heapregionsize=16 # 使用 g1 的 java 堆细分为大小相等的区域(region), 此选项是设置单个区域的大小, 默认值是基于堆大小的一种人体工效划分, 最小值是1mb, 最大值是32mb. # 人体工效: 根据平台相关的默认选择和根据需求动态垃圾回收的行为统称为人体工效, 人体工效的作用就是可以通过少量的命令行选项就可以让jvm提供最合适的性能.
-xnoclassgc # 禁用类垃圾收集, 能提高性能. -xx:maxheapfreeratio=70 # gc过后堆的最大空闲空间比例, 避免过渡压缩 -xx:minheapfreeratio=40 # gc过后堆的最小空闲空间比例, 避免过度膨胀 -xx:maxtenuringthreshold=5 # 晋升老年代的最大年龄, 默认为15: 新生代对象在15次 minor gc 后将被转移至老年代. --- 必须在0-15之间. # 如果设置为0, 等同于去掉了新生代的空间, 新生代对象将会越过 survivor 区直接进入老年代, 很快就会占满老年代发生full gc. # 同时, 这在老年代对象较多的应用中却可以提高效率. # 如果将此值调大, 则新生代对象会在 survivor 区进行多次复制, 即增加了对象在新生代的存活时间. -xx:pretenuresizethreshold=10 # 晋升老年代的对象的大小, 默认为0. 比如设为10m, 则超过10m的对象将越过 eden区, 直接存入老年代. -xx:+usethreadpriorities # 启用本地线程优先级api, 使 java.lang.thread.setpriority() 生效, 不启用则无效 -xx:+disableexplicitgc # 禁用写在程序中的 system.gc(), 即禁止开发人员调用 gc() 方法影响性能. -xx:+explicitgcinvokesconcurrent # 配置 system.gc() 可以和应用程序一起并发执行. # system.gc() 用来回收不用的内存, 此方法只是"建议" jvm 回收内存, 不能强制回收, 具体回收时机由 jvm 决定. -xx:targetsurvivorratio=90 # 允许90%的 survivor 区被占用(jvm默认为50%), 提高对于 survivor 区的使用率 -xx:softreflrupolicymspermb=1 # soft reference(弱引用)在虚拟机中比在客户机中存活的时间更长, 其清除频率可用此命令来控制. # 此命令用来指定每 mb 堆空间中 soft reference 存活的秒数, 默认值为1000毫秒: 对象的最后一个强引用被收集之后, 存活1秒钟. # 这是个近似值: soft reference只会在垃圾收集时才会被清除, 而垃圾收集并不总是发生. 可改为0, 客户机中不使用就立即清除.
在内存调优中, 内存设置越大, 处理请求的效率也就越高, 但同时垃圾收集所需要的时间也就越长, 在垃圾收集期间的处理效率肯定会受影响, 因此需要作出相应的权衡.
关于 promotion failed(晋升失败) : jvm发生young gc时, eden区存活的对象 和 eden区的from块中存活的对象, 两者的体积超过了eden区中to块的大小, young gc的悲观策略将使这些存活的对象都迁移到old区, 而此时old区的大小不足以容纳这些对象, 从而发生promotion failed, 程序将暂停很长时间.
cmsinitiatingoccupancyfraction的设置技巧: 参考:
(xmx-xmn) * (1 - cmsinitiatingoccupancyfraction/100) >= (xmn - xmn/(survivorratior+2))进而推断出：
cmsinitiatingoccupancyfraction <= ( (xmx-xmn) - (xmn - xmn/(survivorratior+2) ) ) / (xmx-xmn) * 100
参考资料:
版权声明
作者: ma_shoufeng(马瘦风)
出处: 博客园
您的支持是对博主的极大鼓励, 感谢您的阅读.
本文版权归博主所有, 欢迎转载, 但未经博主同意必须保留此段声明, 且在文章页面明显位置给出原文链接, 否则博主保留追究法律责任的权利.
如对本文有疑问， 点击进行留言回复！！
关于在IDEA中SpringBoot项目中activiti工作流的使用详解
视频编辑工具ACDSee Luxea Video Editor安装及激活图文教程
java spring整合junit操作(有详细的分析过程)
我要评论
网友评论