JVM Learning Notes

During the geek hour learning session, Li Zhihui shared her experience on the new technology learning method, called the “5-20-2” method.

To explain, when learning a new skill:

  • In 5 minutes to understand what he is to solve the problem, compared with the competitive product technology advantages;
  • Within 20 minutes, learn what ideas and novel approaches the technology uses to solve these problems;
  • In less than two hours, try doing some quick demos.

If you can do that, keep digging deep into the technology, and if you can’t solve the problems, stop early so you don’t waste too much time.

In order to test the feasibility of the above method, STARTING from JVM, I began to consciously train myself to learn new technologies in a short period of time. Although the timing failed, it took 10 hours to get a general impression of the JVM. (Less efficient and subject to training), but this start-at-the-end, compulsively “skimming” approach is a great framework for mastering new technology quickly.

Here’s a rundown of the JVM’s problems.

What are the main problems that the JVM solves

  • Portability of code to different platforms
  • Dynamic allocation of memory
  • Automatic garbage collection

How does the JVM solve these problems

portability

Java code, according to different platforms, compile the corresponding machine code;

Here are some things to know:

  • The structure of the class file
  • Class loading mechanism
  • Code execution mechanism

Note: This part is not expanded and will be filled in later.

Dynamic memory allocation

Here are some things to know:

  • What Java code has to load into memory
  • What are the regions in the JVM, and what does each region do
  • How do different areas interact with each other

Question 1: What information is loaded by the JVM

Items that need to be recorded in memory include: classes, data types, instantiated objects, program execution status (where it was executed), and so on.

Question 2: The MEMORY model of the JVM (which areas and functions it has)

Shared by all threads:

  • Method area: also known as the permanent generation, metadata area metaSpace(after JDK1.8). A thing to refer to.

Used to store class information, constants, and static variables loaded by VMS.

  • Static constant pools are stored in the method area.
  • Permanent generation garbage collection is tied to old generation, so whoever fills up triggers permanent generation and old generation garbage collection.
  • Heap: OOM hardest hit area

Used to hold instantiated objects.

Mainly includes:

  • New generation: includes Eden zone and Survivor zone, and From and To zone are Survivor zone (also called Survivor0 and Survivor1).

  • Old age: mainly used for “age” over 15 objects (transfer age can be set), as well as large objects that need continuous memory space;

Resource allocation habits:
  • The ratio of Young to Old area is 1:2
  • The ratio of Eden to Survivor0 is 8:1, so that 10 equal shares of Young and new generations can be guaranteed.
Reasons for zoning:

In order to execute different GC algorithms in different regions, different GC algorithms are selected according to the life cycle of different objects to maximize efficiency.

Object transfer mechanism:
  • The object is created and stored in Eden;
  • Survive the initial Minor GC and move to Survivor zone;
  • Survival after each GC, age +1;
  • After reaching the age of 15 (default value, parameter can be set), transfer to the Old zone;
  • If memory space is required for creating a large object, create the object in the Old area if Eden does not meet the requirement.

Schematic diagram of heap memory partition:

Note: In the new generation storage, except Eden, it is called Survivor area. Because Survivor zones adopt the replication memory reclamation method, they are divided into two Survivor zones on average, namely Survivor0 and Survivor1, for each other’s memory migration purposes.

So the ratio of Eden to Survivor0 is set to 8:1.

Thread private:

  • VM Stack

Describes Java method execution, creating a “stack pin” for each method executed,

You get an OverOutStack

Mainly includes:
  • Operand stack:
  • Local variable scale: Local variables used to record methods,Note: this is a reference, not a real object
  • The frame data area
  • Native Method Stack

This region primarily serves the JVM’s Native functions. You don’t have to worry about this area.

  • Program Counter Register

The smallest area in the JVM that records the line number indicator of bytecode executed by the current program. Records the current position of the program execution.

Question 3: How do different areas interact with each other

Note: To be improved

Automatic Garbage Collection (GC)

Question:

  • Which memory areas need to be reclaimed
  • How to decide whether to recycle
  • How to reclaim memory, common GC algorithm
  • GC algorithm for different regions

Question 1: Which areas of memory are GC

  • Young: Part of the heap memory
  • Old: Part of the heap memory
  • MetaSpace: method area

Question 2: How do I determine whether the current object should be reclaimed

The tradition is object reference. Not exactly, there will be two useless object reference to each other method, resulting in both object reference number greater than 0, cannot be GC.

The current JDK uses: reachability analysis, directed graph algorithm, objects that cannot be connected from Root Object, are GC.

Objects in the VM stack can be understood as Root objects and searched down.

Problem 3: Common GC algorithms

  • Mark clearing algorithm: mark useless Ob and clear it. The downside is that it creates a lot of debris space.
  • Mark collation and compression algorithm: mark objects and merge memory regions;
  • Replication algorithm: two identical regions, after collating the memory in region 1, place it all in region 2;
  • Generational collection algorithm.

Problem 4: GC algorithm for different regions

Eden: Problem point.

Survivor: mark-copy algorithm

Old & MetaSpace: CMS collection algorithm is generally used

Full GC: Triggered when the Old section or MetaSpace is Full, causing the ENTIRE JVM to pause. Stop the world

Problem 5: Garbage collector concept

Serial:

ParNew:

The Parallel:

CMS: concurrency-mark-sweep algorithm, an algorithm that sacrifices throughput for the shortest reclaim pause time. (Mark cleaning by thread)

