console:可以直观查看堆内存,堆外内存的使用情况,在jdk的bin目录下

 如果内存持续上涨,且gc后下降较少,可以确定存在内存泄漏,再使用visualvm/MemoryAnalyzer确定内存泄漏位置

MAT的使用:

先生成dump文件,命令: jmap -dump:live,file=0908dump.hprof(文件名),format=b pid

在mat中打开dump文件,点击泄漏怀疑点

 根据Keywords排查代码

使用top命令查看内存和cpu占用高的java进程: 命令 top -c -p $(pgrep -d\',\' -f java)

top命令的res表示实际占用的内存,这个数值可能比xmx设置的要大,因为统计内容不同,xmx只是堆内存(包括新生代(eden,from,to),老年代),res范围更广,还包括metaDate,堆外内存等,如果想查看堆内存每块空间具体占用情况,使用 jmap -heap pid 命令

 这些数据在jconsole中也可以看到,用jmap命令看到的只是当前时刻的内存使用情况,jconsole可以看到连续的变化

如果想用命令查看堆外内存也是可以的:

1 在启动命令上加 -XX:NativeMemoryTracking=detail

2 启动后: jcmd pid VM.native_memory baseline 设置当前状态为基准状态

3 程序运行一段时间后: jcmd pid VM.native_memory summary.diff scale=MB

这样就会显示这段时间内的堆外内存变化情况

排查cpu飙高:

1 根据cpu占用高的进程确定是哪些线程导致的:top -Hp pid 

 比如当前 29814,29688两个线程的cpu占用高,再用 jstack pid | /xxx/xxx.dump(导出的文件路径),将这两个线程号转成16进制,当前是10进制,用16进制号在文件中搜索具体代码,比如出现 TIMED_WAITING (on object monitor),是因为synchronized锁使用的范围太大导致许多线程等待锁的释放

根据RUNNABLE确定业务代码的位置

这种方式生产的dump文件只是当前时刻的线程状态