ManagementFactory （二） getMemoryMXBean

MemoryMXBean

package cn.zno.outofmomery;

import java.lang.management.ManagementFactory;
import java.lang.management.MemoryMXBean;
import java.util.ArrayList;
import java.util.List;

public class Test {
    MemoryMXBean memoryMXBean;
    {
        memoryMXBean = ManagementFactory.getMemoryMXBean();
        System.out.println(memoryMXBean.isVerbose());
    }

    void h(){
        List<byte[]> list = new ArrayList<byte[]>();
        while(true){
//          System.out.println(memoryMXBean.getNonHeapMemoryUsage());
            System.out.println(memoryMXBean.getHeapMemoryUsage());
            list.add(new byte[1024*1024]);
        }
    }

    public static void main(String[] args) {
        new Test().h();
    }
}

• 垃圾回收是否启用
• 获取堆内存使用情况
• 获取非堆内存使用情况

VM args

-verbose:gc  -XX:+PrintGCDetails

或

-verbose:gc

或

-Xloggc:D://data.log 

或

-Xloggc:D://data.log -XX:+PrintGCDetails

运行结果：

true
init = (32768K) used = (594K) committed = (31680K) max = (31680K)
init = (32768K) used = (1618K) committed = (31680K) max = (31680K)
init = (32768K) used = (2642K) committed = (31680K) max = (31680K)
init = (32768K) used = (3666K) committed = (31680K) max = (31680K)
init = (32768K) used = (4690K) committed = (31680K) max = (31680K)
init = (32768K) used = (5714K) committed = (31680K) max = (31680K)
init = (32768K) used = (6738K) committed = (31680K) max = (31680K)
init = (32768K) used = (7762K) committed = (31680K) max = (31680K)
[GC 7762K->7548K(31680K), 0.0032242 secs]
init = (32768K) used = (8572K) committed = (31680K) max = (31680K)
init = (32768K) used = (9689K) committed = (31680K) max = (31680K)
init = (32768K) used = (10887K) committed = (31680K) max = (31680K)
init = (32768K) used = (11911K) committed = (31680K) max = (31680K)
init = (32768K) used = (12935K) committed = (31680K) max = (31680K)
init = (32768K) used = (13959K) committed = (31680K) max = (31680K)
init = (32768K) used = (14983K) committed = (31680K) max = (31680K)
init = (32768K) used = (16007K) committed = (31680K) max = (31680K)
[GC 16007K->15739K(31680K), 0.0032697 secs]
init = (32768K) used = (16824K) committed = (31680K) max = (31680K)
init = (32768K) used = (17849K) committed = (31680K) max = (31680K)
init = (32768K) used = (18873K) committed = (31680K) max = (31680K)
init = (32768K) used = (19897K) committed = (31680K) max = (31680K)
init = (32768K) used = (20921K) committed = (31680K) max = (31680K)
init = (32768K) used = (21945K) committed = (31680K) max = (31680K)
init = (32768K) used = (22969K) committed = (31680K) max = (31680K)
init = (32768K) used = (23993K) committed = (31680K) max = (31680K)
[Full GC 23993K->23932K(31680K), 0.0051448 secs]
init = (32768K) used = (24956K) committed = (31680K) max = (31680K)
init = (32768K) used = (26020K) committed = (31680K) max = (31680K)
init = (32768K) used = (27044K) committed = (31680K) max = (31680K)
init = (32768K) used = (28068K) committed = (31680K) max = (31680K)
init = (32768K) used = (29092K) committed = (31680K) max = (31680K)
init = (32768K) used = (30116K) committed = (31680K) max = (31680K)
init = (32768K) used = (31140K) committed = (31680K) max = (31680K)
[Full GC 31140K->31100K(31680K), 0.0034119 secs]
[Full GC 31100K->31090K(31680K), 0.0033546 secs]
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    at cn.zno.outofmomery.Test.h(Test.java:)
    at cn.zno.outofmomery.Test.main(Test.java:)

垃圾回收格式解读

init = 33554432(32768K) used = 24568936(23993K) committed = 32440320(31680K) max = 32440320(31680K)
[Full GC 23993K->23932K(31680K), 0.0051448 secs]

-----------------------------------------------------------
[Full GC gc前used->gc后used(committed), 耗费时间]

参考 ： https://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html

Measurement

Throughput and footprint are best measured using metrics particular to the application. For example, throughput of a web server may be tested using a client load generator, while footprint of the server might be measured on the Solaris Operating System using the pmap command. On the other hand, pauses due to garbage collection are easily estimated by inspecting the diagnostic output of the virtual machine itself.

The command line option -verbose:gc causes information about the heap and garbage collection to be printed at each collection. For example, here is output from a large server application:

               
[GC 325407K->83000K(776768K), 0.2300771 secs]
[GC 325816K->83372K(776768K), 0.2454258 secs]
[Full GC 267628K->83769K(776768K), 1.8479984 secs]

            

Here we see two minor collections followed by one major collection. The numbers before and after the arrow (e.g., 325407K->83000K from the first line) indicate the combined size of live objects before and after garbage collection, respectively. After minor collections the size includes some objects that are garbage (no longer alive) but that cannot be reclaimed. These objects are either contained in the tenured generation, or referenced from the tenured or permanent generations.

The next number in parentheses (e.g., (776768K) again from the first line) is the committed size of the heap: the amount of space usable for java objects without requesting more memory from the operating system. Note that this number does not include one of the survivor spaces, since only one can be used at any given time, and also does not include the permanent generation, which holds metadata used by the virtual machine.

The last item on the line (e.g., 0.2300771 secs) indicates the time taken to perform the collection; in this case approximately a quarter of a second.

The format for the major collection in the third line is similar.

The format of the output produced by -verbose:gc is subject to change in future releases.

The option -XX:+PrintGCDetails causes additional information about the collections to be printed. An example of the output with -XX:+PrintGCDetails using the serial garbage collector is shown here.

               
[GC [DefNew: 64575K->959K(64576K), 0.0457646 secs] 196016K->133633K(261184K), 0.0459067 secs]

            

indicates that the minor collection recovered about 98% of the young generation, DefNew: 64575K->959K(64576K) and took 0.0457646 secs (about 45 milliseconds).

The usage of the entire heap was reduced to about 51% 196016K->133633K(261184K) and that there was some slight additional overhead for the collection (over and above the collection of the young generation) as indicated by the final time of 0.0459067 secs.

The option -XX:+PrintGCTimeStamps will add a time stamp at the start of each collection. This is useful to see how frequently garbage collections occur.

111.042: [GC 111.042: [DefNew: 8128K->8128K(8128K), 0.0000505 secs]111.042: [Tenured: 18154K->2311K(24576K), 0.1290354 secs] 26282K->2311K(32704K), 0.1293306 secs]

The collection starts about 111 seconds into the execution of the application. The minor collection starts at about the same time. Additionally the information is shown for a major collection delineated by Tenured. The tenured generation usage was reduced to about 10% 18154K->2311K(24576K) and took 0.1290354 secs (approximately 130 milliseconds).

As was the case with -verbose:gc, the format of the output produced by -XX:+PrintGCDetailsis subject to change in future releases.