JMAP

01Heap Dump是什么？ ​ Heap Dump也叫堆转储文件，是一个Java进程在某个时间点上的内存快照。Heap Dump是有着多种类型的。不过总体上heap dump在触发快照的时候都保存了java对象和类的信息。通常在写heap dump文件前会触发一次FullGC，所以heap dump文件中保存的是FullGC后留下的对象信息。 02 Heap Dump里面有什么？ 一般在Heap Dump文件中可以获取到（这仍然取决于heap dump文件的类型）如下信息： 对象信息：类、成员变量、直接量以及引用值； 类信息：类加载器、名称、超类、静态成员； Garbage Collections Roots：JVM可达的对象； 线程栈以及本地变量：获取快照时的线程栈信息，以及局部变量的详细信息。 也就是说我们可以对上面这些内容进行分析。通常可以基于Heap Dump分析如下类型的问题： 找出内存泄漏的原因； 找出重复引用的jar或类； 分析集合的使用； 分析类加载器。 总而言之我们对Heap Dump的分析就是对应用的内存使用进行分析，从而更加合理地使用内存。 03怎样获取Heap Dump ? 获取heap dump有多种方式，可以通过参数配置在特定的条件下触发堆转储，也可以通过工具来获取。 通过OutOfMemoryError获取heap dump

1. jmap&jhat a. 查看虚拟机进程号 b. 生成内存快照文件 jmap -dump:format=b,file=a.bin 27088 c. 加载快照文件 jhat a.bin d. 访问localhost:7000 来源： CSDN 作者： pp_lan 链接： https://blog.csdn.net/pp_lan/article/details/104673373

java程序员除了编写业务代码之外，特别是项目上线之后，更需要关注的是系统的性能表现，这个时候就需要了解一下jvm的性能表现了，可以借助于java虚拟机自带的一些分析工具，主要有三个常用的命令。 1. jmap 这个命令是用来查看当前系统中jvm进程 heap dump的情况，包括对象的数量，对象所占内存的大小 使用方式：先使用jps查看进程id 使用 jmap -dump:live,file=b.map 22467 将live进程生成java堆转储快照 使用 jmap -heap PID 生成java堆的详细信息 使用 jmap -histo PID 生成java堆中对象的相关信息，包含数量以及占用的空间大小 2. jstat 主要是用来监控 heap size 和 jvm垃圾回收情况，尤其是gc情况的监控，如果老年代发生full gc，那么很可能会导致内存泄漏的可能性 可以看到新生代survivor S0, survivor S1 heap上的空间 使用百分比，堆中新生代Eden 的空间使用百分比，老年代Old 空间的使用百分比，内存的使用百分比，新生代Yong gc 的统计次数，新生代gc 花费的时间,full gc 的次数，花费的时间，当前进程总的gc时间，这里要注意一点，full gc很具有代表性，full gc次数 和时间 指标很能显示系统性能问题，这两个指标很大

一、Linux 命令 1、jstack （linux下特有） 可以观察到jvm中当前所有线程的运行情况和线程当前状态 jstack 2083 输出内容如下： 2、jmap （linux下特有，也是很常用的一个命令） 观察运行中的jvm物理内存的占用情况。 参数如下： -heap ：打印jvm heap的情况 -histo： 打印jvm heap的直方图。其输出信息包括类名，对象数量，对象占用大小。 -histo：live ： 同上，但是只答应存活对象的情况 -permstat： 打印permanent generation heap情况 jmap -dump:format=b,file=dumpfile.hprof <pid> 将日志信息输出到当前路径，文件名dumpfile.hprof pid 进程号 MAT 工具： https://www.cnblogs.com/larack/p/6071209.html 3、jstat 这是jdk命令中比较重要，也是相当实用的一个命令，可以观察到classloader，compiler，gc相关信息 具体参数如下： -class：统计class loader行为信息 -compile：统计编译行为信息 -gc：统计jdk gc时heap信息 -gccapacity：统计不同的generations（不知道怎么翻译好，包括新生区，老年区

