Analyzing Java programs with Jmap

The previous essay mentions using Jstack to analyze Java threading, and also in this project, when the thread problem is resolved and the memory of the program is growing, the Jmap tool is used to analyze the memory usage of the Java program.

The command is simple, direct

Jmap-histo 22955 > Jmap.info

Where 22955 is the Java PID, redirected to the Jmap.info file, the contents are:

Num #instances #bytesclassname----------------------------------------------1:585,569 359014728[C2:95905 14389200 <constMethodKlass> 3:579,358 13904592java.lang.String4:95905 12287600 <methodKlass> 5:8542 10324824 <constantPoolKlass> 6: 21015 7564272[B7:8542 6355376 <instanceKlassKlass> 8:7126 5664512 <constantpoolcacheklass&   Gt 9:53,877 5603208Com.wisdombud.unicom.monitor.po.MessageBean10:117,112 2810688java.util.Date11:46,743 2534632[Ljava.lang.Object; 12:3669 2142176 <methodDataKlass> 13:25,046 1850544[Ljava.util.hashtable$entry; 14:51,662 1653184Java.util.hashtable$entry15:50,881 1628192Java.util.concurrent.concurrenthashmap$hashentry16:43,410 1389120Java.util.hashmap$entry17:55,516 1332384java.util.ArrayList18:24,915 1195920java.util.Hashtable19:8,988 1162184Java.lang.Class20:14,523 1161840Java.lang.reflect.Method21:21,461 1030128Com.sun.org.apache.xerces.internal.dom.AttrNSImpl22:12,866 956456[S23:14,959 750072[[I24:5,752 694480[I25:9,667 618688Com.sun.org.apache.xerces.internal.dom.ElementNSImpl26:23,097 554328Com.sun.org.apache.xerces.internal.dom.parentnode$userdatarecord27:13,430 537200Com.sun.org.apache.xerces.internal.dom.TextImpl28:5,279 526192[Ljava.util.concurrent.concurrenthashmap$hashentry; 29:15,795 505440Com.sun.org.apache.xerces.internal.xni.QName30:3,120 476496[Ljava.util.hashmap$entry; 31:13,949 446368Com.wisdombud.unicom.collect.linux.bean.ConfLinuxFileSys32:23,464 375424Java.lang.Object33:3,774 366032[Ljava.lang.String; 34:429 233376 <objArrayKlassKlass> 35:9,685 232440Com.sun.org.apache.xerces.internal.dom.AttributeMap36:6,981 223392Com.wisdombud.unicom.collect.linux.bean.PerfLinuxFileSys37:4,652 223296Java.util.HashMap38:5,279 211160java.util.concurrent.concurrenthashmap$segment39:5,512 176384Java.util.concurrent.locks.reentrantlock$nonfairsync40:243 173016[Lcom.sun.org.apache.xerces.internal.util.symboltable$entry; 41:3,159 126360java.lang.ref.SoftReference42:2,516 120768Com.wisdombud.unicom.collect.linux.bean.ConfLinux43:2,761 110440Java.util.linkedhashmap$entry44:1143 100584org.snmp4j.snmp$pendingrequest45:1364 98208org.snmp4j.mp.StateReference46:2,352 94080Com.wisdombud.unicom.collect.linux.bean.PerfLinux Total2225122 467913224

I've removed a lot of the smaller classes that occupy.

The most important is the last two columns, the third column is the number of bytes occupied, the fourth column is the class, the class is explained as follows:

• [Cis achar[]
• [Sis ashort[]
• [Iis aint[]
• [Bis abyte[]
• [[Iis aint[][]

Reference: Http://stackoverflow.com/questions/7913759/what-are-these-objects-in-the-jmap-histogram

As you can see, char is much more, but can also locate in its own code Messagebean occupy more, quickly locate to manipulate this kind of method, in through the analysis code, found the cause of the problem.

Jmap can be used often, such as running every 10 minutes, and by contrast, to see which classes occupy more memory growth.

In addition, the JMAP also has the dump parameter, the method is as follows:

Jmap-dump:format=b,file=mem.dat 22955

In this project, the dump file is very large, because the reason for the network is not transmitted, so there is no analysis.

For the usage of dump, refer to: http://www.cnblogs.com/ggjucheng/archive/2013/04/16/3024986.html

Analyzing Java programs with Jmap