JVM系统优化实践(19):GC生产环境案例(二)

您好,这里是码农镖局CSDN博客,欢迎您来,欢迎您再来~


接昨天的问题继续来说,在高并发场景中,对象过多容易导致OOM。由于高并发导致Young GC存活对象过多,因此会有太多对象进入老年代,导致老年代也被填满,频繁触发Full GC,而老年代空间也很快被塞满。可以用图来表示:

JVM系统优化实践(19):GC生产环境案例(二)_第1张图片

JVM系统优化实践(19):GC生产环境案例(二)_第2张图片 

JVM系统优化实践(19):GC生产环境案例(二)_第3张图片 

JVM系统优化实践(19):GC生产环境案例(二)_第4张图片 

JVM系统优化实践(19):GC生产环境案例(二)_第5张图片 

JVM系统优化实践(19):GC生产环境案例(二)_第6张图片 

因此,有限的内存中存放了过多的对象,而且大多数也都是存活的时候很容易发生OOM。而且系统本身的代码可能也存在着内存泄漏。例如,利用CGLIB动态生成类,来造成Metaspace的内存溢出。JVM的参数设置:-XX:MetaspaceSize=10M -XX:MaxMetaspaceSize=10M

然后输入如下代码:

JVM系统优化实践(19):GC生产环境案例(二)_第7张图片

 

运行代码后,通过jstat,会发现Metaspace数据异常。

再通过JVM栈溢出来实现OOM。JVM参数设置:-Xss1M

代码如下:

JVM系统优化实践(19):GC生产环境案例(二)_第8张图片

 

然后是JVM堆溢出来实现OOM。JVM参数设置:-Xms10M -Xmx10M

代码如下:

JVM系统优化实践(19):GC生产环境案例(二)_第9张图片

 

在一个试用kafka的超大数据量处理的案例中,架构大概是这个样子的:

JVM系统优化实践(19):GC生产环境案例(二)_第10张图片

 

这里面的系统隐患是:

1、一旦kafka故障,那么当前计算对应的数据必须全部驻留内存,并且一直重试等待kafka恢复;

2、计算没有停止的时候,会不停加载更多数据直到OOM。


感谢您的大驾光临!欢迎骚扰,不胜荣幸~

你可能感兴趣的:(技术,jvm,java,GC)