一、AdaptiveSizePolicy简介 AdaptiveSizePolicy(自适应大小策略) 是 JVM GC Ergonomics(自适应调节策略) 的一部分。 如果开启 AdaptiveSizePolicy，则每次 GC 后会重新计算 Eden、From 和 To 区的大小，计算依据是 GC 过程中统计的 GC 时间、吞吐量、内存占用量 。 开启 AdaptiveSizePolicy 的参数为： -XX:+UseAdaptiveSizePolicy JDK 1.8 默认使用 UseParallelGC 垃圾回收器，该垃圾回收器默认启动了 AdaptiveSizePolicy。 AdaptiveSizePolicy 有三个目标： Pause goal：应用达到预期的 GC 暂停时间。 Throughput goal：应用达到预期的吞吐量，即应用正常运行时间 / (正常运行时间 + GC 耗时)。 Minimum footprint：尽可能小的内存占用量。 AdaptiveSizePolicy 为了达到三个预期目标，涉及以下操作： 如果 GC 停顿时间超过了预期值，会减小内存大小。理论上，减小内存，可以减少垃圾标记等操作的耗时，以此达到预期停顿时间。 如果应用吞吐量小于预期，会增加内存大小。理论上，增大内存，可以降低 GC 的频率，以此达到预期吞吐量。

JVM 调优概述 性能定义 吞吐量 - 指不考虑 GC 引起的停顿时间或内存消耗，垃圾收集器能支撑应用达到的最高性能指标。 延迟 - 其度量标准是缩短由于垃圾啊收集引起的停顿时间或者完全消除因垃圾收集所引起的停顿，避免应用运行时发生抖动。 内存占用 - 垃圾收集器流畅运行所需要的内存数量。 调优原则 GC 优化的两个目标： 将进入老年代的对象数量降到最低 减少 Full GC 的执行时间 GC 优化的基本原则是：将不同的 GC 参数应用到两个及以上的服务器上然后比较它们的性能，然后将那些被证明可以提高性能或减少 GC 执行时间的参数应用于最终的工作服务器上。 将进入老年代的对象数量降到最低 除了可以在 JDK7 及更高版本中使用的 G1 收集器以外，其他分代 GC 都是由 Oracle JVM 提供的。关于分代 GC，就是对象在 Eden 区被创建，随后被转移到 Survivor 区，在此之后剩余的对象会被转入老年代。也有一些对象由于占用内存过大，在 Eden 区被创建后会直接被传入老年代。老年代 GC 相对来说会比新生代 GC 更耗时，因此，减少进入老年代的对象数量可以显著降低 Full GC 的频率。你可能会以为减少进入老年代的对象数量意味着把它们留在新生代，事实正好相反，新生代内存的大小是可以调节的。 降低 Full GC 的时间 Full GC 的执行时间比 Minor

Java JVM 查看java进程： ps - ef | grep java jps - l （显示 java 进程的 Id 和软件名称） jps - lmv （显示 java 进程的 Id 和软件名称；显示启动 main 输入参数；虚拟机参数） jmap: jmap - heap pid 查看进程堆内存使用情况，包括使用的 GC 算法、堆配置参数和各代中堆内存使用情况 jmap - histo [: live ] pid 查看堆内存中的对象数目、大小统计直方图，如果带上 live 则只统计活对象( 这个命令执行，JVM会先触发gc，然后再统计信息 ) jmap - dump : format = b , file = dumpFileName 用 jmap 把进程内存使用情况 dump 到文件中，再用 jhat 分析查看 jmap命令详解： jmap命令详解 jstat: jstat -< option > [- t ] [- h <lines> ] <vmid> [< interval > [< count >]] exp : jstat - gcutil pid 5000 S0 — Heap 上的 Survivor space 0 区已使用空间的百分比 S1 — Heap 上的 Survivor space 1 区已使用空间的百分比 E — Heap 上的 Eden

