Deep understanding of Java Virtual machines: JVM advanced features and best practices learn note ⅱ

4th. Virtual machine performance monitoring and fault handling tools
//Learn the theory of virtual machine memory allocation and recovery technology, and how to apply it in practical work.
//Describes the 6 command-line tools and 2 visual troubleshooting tools released with the JDK.
1.JDK command-line tools
There are a number of tools in the bin directory of the JDK that can be used to monitor virtual machines and troubleshoot processing.
Many of the gadgets are named like UNIX commands, such as JPS, which are similar in functionality to the PS of Linux.
Common JDK command-line tools:
JPS:
Jstat: Virtual machine Statistics monitoring Tool
Jinfo:
Jmap:
Jhat:
Jstack:
Visualization tools for 2.JDK
Jconsole:java Monitoring and Management console
VISUALIVM: Multi-in-a-fault processing tool

The 5th chapter of tuning case analysis and actual combat
Share a few more representative practical cases.
1. Program deployment strategy on high-performance hardware
There are two main ways to deploy programs on high-performance hardware:
Using 64-bit JDK to use large memory;
Use several 32-bit virtual machines to build, logical clusters to take advantage of hardware resources.

For a system with strong user interaction and a time sensitive to pause times, the premise of allocating super large heaps to virtual machines is to control the full GC frequency of the application sufficiently low to affect the user's use.
The key to control the full GC frequency is to see if the majority of the objects in the application meet the principle of "coming out of life", that is, most of the objects should not be long-lived, especially large objects that cannot produce batches and long-lived time, so as to guarantee the stability of the old age space.

When you use 64-bit JDK to manage memory, you also need to consider the following possible issues:
Long-time pauses caused by memory recycling;
Performance may be generally low;
The same program consumes more memory than the 32-bit JDK in a 64-bit JDK because of such factors as pointer expansion and data type alignment fillers.

2. Memory overflow due to inter-cluster synchronization

3. Overflow error due to out-of-heap memory
Extensive use of NIO operations can consume a lot of out-of-heap memory.
Here are some practical experiences, in addition to the Java heap and the permanent generation of memory:
Direct Memory: Can be resized by-xx:maxdirectmemorysize and thrown OutOfMemoryError
or Outofmemoryerror:direct buffer memory.
Thread stacks: Can be resized by-XSS and thrown stackoverflowerror when out of memory (cannot be allocated vertically, i.e. new stack frames cannot be allocated)
Socket buffers: Each socket connection is receive and send two buffers, accounting for approximately 37KB and 25KB of memory respectively.
JNI Code:
Virtual Machines and GC:

4. External command causes slow system

5. Server JVM Process crashes

6. Actual combat: Eclipse Run Speed tuning

Deep understanding of Java Virtual machines: JVM advanced features and best practices learn note ⅱ