JMAP

JDK里有三个很好用的工具， jmap ， jconsole 和 jvisualvm ，三个工具都各有所侧重，但是如果你的系统遇到性能瓶颈（内存不足或是CPU占用率过高），你可以通过这三个工具来发现应用里的hot spot。我今天只记一下大概的用法，给自己做个备忘，详细的使用说明，等忙完了这段时间，整理一下。 先介绍一个小工具，jps，这也是jdk自带的工具之一，可以列出系统里所有的java进程。 jmap可以查看程序中堆的使用情况，具体的用法是： jmap –histo:live <pid>； 以及可以将堆dump到一个文件，命令是： jmap –dump:format=b,file=heap.bin <pid>； 请在<pid>处填入相应的进程的id。 jconsole可以查看某个java进程的内存使用、CPU占用率等， 如果想要远程查看某一java程序，则需要在该程序启动参数里加下如下参数： -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port= 9001 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false 上文使用的9001是监听的端口号，你可以指定其他的值

We know that jmap -histo:live triggers a full gc in order to determine live objects: Does jmap force garbage collection when the live option is used? Since jmap -histo considers all objects in the heap (those in the young and old generation), my point is, jmap -histo can also trigger a full gc, too. However, I could not encounter a solid documentation about whether jmap -histo may trigger a full gc or not. Can jmap -histo trigger full garbage collection? Someone with more JDK experience should verify this, but I'm fairly confident it does trigger full GC, at least in OpenJDK 1.7 . Start with

Using memory analyzer from eclipse ide (kepler), I'm trying to acquire heap dump from a locally running VM while an program is running, however acquire heap dump dialog does not list any pid to select. I try to configure hdrof jmap dump provider with -jdkhome C:\Program Files\Java\jdk1.8.0_05\bin but nothing happens. Any solution. Thanks. remove bin from your path , It should be -jdkhome C:\Program Files\Java\jdk1.8.0_05 来源： https://stackoverflow.com/questions/24433668/memory-analysis-from-eclipse-ide-does-not-list-any-local-process-id-when-acquire

给一个系统定位问题的时候，知识、经验是关键基础，数据是依据，工具是运用知识处理数据的手段。这里的数据包括：运行日志、异常堆栈、GC日志、线程快照（threaddump/javacore文件）、堆转储快照（heapdump/hprof文件）等。经常使用适当的虚拟机监控和分析的工具可以加快我们分析数据和定位解决问题的速度，但我们在学习工具前，也应当意识到工具永远都是知识技能的一层包装，没有什么工具是“秘密武器”，学会了就能包医百病。 JDK的命令行工具 Java开发人员肯定都知道JDK的bin目录下有“java.exe“和”javac.exe“这两个命令行工具，但并非所有程序员都了解过JDK的bin下其他命令行程序的作用。每逢JDK更新版本之时，bin目录下命令行工具的数量和功能总会不知不觉地增加和增强。 作者介绍了这些工具中的一部分，主要用于监视虚拟机和故障处理的工具。在软件的使用说明中这些故障处理工具被声明为”没有技术支持并且是实验性质的“（unsupported and experimental）的产品，但事实上这些工具都非常稳定并且功能强大，能在处理应用程序性能问题、定位故障时发挥很大的作用。 这些工具体积都异常的小，大多都在30KB左右。并非JDK开发团队刻意将他们制作得如此精炼来炫技，而是这些命令行工具大多数是jdk\lib\tools.jar类库的一层薄封装而已

JAVA运行时内存区域 程序计数器 一块很小的内存空间 当前线程所执行的字节码的行号指示器 当前线程私有 不会出现OutOfMemoryError情况 java虚拟机栈 通常存放基本数据类型，对象引用（一个指向对象起始地址的引用指针或一个代表对象的句柄），reeturnAddress类型（指向一条字节码指令的地址） 线程私有，生命周期与线程相同 java方法执行的内存模型，每个方法执行的同时都会创建一个栈帧，存储局部变量表(基本类型、对象引用)、操作数栈、动态链接、方法出口等信息 StackOverflowError异常：当线程请求的栈深度大于虚拟机所允许的深度 OutOfMemoryError异常：如果栈的扩展时无法申请到足够的内存 本地方法栈 与虚拟机栈相似，主要为虚拟机使用到的Native方法服务，在HotSpot虚拟机中直接把本地方法栈与虚拟机栈二合一 和虚拟机栈一样可能抛出StackOverflowError和OutOfMemoryError异常。 Java堆(Java Heap) java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此区域的唯一目的就是存储对象实例。java堆是垃圾收集器管理的主要区域。java堆还可以细分为：新生代与老年代。再细一点有Eden空间、Form Survivor空间、To Survivor空间等。 可以通过-Xmx和