# 一、JVM参数 ## 1.1 标准参数 -version -help -server -cp ## 1.2 -X参数 非标准参数，也就是在JDK各个版本中可能会变动 -Xint 解释执行 -Xcomp 第一次使用就编译成本地代码 -Xmixed 混合模式，JVM自己来决定 ## 1.3 -XX参数 使用得最多的参数类型，非标准化参数，相对不稳定，主要用于JVM调优和Debug a.Boolean类型 格式：-XX:\[+-\]<name> +或-表示启用或者禁用name属性 比如：-XX:+UseConcMarkSweepGC 表示启用CMS类型的垃圾回收器 -XX:+UseG1GC 表示启用G1类型的垃圾回收器 b.非Boolean类型 格式：-XX<name>=<value> 表示name属性的值是value 比如：-XX:MaxGCPauseMillis=500 ## 1.4 其它参数 -Xms1000等价于 -XX:InitialHeapSize=1000 -Xmx1000等价于 -XX:MaxHeapSize=1000 -Xss1000等价于 -XX:ThreadStackSize=1000 这一块内容也相当于-XX类型的参数 ## 1.5 查看参数 java -XX:+PrintFlagsFinal -version > flags.txt 上图值得注意的是“=

jps （JVM Process Status Tool）：显示指定系统内所有的HotSpot虚拟机进程 jstat （JVM Statistics Monitoring Tool）：用户收集HotSpot虚拟机各方面的运行数据 jinfo （Configuration Info for Java）：实时查看和调整虚拟机各项参数，在JDK9中集成到了 jhsdb jmap （Memory Map for java）：生成虚拟机的内存转储快照，在JDK9中集成到了 jhsdb jhat （JVM Heap Dump Browser）：用户分析heapdump文件，它会建立一个HTTP/HTML服务器，让用户可以在浏览器上查看分析结果，在JDK9中集成到了 jhsdb jstack （Stack Trace for Java）：生成虚拟机当前时刻的线程快照，在JDK9中集成到了 jhsdb jhsdb （Java HotSport Debugger）：进程调试器，在JDK9引入 jps 列出当前机器上正在运行的虚拟机进程，jps命令格式： jps [option] [hostid] -p: 仅仅显示VM 标示，不显示jar,class, main参数等信息. -m: 输出主函数传入的参数. 下的hello 就是在执行程序时从命令行输入的参数 -l:

最近解决了几次内存异常的问题，有两次是堆外内存异常，感觉解决的问题越多，问题的共性就越容易总结，在这里给大家分享一下，希望抛砖引玉能够帮大家解决遇到的问题。 其实有了MAT这类工具，一般堆内内存基本都能借助工具分析出大概问题所在，但堆外内存有时就不能直观地发现问题了，从解决过几次线上问题的现象总结，堆外内存过高80%都是这两种因素引起： 若metaspace正常，有可能是线程数过多造成的 若metaspace异常，有可能是classLoader过多造成的 当然了，并不是说只有这两种情况，有些也可能是直接内存泄露的问题，但如果你的项目不是大量操作直接内存，或者使用netty等第三方框架的话，可以考虑以上两个问题。 本次文章主要分享metaspace异常的解决过程。前段时间发现某个服务每隔几天就重启一次，由于使用k8s集群，进程内存达到某个阀值会被kill掉重启，通过jvm监控发现被kill之前的堆内内存十分正常，而metaspace却缓慢地上升： 然后通过jmap命令将内存dump出来后，利用mat工具打开，发现其classLoader数量特别多： PS：由于这里只列出重复类，所以数量没有对上 通过查看该classLoader的gc roots可以看出其引用路径： 说实话，一开始看到groovyClassLoader有点懵，想不到哪里用到groovy，猜测是第三方依赖