jvm调优常用工具

1、jps 查看进程

2、jmap 查看内存信息，实例个数以及占用内存大小

jmap -histo 14660
jmap -heap 14660
jmap -dump:format=b,file=eureka.hprof 14660 (可以设置内存溢出自动导出dump文件 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./)
用jvisualvm命令工具导入该dump文件分析

3、jstack 查看死锁

jstack 14660
jvisualvm也可以自动检测死锁

找出占用cpu最高的线程堆栈信息
①top -p
按H，获取每个线程的内存情况
找到最高的线程19663，然后转为十六进制4cd0

②jstack 19663|grep -A 10 4cd0

4、jinfo -flags 14124 查看正在运行的java应用程序的扩展参数

5、jstat 查看堆内存各部分的使用量，以及加载类的数量

jstat [-命令选项] [vmid] [间隔时间(ms)] [查询次数]
jstat -gc pid 1000 10 查看gc情况
jstat -gccapacity 13988 堆内存统计
jstat -gcnew 13988 新生代垃圾回收统计
jstat -gcnewcapacity 13988 新生代内存统计
jstat -gcold 13988 老年代垃圾回收统计
jstat -gcoldcapacity 13988 老年代内存统计
jstat -gcmetacapacity 13988 元数据空间统计

一、full gc比minor gc还多的原因有哪些？

1、元空间不够导致的多余full gc
2、显示调用System.gc()造成多余的full gc，这种一般线上尽量通过­XX:+DisableExplicitGC参数禁用，如果加上了这个JVM启动参数，那
么代码中调用System.gc()没有任何效果
3、老年代空间分配担保机制

二、 young gc和full gc依然很频繁了，而且看到有大量的对象频繁的被挪动到老年代，这种情况我们可以借助jmap命令大概看下是什么对象

jmap -histo 18424

查到了有大量User对象产生，这个可能是问题所在，但不确定，还必须找到对应的代码确认，如何去找对应的代码了？
1、代码里全文搜索生成User对象的地方(适合只有少数几处地方的情况)
2、如果生成User对象的地方太多，无法定位具体代码，我们可以同时分析下占用cpu较高的线程，一般有大量对象不断产生，对应的方法
代码肯定会被频繁调用，占用的cpu必然较高
可以用上面讲过的jstack或jvisualvm来定位cpu使用较高的代码

三、内存泄露到底是怎么回事

一般电商架构可能会使用多级缓存架构，就是redis加上JVM级缓存，大多数同学可能为了图方便对于JVM级缓存就
简单使用一个hashmap，于是不断往里面放缓存数据，但是很少考虑这个map的容量问题，结果这个缓存map越来越大，一直占用着老
年代的很多空间，时间长了就会导致full gc非常频繁，这就是一种内存泄漏，对于一些老旧数据没有及时清理导致一直占用着宝贵的内存
资源，时间长了除了导致full gc，还有可能导致OOM。
这种情况完全可以考虑采用一些成熟的JVM级缓存框架来解决，比如ehcache等自带一些LRU数据淘汰算法的框架来作为JVM级的缓存。