1.MAT简介： MAT 全称 Eclipse Memory Analysis Tools 是一个分析 Java堆数据的专业工具，可以计算出内存中对象的实例数量、占用空间大小、引用关系等，看看是谁阻止了垃圾收集器的回收工作，从而定位内存泄漏的原因。 2.什么时候会用到MAT? a）OutOfMemoryError的时候，触发full gc，但空间却回收不了，引发内存泄露 b）java服务器系统异常，比如load飙高，io异常，或者线程死锁等，都可能通过分析堆中的内存对象来定位原因 3.MAT安装： https://www.eclipse.org/mat/downloads.php --下载地址 http://help.eclipse.org/oxygen/index.jsp?topic=/org.eclipse.mat.ui.help/welcome.html --官网使用教程 #参数配置： 分析堆转储文件需要消耗很多的堆空间，为了保证分析的效率和性能，在有条件的情况下，建议分配给 MAT 尽可能多的内存资源。两种方式分配内存资源给 MAT： 1）修改启动参数 MemoryAnalyzer.exe -vmargs -Xmx4g 2）编辑文件 MemoryAnalyzer.ini 添加 -vmargs – Xmx4g 4.MAT分析dump堆栈： #4.1dump文件生成： a

前提概要： JDK本身提供了很多方便的JVM性能调优监控工具，除了集成式的VisualVM和jConsole外，还有jps、jstack、jmap、jhat、jstat、hprof等小巧的工具，每一种工具都有其自身的特点，用户可以根据你需要检测的应用或者程序片段的状况，适当的选择相应的工具进行检测。接下来的两个专题分别会讲VisualVM的具体应用。 现实企业级Java开发中，有时候我们会碰到下面这些问题： OutOfMemoryError，内存不足 内存泄露 线程死锁 锁争用（Lock Contention） Java进程消耗CPU过高 ...... 这些问题在日常开发中可能被很多人忽视（比如有的人遇到上面的问题只是重启服务器或者调大内存，而不会深究问题根源），但能够理解并解决这些问题是Java程序员进阶的必备要求。 一、 jps(Java Virtual Machine Process Status Tool) ： 基础工具 实际中这是最常用的命令，下面要介绍的小工具更多的都是先要使用jps查看出当前有哪些Java进程，获取该Java进程的id后再对该进程进行处理。 jps主要用来输出JVM中运行的进程状态信息。语法格式如下： Java代码 jps [options] [hostid] 如果不指定hostid就默认为当前主机或服务器。 命令行参数选项说明如下： Java代码

We are working over our client's production server heap to detect and solve memory leaks. For this we are using jmap periodically to collect the necessary information. But last week we couldn't take the dump, because it triggered a EOF error and shutdown the Tomcat instance. I searched on the internet but couldn't find any concrete information about this error. We detected that it only occurs when using the Gc First garbage collector algorithm. This is the command line we used to perform the jmap: jmap -dump:format=b,file=heap.bin <PID> Java version on the server: JDK 1.7.0_7 x64 Has anyone

Java Virtual Machine Memory Map 生成虚拟机的内存转储快照（heapdump）文件 jmap 命令用于生产堆转储快照（一般称为heapdump或dump文件）。如果不使用jmap命令，要向获取Java堆转储快照还有一些比较”暴力“的手段：譬如-XX:+HeapDumpOnOutOfMemoryError参数，可以让虚拟机在OOM异常出现之后自动生生成dump文件，通过-XX:+HeapDumpOnCtrlBreak参数则可以使用[Ctrl]+[Break]键让虚拟机生成dump文件，又或者在Linux系统下通过Kill -3命令发送进程退出信号”恐吓“一下虚拟机，也能拿到dump文件。 jmap的作用并不仅仅是为了获取dump文件，它还可以查询finalize执行队列，Java堆和永久代的详细信息，如空间使用率、当前用的是那种收集器等。 jmap [ option ] vmid 选项 option 具体选项及作用如下： -dump 生成Java堆转储快照。格式为：-dump:[live,]format=b,file=，其中live子参数说明是否只dump出存活的对象 -finalizerinfo 显示在F-Queue中等待Finalizer线程执行finalize()方法的对象。只在Linux/Solaris平台下有效 -heap

分析内存泄露的一般步骤 把Java应用程序使用的heap dump下来 使用Java heap分析工具，找出内存占用超出预期（一般是因为数量太多）的嫌疑对象 必要时，需要分析嫌疑对象和其他对象的引用关系。 查看程序的源代码，找出嫌疑对象数量过多的原因。 dump heap analyze heap Memory Analyzer char[]的数量出其意料的多，占用90%以上的内存 发现有数万计的char[]，每个都占用数百K的内存 Java程序保存了数以万计的大String对象 顺藤摸瓜 在可疑的char[]中，任意挑了一个，使用Path To GC Root功能，找到该char[]的引用路径，发现String对象是被一个HashMap中引用的 虽然缓存中的String对象数量还没有达到阈值，但是String对象大小远远超出了我们的预期，最终导致内存被大量消耗，形成内存泄露的迹象（准确说应该是内存消耗过多） 不过并没有把String大对象放到HashMap中，而是把String大对象进行split（调用String.split方法），然后将split出来的String小对象放到HashMap中 查看代码 public int return this 可以看出，Stirng.split方法调用了Pattern.split方法。继续看Pattern.split方法的代码：