G1: Parallel tagging, generational collection, spatial collation, predictable pauses. (Don’t understand, TBD)

Note: When the remaining space of the Old region is less than the average size, the Full GC is triggered, also known as “Stop the world”. The entire JVM is stopped and the memory resource is reclaimed. The GC resource consumption of the Old region is high, and large objects with a short lifetime should be avoided.

Tools used

The JVM configuration items

Memory area size configuration:

The size of the method area (permanent generation) is limited by the -xx :PermSize and -xx :MaxPermSize parameters. -xx :+UseConcMarkSweepGC: set the CMS GC algorithm -xSS: set the stack memory -xmn: Set the young generation of memory (Eden + Survivor) - XX: SurvivorRatio = 8: set the Eden and Survivor ratio of 8:1, XX: PretenureSizeThreshold: set up large object threshold, -xms: the minimum size of heap memory, which defaults to 1/64 of physical memory. -xmx: the maximum size of heap memory, which defaults to 1/4 of physical memory. -xMN: the size of new generations in the heap. The size of the old generation can also be obtained from this value: -xmx minus -xmnCopy the code

The GC configuration:

The dump file is printed in OOM. + HeapDumpOnOutOfMemoryError - - XX: XX: HeapDumpPath = file_path modified GC collector for CMS - XX: + UseConcMarkSweepGC garbage collection statistics - XX: + PrintGC -xx :+PrintGCDetails: console displays GC details. -xx :+PrintGCTimeStamps -xloggc :filenameCopy the code

OOM

Heap overflow

java.lang.OutOfMemoryError: Java heap space

  • According to the Dump file, determine which area of memory overflow, modify the code logic accordingly, check whether there are discarded objects, not released reference.
  • Adjust JVM parameters as appropriate.

Stack overflow

java.lang.OutOfMemoryError.StackOverflowError

The stack depth required by the program is too large, you can write a dead recursive program triggered.

Overflow of permanent generation

OutOfMemoryError: PermGen space

The persistence band contains the method area, which contains the constant pool.

So a persistent band overflow could be either (1) a run-time constant pool overflow, or (2) Class objects stored in the method area were not recycled in time, or the Class information took up more memory than we configured.

Note: real knowledge comes from actual combat, and theoretical study is the gateway.

Unable to create local thread

Caused by: java.lang.OutOfMemoryError:unable to create new native thread

The total memory capacity of the system remains the same. If the heap memory and non-heap memory Settings are too large, insufficient memory can be allocated to threads.

Commonly used tools

JVM analysis tools

  • Jps: View the current Java process and its process number
  • Analyze using jMAP tool
C:\Users\Yanru>jmap -J-d64 -heap 30284(PID) Attaching to process ID 30284, please wait... Debugger attached successfully. Server Compiler detected. JVM version is 25.201-B09 using Parallel Threads in the new ## Concurrent mark-sweep GC ## Concurrent mark-sweep GC ## Concurrent mark-sweep GC Configuration: The heap configuration is the result of the configuration of JVM parameters. MinHeapFreeRatio = 40 ## Minimum heap usage MaxHeapFreeRatio = 70 ## Maximum heap usage MaxHeapSize = 2147483648 (2048.0MB) ## Maximum heap size NewSize = 268435456 (256.0MB) ## MaxNewSize = 268435456 (256.0MB) ## OldSize = 5439488 (5.1875MB) ##perm zone permanent generation size MaxPermSize ##perm zone permanent generation size MaxPermSize ## Perm zone permanent generation size = 134217728 (128.0MB) ## Heap Usage: ## New Generation (Eden + 1 Survivor Space): ## Cenozoic (Eden + survial) capacity = 241631232 (230.4375MB) ## Eden (74.17323303222656MB) Free = 163854960 (156.26426696777344MB) ## Free Space ## Eden capacity = 214827008 (204.875MB) ## Eden capacity used = 74442288 (70.99369812011719MB) ## Eden capacity used = 140384720 (133.8813018798828MB) ## Eden current remaining capacity 34.65220164496263% used ## Eden usage ………………Copy the code
  • jmap -dump:format=b,file=idea.bin 22128

Generates a JVM status file for process 22128.

  • Jstat: View the health of local classes and remote JVMS

First choice for troubleshooting problems without visual terminals. For process 13224, query 20 times every 250 milliseconds.

C:\Users\Yanru>jstat -gc 13224 250 20
 S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT
10240.0 10240.0  0.0    0.0   81920.0  35945.2   102400.0     0.0     4480.0 775.8  384.0   76.4       0    0.000   0      0.000    0.000
Copy the code
  • Jinfo UID: View the JVM properties of the thread

VM Flags: Non-default VM flags: -XX:CICompilerCount=4 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=null -XX:InitialHeapSize=31457280 – XX: MaxHeapSize = 52428800 – XX: MaxNewS…………………

  • JMC: Visual JVM detection tool

  • Jconsole: Java monitoring management console

You can view the size of each area of heap memory.

JVM Monitoring tool

  • Jconsole: You can view the local Jvm dump file

  • VisualVM: A unified visual monitoring tool

JVM tuning strategies

< to be updated >

Frequently seen exam

< to be updated >

Of course, this outline is not even an introduction to the JVM, a large and widely used technology, but rather a skill tree to understand the technology and fill in the corresponding areas when problems arise.

This mental architecture is similar to sherlock’s memory palace.