可以先用top命令查询出占用内存最多的进程，然后使用下面指令分析占用内存较大的代码
查看进程的内存镜像信息
jmap -572 // 572表示的是进程id
显示java堆详细信息
jmap -heap -572 // 572表示的是进程id
显示堆中对象的统计信息
jmap -histo:live pid | more
下面结果中，第一列代表数量，第二列代表实例数量，第三列代表内存大小，第四列代表完全限定的类名。
结果实例如下：
image.png
描述：打印类加载器信息
jmap -clstats pid
打印等待终结的对象信息
jmap -finalizerinfo pid
dump jvm内存
jmap -dump:format=b,file=dump_file_name pid
举例：dump pid 为 4738 的 java 进程的内存到 app_mem_dump.bin 文件
jmap -dump:format=b,file=app_mem_dump.bin 4738
dump jvm 线程栈
命令格式：
jstack pid > dump_file_name
举例：dump pid 为 4738 的 java 进程的线程栈到 app_thread_dump.txt 文件
jstack 4738 > app_thread_dump.txt
脚本分享
当服务器线程数超过 2500 时自动 dump 线程数最高的 java 进程的内存及线程栈。
#!/usr/bin/env bash
#
# 服务器线程数达到 2500 以上时 dump 线程数最多的 java 进程的线程及内存
#
source ~/.bashrc
cur_thread_num=`ps -efL | wc -l`
if [ $cur_thread_num -le 2500 ]; then
exit 0
fi
cur_date=`date +"%Y-%m-%d_%H-%M-%S"`
cd ./dumpfile
# 服务器当前线程 dump 到文件:按照线程数由大到小排序显示
ps -efL --sort -nlwp > server_thread_dump_$cur_date
# dump 线程数最多的 jvm 的线程及内存
most_thread_num_pid=`cat server_thread_dump_$cur_date | sed -n '2p' | awk '{print $2}'`
nohup jstack -l $most_thread_num_pid > java_app_thread_dump_${cur_date}_pid_${most_thread_num_pid} &
nohup jmap -dump:format=b,file=java_app_mem_dump_${cur_date}_pid_${most_thread_num_pid} $most_thread_num_pid &
exit 0
如果出现性能问题，首先需要确认是Netty的问题还是业务的问题，通过jstack命令或者jvisualvm工具打印线程堆栈，看看进程都在忙什么，按照线程CPU使用情况进行排序（top -H 命令采集），看线程在忙什么。通常如果采集几次都发现Netty的NIO线程的堆栈停留在select操作上，说明I/O比较空闲，性能平静不是netty。
通过jmap dump内存快照
如果是线上环境，注意dump之前必须先将流量切走，否则大内存dump是直接卡死服务。
# dump当前快照
jmap -dump:live,format=b,file=dump.hprof <pid>
# 触发full gc，然后再dump一次
jmap -dump:live,format=b,file=dump_gc.hprof <pid>
dump:live的作用是会触发Full GC，然后再dump数据，用作gc前后的数据做对比。
