线上 JVM 内存溢出， OOM 问题排查求指点。

[jiobanma]

如题，线上有个服务跑着跑着就会 OOM ，导致所有请求失败，内存无法回收。

1. 报错信息

java.lang.OutOfMemoryError: GC overhead limit exceeded
Dumping heap to /xxx/xxx/bootstrap/java_pid39726.hprof ...

2. 排查过程

2.1 JVM 参数

2.2 分析 dump 文件

用 VisualVM 分析 dump 文件发现，有个大对象占用了 33%的内存，如图①，查看该对象，发现里面大概有 200w 个对象，有一部分是空的，最大的几个对象就是顶部的那四五个。这些对象是一个 JSON 字符串，最上面几个大对象排查发现其中的 url 部分有大量重复，可能是前端提交数据或者后端处理 url 拼接的时候循环有问题，导致有大量重复的 url 使得其中这个对象特别的大。排查数据库，length 这个字段，最大的几个分别占用 9469799 ，4764368 ，4725799 ，4571257 。

3. 其他

JVM 调优经验较少，不知道是不是这么个排查流程，也不知道排查的点对不对。希望有经验的大佬给点指导。 补充几点：

1. 目前准备先把数据库里的重复的 url 干掉，但是应该解决不了实际问题，最大的几个对象加起来也就不到 100m 。
2. 估计是哪里的接口或者操作触发了大批量的查询，导致数据都压到了内存中。先排查下代码，看看哪里有批量查询的地方，然后加一些范围条件。

[e7]

@jiobanma limit 兜底是个好习惯

[luozic]

定期扫 db 打性能分析日志，做优化。

[zhangyaxiao072]

可能是哪里的代码又问题；下次溢出可以多抓几次线程，jstack ，仔细看看里面的信息

[mitsuizzz]

@jiobanma 数据库层面有慢 SQL 监控的话，应该早就可以发现原因了。

[jiobanma]

@e7 是呀 以后要注意了
@luozic
@mitsuizzz
慢 sql 有监控的，只是项目太忙，一直没时间优化。而且很多都是老项目里的了，业务比较复杂，老员工都走的差不多了，不出大问题其他人不太敢动代码

[NeoZephyr]

@manecocomph 继续泄露看到的也是 char[] bytes[] 大头啊