JVISUALVM Introduction and memory leak combat analysis

What can JVISUALVM do       VisualVM is NetBeans's profile subproject, which has been brought in JDK6.0 update 7 (Java startup does not require specific parameters, and the monitoring tool is bin/ Jvisualvm.exe), capable of monitoring threads, memory conditions, viewing methods of CPU time and in-memory objects, objects that have been GC, reverse-viewing allocated stacks (such as 100 string objects by which several objects are allocated).       under Jdk_home/bin (the default is the C:\Program files\java\jdk1.6.0_13\bin) directory, There is a Jvisualvm.exe file, double-click Open, from the UI view, this software is based on NetBeans developed.       can be monitored remotely and locally. Remote monitoring requires a jmx to be opened, which is mentioned below.       Its default page is: The left is divided into local and remote. Double-click on the local VISUALVM thread, you can see the following monitoring content: specific introduction See: http://www.ibm.com/developerworks/cn/java/j-lo-visualvm/Second, ready to simulate a memory leak demo       1, define static variables hashmap      2, segment loop create objects, and add hashmap      code as follows: Import Java.util . Hashmap;import Java.util.map;public class Cyclicdependencies {   //declaring cached objects     private static final Ma P map = new HashMap ();    public static void Main (String args[]) {        try {            Thread.Sleep (10000);//To open VISUALVM time        } CATCH (interruptedexception e) {            e.printstacktrace ();       }&NB Sp      //Loop Add object to cache         for (int i=0; i<1000000;i++) {        &NB Sp   Testmemory t = new testmemory ();            map.put ("key" +i,t);      & nbsp }        SYSTEM.OUT.PRINTLN ("first");       //provide time for dump out heap       &N Bsp Try {            Thread.Sleep (10000);       } catch (Interruptedexcepti On e) {            e.printstacktrace ();       }      &NB Sp for (int i=0; i<1000000;i++) {            testmemory t = new testmemory ();    &NB Sp       Map.put ("key" +i,t);       }        SYSTEM.OUT.PRINTLN ("secOnd ");        Try {            Thread.Sleep (10000);        catch (interruptedexception e) {            e.printstacktrace ();    &NBSP ;  }        for (int i=0; i<3000000;i++) {            Testmemory t = new Testmemory ();            map.put ("key" +i,t);       }        SYSTEM.OUT.PRINTLN ("third");        Try {            thre Ad.sleep (10000);       } catch (Interruptedexception e) {            E. Printstacktrace ();       }        for (int i=0; i<4000000;i++) {    &N Bsp       Testmemory t = new testmemory ();            map.put ("key" +i,t);  & nbsp   &NBSP }        SYSTEM.OUT.PRINTLN ("forth");        Try {        &NBS P   Thread.Sleep (integer.max_value);       } catch (Interruptedexception e) {            E.printstacktrace ();       }        SYSTEM.OUT.PRINTLN ("QQQ Q ");   }}     3, configure JVM parameters as follows:          -Xms512m-Xmx512m          -XX:-UseGCOverheadLimit           -XX:MaxPermSize=50m    &NBSP;4, run the program and clock out VISUALVM monitor three, use JVISUALVM to analyze memory leaks       1, view visual GC tag, the content is as follows, this is the output first of the              This is the output of Forth: through 2 graphs comparison found: Laosheng generation has been in the GC, When the program continues to run, you can see that the Laosheng GC is still continuing: it has increased to 7 times, but the memory of the Laosheng generation has not decreased. Indicates that there is an object that cannot be reclaimed, possibly a memory leak. How to analyze is that object leaking? Open the tag for the sampling device:Click on the following example: According to the program output heap dump, when the output second, dump once, when the output forth dump once. Go to the last dump stack tag and click on the class: Click on the upper right corner: "Compare to another heap storage". Select the dump content comparison for the first export: the comparison results are as follows: You can see that the Testmemory object instance has been increasing and many times in two intervals, indicating that the method referenced by the object may have a memory leak. How do I see the object reference relationship? Right-Select the class Testmemory, select Show in Instance view, as shown below: The total number of instances created on the left, the structure of the instance on the right, and the reference description below, which can be seen in the class Cyclicdependencies and referenced by HashMap. This can determine the location of the leak, and then according to the actual situation to analyze and solve. Iv. JVISUALVM remotely Monitor Tomcat 1, modify remote Tomcat's catalina.sh profile, adding: java_opts= "$JAVA _opts-djava.rmi.server.ho Stname=192.168.122.128-dcom.sun.management.jmxremote.port=18999-dcom.sun.management.jmxremote.ssl= False-dcom.sun.management.jmxremote.authenticate=false "This configuration does not go through the permission check.    Just open the JMX port.   2, open JVISUALVM, right-click Remote, select Add remote host: 3, enter the name of the host, direct write IP, as follows: Right-click the new host, select Add JMX connection, enter the port configured in Tomcat. 4. Double-click to open. Complete! V. Extended knowledge thread deadlock detection JVM Tuning Recommendations    is essentially the number of GC reductions. If you are an application that creates objects frequently, you can increase the Cenozoic size appropriately. More constants can increase the persistent generation size. For more than one object, you can increase the Laosheng generation size. such as the spring application. GC selection, after JDK5.0, the JVM will be judged based on the current system configuration. The general execution of the-server command is possible. The GC consists of three strategies: serial, parallel, and concurrent. Throughput is widely used, generally using parallel collection, open multiple threads, speed up the GC.     Applications with high response times, typically using concurrent collections, such as application servers.  The older generation is recommended to be configured as a concurrent collector because the concurrent collector does not compress and defragment the disk, so it is recommended to configure:-XX:+USECONCMARKSWEEPGC #并发收集年老代-xx:cmsinitiatingoccupancyfraction=80 # Represents the age-old generation of space to 80% when it begins to execute cms-xx:+usecmscompactatfullcollection # Open the compression of older generations.      Performance may be affected, but memory fragmentation can be eliminated. -XX:CMSFULLGCSBEFORECOMPACTION=10 # Because the concurrent collector does not compress and defragment the memory space, running a period of time will result in "fragmentation", resulting in reduced operational efficiency. This parameter sets the memory space to be compressed and organized after running the secondary FULLGC. run the JVISUALVM on Linux directly      Download the X-manager and you can try to show it on your local machine. not supported by this JVM      Ensure that the JVISUALVM belongs to the JDK version and Linux consistent.

JVISUALVM Introduction and memory leak combat analysis