Java Virtual machine garbage collection mechanism and Java wrong three Musketeers

One, Java Virtual machine logical recovery mechanism

1. Java Garbage collector

The Java garbage collector is one of the three important modules of the Java Virtual Machine (JVM) (the other two are the interpreter and multithreading mechanism), providing the application with automatic memory allocation (Allocation), auto-recycling (garbage Collect) function, Both of these operations occur on the Java heap (a memory is fast).

At some point, an object with more than one reference (rreference) points to it, then the object is Alive (live), otherwise death (Dead), as garbage, can be reclaimed and reused by the garbage collector.

The recycle operation consumes CPU, thread, time and other resources, so it is easy to understand that the garbage collection operation is not happening in real time (object death is released immediately), when the memory consumes or reaches an indicator (Threshold, using memory as the total memory of the column, such as 0.75), the garbage collection operation is triggered. There is an exception to the death of an object, an object of type Java.lang.Thread, even if there is no reference, is not recycled as long as the thread is still running.

According to statistical analysis, Java (including some other high-level languages) Most of the object life cycle is short, so the Java memory management. The goal of generational is to use different management strategies (algorithms) for different generations of memory blocks to maximize performance. Compared to the elderly, usually younger generations are much smaller, the frequency of recovery is high, fast. Older generations are less frequent and take longer to recover. The memory is allocated within the young generation, and the objects inside the young generation will be automatically promoted to the old generation after multiple recycling cycles remain alive.

2. Garbage collection type

All of the collector types are based on generational technology. The Java hotspot virtual machine contains three generations, the younger generation (young Generation), the older generation (old Generation), and the Permanent generation (Permanent Generation).

(1) Permanent generation

Store classes, methods, and their descriptive information. The initial size and maximum values can be specified by the-xx:permsize=64m and-xx:maxpermsize=128m two selectable options. Usually we do not need to adjust this parameter, the default permanent generation size is enough, but if the load of the class very much, not enough, adjust the maximum value.

(2) Old generation

The main storage of the young generation after multiple recycling cycle still survive to upgrade the object, of course, for some large memory allocation, may also be directly allocated to permanent generation (an extreme example is that the young generation simply cannot save).

(3) Young generation

The vast majority of memory-allocation-recycling actions occur in younger generations. As shown, the young generation is divided into three regions, the original area (Eden) and two small survival zones (Survivor), and two survival zones are divided by function from and to. The vast majority of objects are allocated in the original area, and more than one garbage collection operation remains alive in the survival area.

Description: The young generation of objects that survived through multiple recycling cycles will automatically be promoted to older generations. Older generations will still survive for multiple recycling cycles.

3. Java Virtual machine garbage collection mechanism

(1) Minor GC

Recovering memory from the young generation space (including Eden and Survivor zones) is called the Minor GC. This definition is both clear and easy to understand. However, when a Minor GC event occurs, the Minor GC is triggered when the JVM cannot allocate space for a new object, such as when the Eden area is full. So the higher the allocation rate, the more frequently the Minor GC is executed.

All Minor GC triggers "world-wide Pause (Stop-the-world)", which is the thread that stops the application.

(2) Major GC vs full GC

GC, which occurs in the old age, Major GC, often accompanied at least once Minor GC. The speed of the MAJORGC is generally 10 times times slower than the Minor GC.

When full GC occurs, "world-wide Pause (Stop-the-world)" is also triggered to stop the application's thread. And lasts for a long time.

Second, Java wrong three Musketeers

1. Jstack View information about the thread stacks of the specified Java process

Jstack [-l] <pid>

Jstack-f [-M] [-l] <pid>

-l:long listings, additional lock information is displayed, so a deadlock occurs often with this option

-M: Mixed mode, which outputs both Java stack information and C + + stack information

-F: When using "Jstack-l PID" is unresponsive, you can use-f to force output information

Example:

(1) View PID

PS Aux|grep Tomcat

Root 2745 0.6 19.0 2333928 190144 pts/0 Sl 08:58 3:57/usr/java/jdk1.8.0_144/jre/bin/java-djava.util.logging. Config.file=/usr/local/tomcat/conf/logging.properties-djava.util.logging.manager= org.apache.juli.classloaderlogmanager-djdk.tls.ephemeraldhkeysize=2048-djava.endorsed.dirs=/usr/local/tomcat/ endorsed-classpath/usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomcat/bin/tomcat-juli.jar-dcatalina.base=/ Usr/local/tomcat-dcatalina.home=/usr/local/tomcat-djava.io.tmpdir=/usr/local/tomcat/temp Org.apache.catalina.startup.Bootstrap start

Root 9424 0.0 0.0 112648 960 pts/0 s+ 19:47 0:00 grep--color=auto Tomcat

You can see that the PID is 2745

(2) Jstack-l 2745

2. Jstat output statistics for the specified Java process

Jstat-help|-options

Jstat-<option> [-t] [-h<lines>] <vmid> [<interval> [<count>]

# jstat-options

-class:class loader load statistics

-compiler:JIT Compilation statistics

-GC:GC

-gcnew: cenozoic

-gcold: The old age

-printcompilation JVM Compilation Method Statistics

[<interval> [<count>]]

Interval: time interval, unit is milliseconds;

count: The number of times displayed;

Example:

(1) Jstat-class 2745 1000 1000 display 1000 times in seconds, class load statistics

(2) JSTAT-GC 2745 1000 1000 You can see how often large GC and small GC occur.

              

s0c,s1c,s0u,s1u:Survivor 0/1 area Capacity (capacity) and usage (used)

EC,EU:Eden area capacity and usage

OC,OU: Capacity and usage for older generations

PC,PU: permanent generation capacity and consumption

YGC,ygt: Young generation GC times and GC time-consuming

FGC,fgct:fullGC times and full GC time-consuming

GCT:GC Total time-consuming

3. Jmap memory Map for viewing the usage status of heap Ram

very consumption of resources, usually first take the machine off, and then execute the command

jmap [option] <pid> View more information about heap space:

Jmap-heap <pid> View the number of objects in heap memory:

Jmap-histo <pid>

Live: Only the Activity object is counted;

Save the heap memory data to a file, and then use JVISUALVM or jhat to view it :

Jmap-dump:<dump-options> <pid>

Dump-options:

Live dump only live objects; If not specified, all objects in the heap is dumped.

Format=b binary format

File=<file> dump Heap to <file>

Example: Jmap-dump:format=b,file=/app/dump 2745

Cd/app

Because a binary file cannot be viewed directly, it needs to be converted

Jhat Dump

Ss-ntl listens on port 7000 and can be viewed in a browser

Java Virtual machine garbage collection mechanism and Java wrong three Musketeers