记一次OOM排查优化问题

一、OOM简介

以下为转载的一些知识点，这边主要是记录以下排查过程
1.jvm内存分配不够，电脑内存的大小，不等于java程序能够使用的内存大小。jvm分配的内存大小，可以在JVM启动时，通过配置文件配置。
2.内存利用不当，有两个表现，内存泄漏和内存溢出。

内存泄漏：对象使用完毕后，不能够及时销毁，变成内存垃圾，如果不能够及时清理，内存垃圾越来越多，可用内存越来越少，影响程序的健康运行。虽然java提供GC机制，可以自动进行内存回收，但是逻辑错误，可能导致垃圾堆积过多。如，将太多的局部作用的对象保存为全局对象。
内存溢出：请求分配的内存，比jvm剩余可用内存少，导致程序不能够正确运行，导致崩坏。

二、排查准备

初步计划就是在oom的时候拿到内存的使用记录，然后用工具进行图表分析（图标更直观）
1、在JVM添加参数

-XX:+HeapDumpOnOutOfMemoryError
表示当JVM发生OOM时，自动生成DUMP文件
-XX:HeapDumpPath=/tmp/oom
DUMP文件存放的位置

如果平时想生成dump文件查看一下内存使用情况的话，可以用下面这句话：

jmap -dump:live,format=b,file=myjmapfile.txt 19570

19570是PID，myjmapfile.txt是你准备好的空白txt文件
dump文件的后缀是hprof，jmap可以把hprof的内容解析成文本放到txt下面

2、hprof分析
JDK自带的jvisualvm.exe
1)
可以看出来很明显在项目的某个类里面，占据了大量的内存，然后查看代码
2）
可以看出new String(""),对于每次的构造器构造对象的时候为每个字段都创建了一个内容为空字符串的String对象，这里可以直接赋值为""（代码是遗留问题，不是我们一手开发）。不是很明确主要问题是不是这里，但是这里的确是个优化点。对于每一条记录都有一个该类的对象，每条记录初始化会占用不少的String对象开销，如果有大量的单条数据query请求，那就会造成内存的浪费。

三、后话

准备下一篇复习以下JVM的内存模型，春招的时候背了很多，现在太久没用过，忘得差不多了