大家好，我是方木

排查和解决 OOM(Out of Memory)

常见的问题排查方式

查看服务的进程是否存在

`ps -ef | grep 服务名 ps -aux | grep 服务名`

查看服务的日志

`cat -n xxx_log |grep "OutOfMemoryError"`

**「java.lang.OutOfMemoryError GC overhead limit exceeded oracle官方给出了这个错误产生的原因和解决方法：」**

> ?
>
> 大概意思就是说，JVM花费了98%的时间进行垃圾回收，而只得到2%可用的内存，频繁的进行内存回收(最起码已经进行了5次连续的垃圾回收)，JVM就会曝出ava.lang.OutOfMemoryError: GC overhead limit exceeded错误。
>
> ?

查看堆内存占用概况

`jmap -heap 进程号`

查看堆中对象的统计信息

`jmap -histo 进程号 | head -n 100`

查看GC统计信息

`jstat -gcutil 进程号`

```bash
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT
0.00 0.00 100.00 99.94 90.56 87.86 875 9.307 3223 5313.139 5322.446

S0：幸存1区当前使用比例
S1：幸存2区当前使用比例
E：Eden Space（伊甸园）区使用比例
O：Old Gen（老年代）使用比例
M：元数据区使用比例
CCS：压缩使用比例
YGC：年轻代垃圾回收次数
FGC：老年代垃圾回收次数
FGCT：老年代垃圾回收消耗时间
GCT：垃圾回收消耗总时间
```

生产对堆快照Heap dump

`jmap -dump:format=b,file=/tmp/进程号_jmap_dump.hprof 进程号`

分析生成的堆快照

使用 Eclipse Memory Analyzer 工具。 下载地址： www.eclipse.org/mat/downloa…

mat 加载 dump文件

内存泄露

内存泄露的背景，新启了一个新项目，长时间放在测试环境运行测试中，过了一周多，突然服务重启的时候，一直都是重启失败，看了下监控面板发现，从7月8日直到7月14日，每天内存都在下降（正常情况下 应该在某个区间来回波动），此时开始怀疑程序写了某些bug导致内存泄露了

服务机器指标

服务机器指标

后续又让服务跑了一段时间后，主动生成此时的jvm dump文件，使用 mat 工具分析后发现 ByteArrayInputStream 的数据比较，评估了下，预计就是使用流不规范 未及时回收导致的。真是低级的错误

涉及修改的代码

代码的逻辑很简单：从apollo获取对应key的配置，将其配置加载到 Properties中，怀疑这块代码使用不规范导致内存泄露

String configTmp = config.getProperty("canal_config_template", "");
Properties canalConfigProperties.load(new ByteArrayInputStream(configTmp.getBytes(StandardCharsets.UTF_8)));

修改方案,jdk1.8 可以通过将 ByteArrayInputStream定义在 try中，使用完会自动回收资源，相当于 在finnaly{byteArrayInputStream.close();}

Properties canalConfigProperties;
String configTmp = config.getProperty("canal_config_template", "");
try (ByteArrayInputStream byteArrayInputStream = new ByteArrayInputStream(configTmp.getBytes(StandardCharsets.UTF_8))) {
    canalConfigProperties.load(byteArrayInputStream);
}

后续进行一段时间的压测，发现 Memory Basic 趋于一个区间，终于正常了（幸好还没上线）

服务机器指标

OOM 问题排查 案例一

canal 测试环境突然报OOM异常

?

前提：canal 会先监听 mysql 所有的 binlog，将 binlog 进行解析得到 sql 过滤掉哪些 不需要监听的 table。

?

由于现在在每个环境都配置了，服务发生OOM的时候 会自动生成 dump文件
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof

dump 文件

拿到dump文件使用 mat 开始一顿操作后，发现某个字符串特别大 300多M，解析它的对象 也以及 200M多了，在此次出现OOM，分析了执行多堆栈信息，发现api_scenario_report_detail这张表执行了一条 300多M的sql（这个就太夸张了），定位了问题后 与 对应开发人员沟通后得知，他们那边使用开源压测项目，里面有遗留的 bug，导致出现了这一条300多M的 sql（有惊无险，还好不是 canal 的 bug)

堆分析

堆分析

OOM 问题排查 案例二

?

前提：一个conusmer的服务 是专门用来监听 kafka中消息，将其数据进行加处理后，发送至es中

?

服务发生 OOM 后，很快就拿到了 dump文件，同样使用 mat 工具进行分析，分析后 发现 ArrayBlockingQueue 中在线程池等待的对象100多个，一个对象差不多 4M左右，相当于在 队列里 堆积了 400多M 的对象，还在上涨。此次在确认了下 测试环境 consumer 这个服务 kafka 中的消息突然激增，导致 consumer 消费能力跟不上，再加上测试环境的服务机器都是 1.8核1.6G，服务本身的一些其他逻辑 可用的内存本身就500多M，也就导致了此次的 OOM 的问题。（准备写这个文章的时候，这个 dump文件 找不到了）

查看相应的代码逻辑

int cpuNum = Runtime.getRuntime().availableProcessors();
if(cpuNum < 1 ) {
    cpuNum = 1;
}
// configProperties.getKafkaComsumerQueue() 之前的配置是 500
threadPoolExecutor = new ThreadPoolExecutor(1,cpuNum,5000L, TimeUnit.MILLISECONDS,new ArrayBlockingQueue<>(configProperties.getKafkaComsumerQueue()),new ThreadPoolExecutor.CallerRunsPolicy());
...
// 监听消费kafka对应的topic消息

之前 configProperties.getKafkaComsumerQueue() 的配置是 500，如果一个对象是4M的话，得至少快 2G的内存 才能防止 OOM…
既然是测试环境，而且平时数据量都比较小，没必要申请更搞配置的机器，因此降低 队列的长度即可解决问题，为了安全期间后 再出现此类的 OOM，甚至上游的对象那天变大了 又导致 OOM，因此 将队列的大小改为 100（至少先保证服务可用～）

总结

「大家用到线程池的话，一定要留意 执行的任务是 CPU密集型和IO密集型，以及队列的大小需要预留多少」

关注我的微信公众号：Java架构师进阶编程 获取最新面试题，电子书

专注分享Java技术干货，包括JVM、SpringBoot、SpringCloud、数据库、架构设计、面试题、电子书等，期待你的关注！