JMAP

As the title states, how much overhead does jmap -histo and jmap -heap bring to a jvm respectively? If a memory sensitive Java process is at the edge of OutOfMemory (e.g around 96% of heap is full, and can't be cleared by full gc), is it possible for one of the operations to bring the jvm to OutOfMemory? apangin jmap -histo and jmap -heap work differently: jmap -histo uses Dynamic Attach Mechanism, and jmap -heap works through HotSpot Serviceability Agent. The difference is described here . Therefore, jmap -histo is executed by JVM itself, but jmap -heap runs in a tool process while JVM

1.JVM-堆快照（Snapshot） 1.1 输出方式-获取hprof文件 启动参数配置OOM时触发打印堆快照 （1）tomcat启动方式添加参数 (添加环境变量) export JAVA_OPTS= -XX:+HeapDumpOnOutOfMemoryError (表明进行统计相关heapDump文件再OOM的时候) -XX:HeapDumpPath=/export/Domains/rcsv-fm.wd.local/server1/logs/ gc.hprof （表明会导出生产的HeapDump文件的路径） (2) jvm 命令参数 (添加环境变量) Java -jar -XX:+HeapDumpOnOutOfMemoryError (表明进行统计相关heapDump文件再OOM的时候) -XX:HeapDumpPath=/export/Domains/rcsv-fm.wd.local/server1/logs/ gc.hprof （表明会导出生产的HeapDump文件的路径） （1）-XX:+HeapDumpOnOutOfMemoryError参数表示当JVM发生OOM时，自动生成DUMP文件。 （2）-XX:HeapDumpPath=${目录}参数表示生成DUMP文件的路径，也可以指定文件名称，例如：-XX:HeapDumpPath=${目录}/java_heapdump

分析系统堆栈 1.查看应用线程 jps -l 2.导出dump信息 jmap -dump:live,file=app.dump 6864 来源： https://my.oschina.net/u/3126880/blog/3132226

jhat也是jdk内置的工具之一。主要是用来分析java堆的命令，可以将堆中的对象以html的形式显示出来，包括对象的数量，大小等等，并支持 对象查询语言 。 使用jmap等方法生成java的堆文件后，使用其进行分析。 第一步：导出堆 #jmap -dump:live,file=a.log pid 除了使用jmap命令，还可以通过以下方式： 1、使用 jconsole 选项通过 HotSpotDiagnosticMXBean 从运行时获得堆转储（生成dump文件）、 2、虚拟机启动时如果指定了 -XX:+HeapDumpOnOutOfMemoryError 选项, 则在抛出 OutOfMemoryError 时, 会自动执行堆转储。 3、使用 hprof 命令 第二步：分析堆文件 #jhat -J-Xmx512M a1.log 说明：有时dump出来的堆很大，在启动时会报堆空间不足的错误，可加参数：jhat -J-Xmx512m <heap dump file>。这个内存大小可根据自己电脑进行设置。 解析Java堆转储文件,并启动一个 web server 第三步：查看html http://ip:7000/ 对于jhat启动后显示的html页面中功能： （1）显示出堆中所包含的所有的类 （2）从根集能引用到的对象 （3）显示平台包括的所有类的实例数量 （4）堆实例的分布表 （5

通过top命令查看CPU情况，如果CPU比较高，则通过top -Hp <pid>命令查看当前进程的各个线程运行情况，找出CPU过高的线程之后，将其线程id转换为十六进制的表现形式，然后在jstack日志中查看该线程主要在进行的工作。这里有两种情况： 如果该现场为用户线程，则通过该线程的堆栈信息查看其具体是在哪处用户代码比较消耗cpu 如果该线程为vm thread,则通过jstat -gcutil <pid> <period> <times>命令监控当前系统的GC状况，然后通过jmap dump:format=b,file=<filepath> <pid>导出系统当前的内存数据。导出之后将内存情况放到eclipse的mat工具中分析即可得出内存中什么对象比较消耗内存，进而可以处理相关代码。 top命令看到CPU并不高，并且系统内存占用率也比较低。此时可以考虑是否由于另外三种情况导致。 如果是接口调用比较耗时，并且不定时出现，则可以通过压测方式加大阻塞点出现的频率，从而通过jstack查看堆栈信息，找到阻塞点 如果某功能突然出现停滞，情况无法复现，可以通过多次导出jstack日志的方式比对哪些用户线程一直处于等待状态，这些线程就是可能存在问题的线程 如果通过jstack可以查看到死锁，则可以检查死锁的两个线程的具体阻塞点，从而处理相应问题 来源： oschina 链接： https:

java 获取内存dump 的几种方式 1、获取内存详情：jmap -dump:format=b,file=e.bin pid 这种方式可以用 jvisualvm.exe 进行内存分析，或者采用 Eclipse Memory Analysis Tools (MAT)这个工具 2. 获取内存dump： jmap -histo:live pid 这种方式会先出发fullgc，所有如果不希望触发fullgc 可以使用jmap -histo pid 3.第三种方式：jdk启动加参数： -XX:+HeapDumpBeforeFullGC -XX:HeapDumpPath=/httx/logs/dump 这种方式会产生dump日志，再通过jvisualvm.exe 或者Eclipse Memory Analysis Tools 工具进行分析 jstack 系统运行缓慢，CPU 100%，以及Full GC次数过多问题的排查思路 Trace跟踪参数 -verbose:gc -XX:+printGC 可以打印GC的简要信息 [GC 4790K->374K(15872K), 0.0001606 secs] [GC 4790K->374K(15872K), 0.0001474 secs] [GC 4790K->374K(15872K), 0.0001563 secs] [GC 4790K->374K

cup占用率高 ： 第一步：找到占用CPU过高的进程的pid 使用top命令，然后按shift+p按照CPU排序 第二步：找到进程中消耗资源最高的线程的id 使用top -Hp [进程id] 第三步：将线程id转换为16进制（字母要小写） 使用echo 'obase=16;[线程id]' | bc或者printf "%x\n" [线程id] 【bc是linux的计算器命令】 第四步：查看线程状态信息 执行jstack [进程id] |grep -A 10 [线程id的16进制]” 第五步：导出堆栈异常信息 执行jstack [进程id] |grep -A 10 [线程id的16进制] > xxx.txt 下载至本地sz xxx.txt 内存占用较高 ：找到内存占用高的线程后，使用 jmap -dump:format=b,file=dumpfile.dat [pid]将内存信息down下来，pid为线程id，使用java自带工具 java visual vm：打开jdk/bin/jvisualvm，装入dump文件即可； 来源： oschina 链接： https://my.oschina.net/u/3734816/blog/3136891

cup占用率高 ： 第一步：找到占用CPU过高的进程的pid 使用top命令，然后按shift+p按照CPU排序 第二步：找到进程中消耗资源最高的线程的id 使用top -Hp [进程id] 第三步：将线程id转换为16进制（字母要小写） 使用echo 'obase=16;[线程id]' | bc或者printf "%x\n" [线程id] 【bc是linux的计算器命令】 第四步：查看线程状态信息 执行jstack [进程id] |grep -A 10 [线程id的16进制]” 第五步：导出堆栈异常信息 执行jstack [进程id] |grep -A 10 [线程id的16进制] > xxx.txt 下载至本地sz xxx.txt 内存占用较高 ：找到内存占用高的线程后，使用 jmap -dump:format=b,file=dumpfile.dat [pid]将内存信息down下来，pid为线程id，使用java自带工具 java visual vm：打开jdk/bin/jvisualvm，装入dump文件即可； 来源： oschina 链接： https://my.oschina.net/u/3734816/blog/3136891

Quick question Does the jmap heap dump include only the old generation, or also the young generation ? Long explanation I have 2 heap dump ( jmap -heap:format=b 9999 ) : one of my server with no load (no HTTP request) one while working 50% CPU, a high load (benchmarking) Now, the first dump shows a heap size bigger than the second (which I thought was weird). Could that be because the Young generation (at high load) is changing often because the Garbage collector is running often (yes, the JVM is almost full) ? Old generation is full at 99%, I've noticed the young generation space usage vary a