01. Preface

Brush Douban saw the third edition of in-depth understanding of JVM, so he bought it to update the JVM knowledge. This article is a note for personal Review only.

02. Java memory area and memory overflow

03. Runtime data area

Reference: JVM specification, Memories of a Java Runtime

Heap: the memory area created by - Xmx, -Xms when the JVM is started. It is used to allocate the memory required by objects and arrays. It is managed and recycled by GC

Method area: stores the class information loaded by the JVM (fields, bytecode instructions of member methods, etc.), runtime constant pool (literal, symbol reference, etc.), JIT compiled Code Cache, etc; Before JDK8, Hotspot stored the method area in the permanent generation heap memory, and then abandoned the permanent generation with reference to JRockit and stored it in the Metaspace area of local memory

Direct memory: JDK1.4 introduces NIO, uses Native/Unsafe libraries to allocate system memory directly, and uses buffer and channel to interact with it to avoid the overhead of copying between system memory and JVM heap memory

Thread private memory

• Program counter: records the position of the next instruction to be executed by the current thread, resumes execution after context switching, and is updated by the bytecode interpreter
• JVM stack
• Describes the memory model of Java method execution: when executing a new method, create a stack frame and store information such as local variable table and operand stack
• Storage unit: variable slot, long and double account for 2 slots, and other basic data types and reference types account for 1. Therefore, the total length of the table can be known during compilation
• Native method stack: executes native C/C + + methods

04. JVM object

1. Create object

Allocate heap memory: after the class is loaded, the memory required by its object is determined; Heap memory is shared by multiple threads. If concurrent objects compete for memory through CAS optimistic locks, the efficiency is low. Therefore, when a thread is created, a private allocation buffer (TLAB: Thread Local Allocation Buffer) is allocated to the heap memory

• Memory model

• Allocation process

Note: when the remaining space of TLAB is insufficient to allocate new objects, but it is less than the maximum wasted space threshold, a new TLAB will be created by locking

Zero value initializes the heap memory of the object, sets the object header information, and executes the constructor () V

2. Memory layout of objects

Object header

• Mark Word: records the runtime information of the object, such as hashCode, GC generation age, and the tail 2 bit s are used to mark the lock status

• Class Pointer: refers to the class information to which it belongs
• Array length (optional, the object is an array): 4 bytes store its length

Object data: the values of various fields are stored next to each other by width

Alignment and filling: memory alignment is an integer multiple of 1 word length to reduce CPU bus cycle

Verification: openjdk/jol checks object memory layout

public class User {
private int age = -1;
private String name = "unknown";
}

// java -jar ~/Downloads/jol-cli-latest.jar internals -cp . com.jol.User
OFF  SZ               TYPE DESCRIPTION               VALUE
0   8                    (object header: mark)     0x0000000000000001 (non-biasable; age: 0)
8   4                    (object header: class)    0xf8021e85 // User.class reference address
 12   4                int User.age                  -1         // Basic types store values directly
 16   4   java.lang.String User.name                 (object)   // A reference type that points to a String object in the runtime constant pool
 20   4                    (object alignment gap)               // There is a 4-byte memory fill
Instance size: 24 bytes

05. Memory overflow

Heap memory: - Xms specifies the initial size of the heap. When the memory occupied by a large number of objects that cannot be recycled exceeds the upper limit of - Xmx, a memory overflow OutOfMemoryError will occur

• Troubleshooting: locate large objects that cannot be recycled and find their GC Root reference path through the *. hprof heap dump file generated by Eclipse MAT analysis - XX:+HeapDumpOnOutOfMemory
• Solution: in case of memory leakage, modify the code and recycle large objects in time by means of null explicit assignment and virtual reference; In case of memory overflow, all large objects must survive. Increase - Xmx, reduce the life cycle of large objects, and check whether the use of data structure is reasonable

// -Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError
public class HeapOOM {
 static class OOMObject {}
 public static void main(String[] args) {
  List<OOMObject> vs = new ArrayList<>();
  while (true)
     vs.add(new OOMObject());
 }
}

Analyzing GC Root, it is found that com.ch02.HeapOOM object indirectly references a large number of OOMObject objects, occupying a total of 15.4MB heap memory, which cannot be recycled, resulting in OOM

Stack memory: - Xss specifies the stack size. When the stack depth exceeds the threshold (such as recursive calls that do not trigger termination conditions), the local method variable table is too large, etc., it may lead to memory overflow StackOverflowError

Method area: - XX:MetaspaceSize specifies the initial size of meta space, - XX:MaxMetaspaceSize specifies the maximum size. The default is - 1 unlimited. If a large number of classes are generated dynamically at runtime, OOM may be triggered

Runtime constant pool: strObj.intern() dynamically puts the first string object into the string constant pool and returns it. Before JDK7, it will be copied to the permanent generation, and then it will directly reference the heap object

String s1 = "java"; // When the class is loaded, the symbol is copied from the bytecode constant pool to the runtime constant pool, and the string object initialized in the parsing phase
String s2 = "j";
String s3 = s2 + "ava"; // Dynamically allocated string object on heap
println(s3 == s1);          // false
println(s3.intern() == s1); // true / / already exists in string constant pool

Direct memory: - XX:MaxDirectMemorySize specifies the size. It is as large as - Xmx by default. It is not managed by GC. When the requested memory exceeds the threshold, OOM

06. Garbage collection and memory allocation

GC can be divided into three sub questions: which memory can be recycled, when and how

07. GC conditions

1. reference counting algorithm

Principle: each object maintains a reference counter rc. When it is referenced by assignment and parameter passing, rc + +. When the reference variable is dereferenced by modifying the direction and leaving the function scope, rc --, when it decreases to 0, it indicates that the object can no longer be used and can be recycled. Pseudo code:

assign(var, obj):
incr_ref(obj) # self = self # First increase and then decrease to avoid early memory release caused by referencing itself
decr_ref(var)
var = obj
 
incr(obj):
obj.rc++

decr(obj):
obj.rc--
if obj.rc == 0:
  remove_ref(obj) # Break the reference relationship between obj and other objects
  gc(obj)         # Reclaim obj memory

Advantages: the idea is simple, the object is useless or recycled, and the delay is low. It is suitable for scenes with less memory

Disadvantages: the objects in this algorithm are isolated, and the authenticity and validity of the objects cannot be checked from the global perspective. The objects of both sides of the circular reference need to be detected and recycled by introducing an external mechanism, as shown in the red circle in the figure below (source: what is garbage collection)

2. reachability analysis

Principle: starting from the objects that will not be recycled (GC Roots), search the global object graph outward. The unreachable objects can no longer be used and can be recycled; Common objects that can be used as GC Root are:

• Execution context: heap objects referenced by parameters, local variables, temporary variables, etc. in the JVM stack
• Global reference: the object pointed to by the static reference and constant reference of the class in the method area (such as the string object in StringTable)

Advantages: no object is required to maintain GC meta information, and the overhead is small; Single scan can identify and recycle objects in batch, with high throughput

Disadvantages: in the multithreaded environment, the reference relationship between objects is changing at any time. In order to ensure the accuracy of GC Root tag, it needs to be carried out in the unchanged snapshot, resulting in Stop The World (hereinafter referred to as STW) Caton

3. Four reference types

Example: limit heap memory to 50MB, including 30MB for the new generation and 20MB for the old generation; Allocate 10MB byte [] objects five times in sequence, use only soft references for reference, and observe the GC process

public static void main(String[] args) {
// softRefList --> SoftReference --> 10MB byte[] 
List<SoftReference<byte[]>> softRefList = new ArrayList<>();
ReferenceQueue<byte[]> softRefQueue = new ReferenceQueue<>(); // Invalid reference queue
for (int i = 0; i < 5; i++) {
  SoftReference<byte[]> softRef = new SoftReference<>(new byte[10*1024*1024], softRefQueue);
  softRefList.add(softRef);

  for (SoftReference<byte[]> ref : softRefList) // dump all objects pointed to by soft references. Check whether they have been recycled
      System.out.print(ref.get() == null ? "gced " : "ok ");
  System.out.println();
}
Reference<? extends byte[]> ref = softRefQueue.poll();
while (ref != null) {
  softRefList.remove(ref); // Dereference the soft reference object itself
  ref = softRefQueue.poll();
}
System.out.println("effective soft ref: " + softRefList.size()); // 2
}

// java -verbose:gc -XX:NewSize=30m -Xms50m -Xmx50m -XX:+PrintGCDetails com.ch02.DemoRef
ok 
ok ok 
// When allocating the third [] byte, Eden GC is invalid, triggering Full GC to promote a [] byte to the elderly area
// At this time, the three byte s [] are only referenced by soft references and are marked for secondary recycling (if they are weak references, Eden has been recycled at this time)
[GC (Allocation Failure) --[PSYoungGen: 21893K->21893K(27136K)] 21893K->32141K(47616K), 0.0046324 secs]
[Full GC (Ergonomics) [PSYoungGen: 21893K->10527K(27136K)] [ParOldGen: 10248K->10240K(20480K)] 32141K->20767K(47616K), [Metaspace: 2784K->2784K(1056768K)], 0.004 secs]
ok ok ok
// Again, the first three byte s [] are all recycled
[GC (Allocation Failure) --[PSYoungGen: 20767K->20767K(27136K)] 31007K->31007K(47616K), 0.0007963 secs]
[Full GC (Ergonomics) [PSYoungGen: 20767K->20759K(27136K)] [ParOldGen: 10240K->10240K(20480K)] 31007K->30999K(47616K), [Metaspace: 2784K->2784K(1056768K)], 0.003 secs]
[GC (Allocation Failure) --[PSYoungGen: 20759K->20759K(27136K)] 30999K->30999K(47616K), 0.0007111 secs]
[Full GC (Allocation Failure) [PSYoungGen: 20759K->0K(27136K)] [ParOldGen: 10240K->267K(20480K)] 30999K->267K(47616K), [Metaspace: 2784K->2784K(1056768K)], 0.003 secs]
gced gced gced ok
gced gced gced ok ok

4. finalize

Principle: if the object is unreachable and marked recyclable, it will be filtered whether the finalize() has been rewritten and executed. If it passes, the object will be put into the F-Queue queue and wait for the low priority background Finalizer thread to trigger the execution of its finalize() (the end of execution is not guaranteed), Object can establish a reference relationship with any node in the GC Root object graph in finalize to escape GC

Usage: the finalize mechanism is not equivalent to the destructor in C + +, and its execution result is uncertain. It is not recommended and can be replaced by try finally

08. GC algorithm

Generational collection theory

Two generational hypotheses: in line with the actual situation of most programs

• Weak generation hypothesis: most objects are born in the morning and die in the evening, and their survival time is very short
• Strong generational hypothesis: the more GC objects survive, the more likely they are to continue to be used and the more difficult it is to recycle

Correspondingly, the JVM heap is divided into two different regions, and objects are classified by age, taking into account GC time and memory utilization

• New generation: a large number of objects will be recycled. Only the surviving objects will be concerned and promoted gradually
• Old age: a large number of objects are not recycled, only focus on the objects to be recycled

Cross generational reference

• Problem: the old generation will refer to the new generation, and the new generation GC needs to traverse a large number of surviving objects in the old generation to analyze accessibility and high time complexity
• Background: the objects of mutual reference tend to exist and die at the same time. For example, the new generation in the cross generational reference relationship is bound to be promoted gradually, and finally the cross generational relationship is eliminated
• Hypothesis: compared with intergenerational references, intergenerational references account for only a few, and there is no need to scan the elderly generation
• Implementation: the new generation maintains the global data structure: the Remembered Set, which divides the old generation into multiple sub blocks, marks the sub blocks with cross generation references, and waits for subsequent scanning; Cost: to ensure the correctness of the memory set, it is necessary to keep synchronization when cross generation references are established or disconnected

09. Mark sweep

• Principle: Mark unreachable objects, clean and recycle them uniformly, and vice versa
• Disadvantages: the execution efficiency is unstable, and the recovery time depends on the number of active objects; If there are too many memory fragments, there will be continuous memory (array) with sufficient memory but unable to allocate too large

10. Mark copy: mark copy

• Theory: cut the heap memory into two equal parts A and B, use only a each time, mark the living object and copy it to B after it is used up, and execute swap after clearing a
• Advantages: it directly aims at half area recycling and has no memory fragmentation problem; To allocate memory, you only need to move the heap top pointer for efficient sequential allocation
• Disadvantages: when there are A large number of live objects in area A, the replication overhead is large; Area B is idle for A long time, resulting in serious memory waste
• Practice: for the new generation with few surviving objects, it is not necessary To allocate by 1:1, but by 8:1:1 memory layout. Eden and From areas are used at the same time, and only To area will be idle (guarantee mechanism: if To area is not enough To accommodate the surviving objects after Minor GC, it will be promoted To the elderly area)

11. Mark compact

• Principle: after marking the living objects, move them to one side of the memory space, and then recycle the memory outside the boundary
• Advantages: simple memory model, no memory fragments, reducing the time cost of memory allocation and access, and improving throughput
• Disadvantages: STW needs to update the reference relationship synchronously when moving objects, which will increase the delay

12. HotSpot GC algorithm details

13. Initiating GC: safe points and safe areas

• Question: in order to ensure the accuracy of the reachability analysis results, it is necessary to suspend the user thread (STW), and then collect the GC Root from the execution context of each thread. How do you notify the thread to suspend?
• Safety point: there is thread interrupt mark inside HotSpot; Insert an additional test instruction to check the mark at the instruction for long-time execution such as method call, loop jump and abnormal jump of each thread; If the polling discovery flag is true, the thread will actively suspend at the nearest SafePoint. At this time, the reference relationship of the object on its stack will no longer change, and the GC Root object can be collected
• Security area: the instruction area where the reference relationship will not change, and the GC Root can be collected safely; When the thread leaves this area, it needs to wait if the GC Root collection process has not ended

Sketch Map

14. Accelerating GC: CardTable

Question: there will be cross generational references to the collection area (Cenozoic) in the non collection area (old age). How to avoid full scanning of the former?

Card table: byte array implementation of memory set; Divide the old generation memory into sub memory blocks with the size of Card Page (512KB). If a cross generation reference is created, the corresponding card will be marked as dirty. During GC, only the sub memory blocks marked as dirty in the old generation need to be scanned

Write barrier: different from volatile memory barrier that disables instruction rearrangement, write barrier in GC is a mechanism to perform additional hook actions when object references are updated. Simple implementation:

void oop_field_store(oop* field, oop new_val) { // oop: ordinary object pointer
// pre_write_barrier(field, new_val); //  Barrier before writing: execute before updating and use oop old state
*field = new_val;
post_write_barrier(field, new_val); // Post write barrier: execute after updating
}

Use the write barrier to ensure the real-time update of CardTable (Figure source: The JVM Write Barrier - Card Marking)

15. Correct GC: concurrent reachability analysis

Reference speech: Shenandoah: the garbage collector that court by Aleksey shipilev

**Problem: * * the object source of GC Roots is fixed, so the STW time during enumeration is short and controllable. However, the time complexity of subsequent reachability analysis is positively correlated with the number of objects in the heap, that is, the more objects in the heap, the more complex the object graph, and the STW time after the heap becomes larger is unacceptable

**Resolution: * * concurrency flag. Lead to new problems: the user thread dynamically establishes and dereferences, and the graph structure changes during the marking process, resulting in unreliable results; Proof: three color method is used to describe the object state

• White: objects that have not been accessed by the collector; The beginning of the analysis is white, but the end of the analysis is still white
• Gray: accessed by the collector, but at least one reference on it has not been scanned (intermediate state)
• Black: accessed by the collector, all references on it have been scanned, and there is a reference chain, which is a living object; If other objects refer to black objects, they do not need to be scanned and must survive; Black cannot directly reference white

STW has no concurrent correct flag: the top 3 objects will be recycled

Concurrent modification of references by user threads will lead to invalid tag results. There are two cases:

• Less recycling, the object is marked as alive, but the user dereferences it: floating garbage is generated, acceptable, waiting for the next GC

• Error recycling: the object is marked as recyclable, but the user creates a new reference: the actual living object is recycled, memory error

The paper uniprocessor garbage collection technologies - Paul R. Wilson § 3.2 proves that "the actual living object is marked as recyclable" must meet two conditions (in time order) at the same time

• Insert one or more new references from black to white
• Delete all direct and indirect references from gray to white

In order to correctly realize the marking, one of the conditions can be broken (analogous to the idea of breaking one of the four conditions of deadlock), corresponding to two schemes respectively:

• Incremental update: record the reference relationship from black to white. After concurrent marking, take black as the root and rescan; A direct survival
• Original snapshot SATB (snapshot at the beginning): record the gray to white dereference relationship. After concurrent marking, take gray as the root and rescan; B is gray, and finally becomes black, surviving. Note that if there is no step 3, B and C become floating garbage

16. Classic garbage collector

Schematic diagram of matching use:

17,Serial, SerialOld

Principle: when GC is triggered due to insufficient memory, all user threads will be suspended, and the new generation will be marked and copied in a single way. The old generation will be marked and sorted out, and the user threads will be restored after collection

Advantages: the whole process STW is simple and efficient

Disadvantages: STW duration is positively related to the number of heap objects, and GC threads can only use 1 core, which cannot be accelerated

Scenario: single core CPU with less available memory (such as 100MB), the only option before JDK1.3

18,ParNew

Principle: the Serial implementation of multi-threaded parallel version can effectively reduce the STW duration; The number of threads is the same as the number of cores by default and can be configured

Scenario: before JDK7, it was used with the old CMS recycler

19,Parallel, Parallel Old

Garbage collection has two goals that are usually not both

• Low delay: STW duration, fast response; Allow high-frequency and transient GC, such as reducing Cenozoic space and accelerating collection delay (throughput reduction)
• High throughput: high user thread time / (user thread time + GC thread time) and low total GC time; Allow low frequency, single long time GC, (delay increase)

Principle: similar to ParNew, both are parallel recycling, and three options are added (tend to improve throughput)

• -20: Maxgcpausetime: controls the maximum delay
• -20: Gctimeratio: control throughput (99% by default)
• -20: + useadaptive sizepolicy: enable adaptive policy to automatically adjust the memory ratio of Eden and two Survivor areas - XX:SurvivorRatio, promotion threshold of the elderly generation - XX: pretenusizethreshold

20,CMS

CMS: Concurrent Mark Sweep, i.e. Concurrent Mark Sweep, mainly has four stages

• initial mark: STW collects GC Roots quickly
• concurrent mark: detect the reference chain from GC Roots and mark recyclable objects; Execute concurrently with the user thread, and avoid false recycling through incremental update
• remark: STW reanalyzes GC Roots collected by incremental updates
• Concurrent sweep: concurrent sweep recyclable objects

Advantages: the time of two STW s is much shorter than that of concurrent marking, and the delay is greatly reduced compared with the first three collectors

shortcoming

• CPU sensitivity: if the number of cores is small (< 4core), concurrent marking will occupy a lot of CPU time, resulting in a sudden drop in throughput
• Unable to process floating garbage: - XX: cmsinitiatingoccupancyfraction (default 92%), specify the threshold to trigger CMS GC; During concurrent marking and concurrent cleaning, the user thread will generate floating garbage (reference recyclable objects and generate new objects). If the proportion of floating garbage exceeds - XX: cmsinitiatingoccupancyfraction; If too much floating garbage is generated at the same time of GC, resulting in insufficient memory of the older generation, CMS concurrency failure will occur and degenerate into Serial Old to execute Full GC, resulting in a sudden increase in delay
• Unable to avoid memory fragmentation: - XX:CMSFullGCsBeforeCompaction (default 0) specifies to defragment the memory fragments of the old age before Full GC every time

21,G1

Features: local recycling based on region memory layout; GC delay target configurable; No memory fragmentation

Cross generation reference: in addition to using the card table to mark whether each card page is dirty, each region also uses the hash table to record which regions each card page is being referenced by. Through this "two-way pointer" mechanism, the Old area can be found directly to avoid full scanning (the memory overhead of G1 itself)

G1 GC has 3 stages (refer to its GC log)

• Cenozoic GC: Eden area proportion over threshold trigger; Mark the living objects and copy them to the Survivor area. There may be objects in it that will be promoted to the Old area

• When the proportion of GC: Old area reaches the threshold, it is triggered to perform label sorting
• Initial tag: enumerate GC Roots, which has been completed during the new generation GC
• Concurrency flag: perform reachability analysis concurrently, and use SATB to record reference changes
• Re labeling: SATB analysis to avoid false recycling
• Filter recycling: the regions are filtered according to the recycling value and time cost to form a recycling set. STW copies the living objects to the empty regions and cleans up the old regions to complete the recycling
• Mixed GC

Parameter control (document: HotSpot GC Tuning Guide)

22. Memory allocation strategy

Using Serial Collector - XX:+UseG1GC demo

1. Priority distribution of objects in Eden District

The new objects are allocated in Eden district. If the space is insufficient, miner GC will be triggered, and the surviving objects will be copied to To Survivor. If the memory is still insufficient, they will be transferred to the elderly district through the allocation guarantee mechanism. If the memory is still insufficient, OOM will be started

byte[] buf1 = new byte[6 * MB];
byte[] buf2 = new byte[6 * MB]; // 4MB left in 10MB eden area, insufficient space, trigger minor GC

// java -verbose:gc -Xms20m -Xmx20m -Xmn10m -XX:+PrintGCDetails -XX:+UseSerialGC com.ch03.Allocation
// After minor gc, the memory of the new generation was reduced from 6M to 0.2M, the surviving objects were moved to the old area, and the total heap memory was still 6MB
[GC (Allocation Failure) [DefNew: 6823K->286K(9216K), 0.002 secs] 6823K->6430K(19456K), 0.002 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
Heap
 def new generation   total 9216K, used 6513K 
eden space 8192K,  76% used // buf2
from space 1024K,  28% used
to   space 1024K,   0% used 
 tenured generation   total 10240K, used 6144K
 the space 10240K,  60% used // buf1

2. Large objects directly enter the elderly area

For serial and parnew, large objects (continuous memory) exceeding the threshold of - XX: pretenusizethreshold can be configured and allocated directly in the older generation to avoid triggering minor gc, resulting in a large number of memory replication operations by Eden and Survivor

byte[] buf1 = new byte[4 * MB];

// java -verbose:gc -Xms20m -Xmx20m -Xmn10m -XX:+PrintGCDetails -XX:+UseSerialGC
// -20: Pretenuresizethreshold = 3145728 com. CH03. Allocation / / 3145728, i.e. 3MB
Heap
 def new generation   total 9216K, used 843K 
eden space 8192K,  10% used 
from space 1024K,   0% used 
to   space 1024K,   0% used 
 tenured generation   total 10240K, used 4096K 
 the space 10240K,  40% used // buf1

3. The long-term surviving objects enter the elderly generation

The 4bit age field in the object header stores the current GC generation age of the object. When the threshold - XX:MaxTenuringThreshold (15 by default, that is, the maximum value of the age field) is exceeded, it will be promoted to the old age. You can use - XX:+PrintTenuringDistribution to observe the generation distribution

byte[] buf1 = new byte[MB / 16];
byte[] buf2 = new byte[4 * MB];
byte[] buf3 = new byte[4 * MB]; // Trigger minor gc
buf3 = null;
buf3 = new byte[4 * MB];

// java -verbose:gc -Xms20m -Xmx20m -Xmn10m -XX:+PrintGCDetails -XX:+UseSerialGC 
// -XX:MaxTenuringThreshold=1 -XX:+PrintTenuringDistribution com.ch03.Allocation
[GC (Allocation Failure) [DefNew
Desired survivor size 524288 bytes, new threshold 1 (max 1)
- age   1:     359280 bytes,     359280 total
: 4839K->350K(9216K)] 4839K->4446K(19456K), 0.0017247 secs] 
// So far, buf1 has survived the first collection, age=1
[GC (Allocation Failure) [DefNew
Desired survivor size 524288 bytes, new threshold 1 (max 1): 4446K->0K(9216K)] 8542K->4438K(19456K)] 
Heap
 def new generation   total 9216K, used 4178K 
eden space 8192K,  51% used 
from space 1024K,   0% used // buf1 was promoted in advance in the second round of collection
to   space 1024K,   0% used 
 tenured generation   total 10240K, used 4438K 
 the space 10240K,  43% used 

4. Dynamic judgment of generation age

-20: Maxtenuringthreshold is not the minimum hard threshold for promotion. When the number of objects of the same age in Survivor exceeds 50%, objects greater than or equal to this age will be promoted automatically, even if it has not reached the threshold

5. Space allocation guarantee

The old age is the guarantee area of To Survivor area. When the total size of surviving objects in Eden + From Survivor exceeds To Survivor, it will try to store them in the old age. After JDK6, as long as the continuous space of the old age is greater than the total size of the new generation objects or the average size of the previous promotion, only Minor GC will be performed, otherwise Full GC will be performed

23. Class file structure

Class file realizes language independence and JVM realizes platform independence. Refer to Java virtual machine specification

A Class file describes the explicit definition of a Class or interface. The content of the file is a group of binary streams in 8 bytes. There is no separator between data items. Data items exceeding 8 bytes are stored after being segmented by big endian. There are two types of data items:

• Unsigned number: describes the basic type; Use U1, U2, U4 and U8 to represent the unsigned number of 1,2,4 and 8 bytes in length respectively; Store digital values, index sequence numbers, UTF-8 encoded values, etc
• Table: composite type composed of unsigned numbers and nested other tables; Agreement_ info suffix; Store field types, method signatures, and so on

24. Structure definition

25. Grammar

Reference document: The class File Format

ClassFile {
u4             magic;         // magic number
u2             minor_version; // Version number
u2             major_version;
u2             constant_pool_count; // Constant pool
cp_info        constant_pool[constant_pool_count-1];
u2             access_flags;     // Class access tag
u2             this_class;       // Fully qualified name of this class
u2             super_class;      // Single parent
u2             interfaces_count; // Multiple interfaces
u2             interfaces[interfaces_count];
u2             fields_count;  // Field table
field_info     fields[fields_count];
u2             methods_count; // Method table
method_info    methods[methods_count];
u2             attributes_count; // Class properties
attribute_info attributes[attributes_count];
}

• Magic: magic number, simply identify *. class file, and the value is fixed as 0xCAFEBABE
• minor_version, major_version: the minor and major version numbers of the Class file
• constant_pool_count: constant pool size + 1
• constant_pool: constant pool. The index starts from 1. The value of 0 is reserved, indicating that no constant in any constant pool is referenced; Constants fall into two categories
• Literal quantity: such as UTF8 string, int, float, long, double and other numeric constants
• Symbol reference: there are 17 existing constants such as fully qualified names of classes and interfaces, field names and descriptors, method types and descriptors. Except that u1 tag prefix is used to identify constant types, the structures of constants are different from each other. The common ones are:
• CONSTANT_Utf8_info: save the string encoded by UTF8

CONSTANT_Utf8_info {
  u1 tag;           // The value is 1
  u2 length;        // bytes array length, u2 the maximum value is 65535, that is, the literal amount of a single string does not exceed 64KB
  u1 bytes[length]; // Byte array of variable length
}

• CONSTANT_Class_info: represents a symbolic reference to a class or interface

CONSTANT_Class_info {
  u1 tag;        // The value is 7
  u2 name_index; // Utf8 pointing to the fully qualified class name_ Info / / there is a hierarchical combination relationship between constants
}

• CONSTANT_Fieldref_info, CONSTANT_Methodref_info, CONSTANT_NameAndType_info: member variables, member methods, and their type descriptors

CONSTANT_Fieldref_info {
  u1 tag;                 // The value is 9
  u2 class_index;         // Category
  u2 name_and_type_index; // Field name, type descriptor
}
CONSTANT_Methodref_info {
  u1 tag;                 // The value is 10
  u2 class_index;         // Category
  u2 name_and_type_index; // Method name, signature descriptor
}
CONSTANT_NameAndType_info {
  u1 tag;              // The value is 12
  u2 name_index;       // The name of the field or method
  u2 descriptor_index; // type descriptor 
}

Only the structures of five constants are listed above. It can be seen that the hierarchical relationship between constants is described by combination

• access_flags: the access flag of the class. It has 16 bits, and each flag corresponds to one bit, such as ACC_PUBLIC corresponds to 0x0001, indicating that the class is modified by public; The other 8 marks refer to Opcodes.ACC_XXX
• this_class, super_class: the class that points to this class and the only parent Class_info Symbolic Constant
• interface_count, interfaces: multiple interface information describing the implementation of this class
• fields_count, fields: field table; Describes the number and details of class fields and member variables

field_info {
u2             access_flags;     // Access tags such as scope, static,final,volatile, etc
u2             name_index;       // Field name
u2             descriptor_index; // type descriptor 
u2             attributes_count; // Property sheet for field
attribute_info attributes[attributes_count];
}

The type descriptor simplifies the description of the data type of the field, the parameter list and return value of the method. The relationship with the type in Java is as follows:

• Basic types: Z:boolean, B:byte, C:char, S:short, I:int, F:float, D:double, J:long
• Void and reference type: V:void
• Reference type: L:, Replace. In the class name with /, and add; Delimiter, such as Ljava/lang/Object described as Object class;
• Array type: each dimension is represented by a prefix [example: the corresponding descriptor of boolean regionMatch(int, String, int, int) is (ILjava/lang/String;II)Z
• methods_count, methods: method table; completely describes the modifier, parameter list, return value and other signature information of each member method

method_info {
u2             access_flags;     // Access tag
u2             name_index;       // Method name
u2             descriptor_index; // Method Descriptor 
u2             attributes_count; // Method property sheet
attribute_info attributes[attributes_count];
}

Field table and method table can have multiple attribute tables, such as constant field table, method bytecode instruction table, method exception table, etc. attribute template:

attribute_info {
u2 attribute_name_index;   // Attribute name
u4 attribute_length;       // Attribute data length
u1 info[attribute_length]; // For other fields, the structure of each attribute is different
}

There are 20 + attributes, and only three common attributes are recorded here

• Code attribute: stores the bytecode instruction compiled by the method

Code_attribute {
  u2 attribute_name_index; // Property name, and the Utf8_info value pointed to is fixed as "Code"
  u4 attribute_length;     // Length of remaining bytes
  u2 max_stack;  // The maximum depth of the operand stack, which is the depth of the operand stack in the stack frame of this method
  u2 max_locals; // The size of the local variable table in slot variable slot, storing the hidden parameter this, argument list, catch parameter, local variable, etc
  u4 code_length;       // Total bytecode instruction length
  u1 code[code_length]; // The JVM instruction set size is 200 +, and the number of a single instruction is described by u1
  u2 exception_table_length; // The exception table describes the exception generated by each instruction interval in the method and its handler address
  {   u2 start_pc;   // An exception of type catch_type will be thrown within the scope of the [start_pc, end_pc) instruction
      u2 end_pc;   
      u2 handler_pc; // If this exception is thrown, goto is executed at the handler_pc
      u2 catch_type;
  } exception_table[exception_table_length];
  u2 attributes_count; // The Code attribute is its own attribute
  attribute_info attributes[attributes_count];
}

• LineNumberTable attribute: records the correspondence between the line number of Java source Code and the line number of bytecode. It is used to display the line number corresponding to the stack and other information when throwing exceptions. Can be a child of the Code attribute

LineNumberTable_attribute {
  u2 attribute_name_index; u4 attribute_length;
  u2 line_number_table_length;
  {   u2 start_pc;     // Start position of bytecode instruction interval
      u2 line_number;  // Corresponding source code line number
  } line_number_table[line_number_table_length];
}

• LocalVariableTable property: records the variable name of the local variable in the Java method and the corresponding relationship with the variable in the stack frame local variable table. It is used to retain the meaningful variable name of each method

LocalVariableTable_attribute {
  u2 attribute_name_index; u4 attribute_length;
  u2 local_variable_table_length;
  {   u2 start_pc; // Bytecode offset at the beginning of the local variable life cycle
      u2 length;   // Bytecode length covered by the backward lifecycle
      u2 name_index;       // Variable name
      u2 descriptor_index; // type descriptor 
      u2 index; // The slot index in the corresponding local variable table
  } local_variable_table[local_variable_table_length];
}

For other properties, refer directly to the JVM documentation

26. Example

Source code: com/cls/Structure.java

package com.cls;

public class Structure {
public static void main(String[] args) {
  System.out.println("hello world");
}
}

After javac -g:lines com/cls/Structure.java is compiled, refer to the correct result obtained by javap decompilation, od -x --endian=big Structure.class to obtain the hexadecimal representation of the content of the class file. The interpretation is as follows:

cafe babe # 1. U4 magic number, identifying class file type
0000 0034 # 2. U2, U2 version number, 52 JDK8 

# 3. Constant pool
---1---
001f # u2 constant_pool_count, 31 items (counting from 1, 0 reserved)
0a      # u1 tag，10，Methoddef_info, member method structure 
0006    # u2 index，6，Category Class_info Number in constant pool   ## java/lang/Object
0011    # u2 index，17，This method NameAndType number             ## <init>:()V

---2---
09      # 9，Fileddef_info, member variable structure
0012    # u2 index，18，Category Class_info number     ## java/lang/System
0013    # u2 index，19，This field NameAndType number    ## out:Ljava/io/PrintStream

---3---
08      # 8，String_info, string
0014    # u2 index，20，Literal number     ## hello world

---4---
0a 
0015    # 21    ## java/io/PrintStream
0016    # 22    ## println:(Ljava/lang/String;)V

---5---
07      # Class_info, fully qualified class name
0017    # u2 index，23，Literal number     ## com/cls/Structure

---6---
07      # 7，Class_info, class reference
0018    # 24    ## java/lang/Object

---7---
01      # Utf8_info, UTF8 encoded string
0006    # u2 length, 6, string length
3c 69 6e 69 74 3e # literal values     ## "<init>"

---8-16---
01 0003 282956                                          ## "()V"
01 0004 436f6465                                        ## "Code"
01 000f 4c696e654e756d6265725461626c65                  ## "LineNumberTable"
01 0004 6d61696e                                        ## "main"
01 0016 285b4c6a6176612f6c616e672f537472696e673b2956    ## "([Ljava/lang/String;)V"
01 0010 4d6574686f64506172616d6574657273                ## "MethodParameters"
01 0004 61726773                                        ## "args"
01 000a 536f7572636546696c65                            ## "SourceFile"
01 000e 5374727563747572652e6a617661                    ## "Structure.java"

---17---
0c      # 12. NameAndType, name and type descriptor
0007    # u2 index，7，Field or method name area quantity number    ## <init>
0008    # u2 index，8，Field or method structure number       ## ()V

---18---
07 0019 # 25    ## java/lang/System

---19---
0c
001a 001b   # 26:27    ## out:Ljava/io/PrintStream;

---20---
01 000b 68656c6c6f20776f726c64    ## "hello world"

---21--
07 001c # 28    ## java/io/PrintStream

---22--
0c
001d 001e   # 29:30                             ## println:(Ljava/lang/String;)V

---23-31---
01 0011 636f6d2f636c732f537472756374757265          ## "com/cls/Structure"
01 0010 6a6176612f6c616e672f4f626a656374            ## "java/lang/Object "
01 0010 6a6176 612f 6c61 6e67 2f53 7973 7465 6d     ## "java/lang/System"
01 0003 6f7574                                      ## "out"
01 0015 4c6a6176612f696f2f5072696e7453747265616d3b  ## "Ljava/io/PrintStream;"
01 0013 6a6176612f696f2f5072696e7453747265616d      ## "java/io/PrintStream"
01 0007 7072696e746c6e                              ## "println"
01 0015 284c6a6176612f6c616e672f537472696e673b2956  ## "(Ljava/lang/String;)V"

0021 # 4. u2，access_flags                           ## ACC_PUBLIC | ACC_SUPER
0005 # 5. u2, this_class,5                           ## --5.Class_info--> com/cls/Structure
0006 # 6. u2, super_class, 6                         ## --6.Class_info--> java/lang/Object 
0000 # 7. u2, interface_count, 0
0000 # 8. u2, fields_count, 0

0002 # 9. methods count, 2
  # Method 1
0001    # u2, access_flags, ACC_PUBLIC                 
0007    # u2, name_index, 7                         ## <init> 
0008    # u2, descriptor_index, 8                   ## ()V                          
0001    # u2, attribute_count, 1                             
0009        # u2, attribute_name_index, 9           ## Code attribute
0000 001d   # u4, attribute_length, 30 
0001        # u2, max_stack, 1                                
0001        # u2, max_locals, 1                            
0000 0005  # u4, code_array_length, 5                        
2a               # u1, aload_0                       ## Put the variable this in the 0th slot on the stack 
b7   0001        # u1, invokespecial                 ## Execute < init > inherited from Object
b1               # u1, return                        ## Return void
0000        # u2, exception_table_length, 0          ## exception table is empty, no exception
0001        # u2, attributes_count, 1                ## Sub attribute of Code attribute itself
000a            # 10                                    ## LineNumberTable property
0000 0006       # 6
0001            # u2, line_number_table_length, 1
0000                # u2, start_pc, 0
0003                # u2, line_number, 3
  # Method 2
0009    # access_flags                               ## ACC_PIBLIC | ACC_STATIC
000b    # name_index, 11                             ## main
000c    # descriptor_index, 12                       ## ([Ljava/lang/String;)V
0002    # attribute_count, 2
0009        # attribute_name_index, 9                ## Code
0000 0025  # attribute_length, 37
0002        # max_stack, 2 
0001        # max_locals, 1
0000 0009  # code_array_length, 9
b2   0002       # getstatic, 2                       ## Field: java/lang/System.out:Ljava/io/PrintStream; //  Load static object variables
12   03         # ldc, 3                             ## String: "hello world" / / put constant parameters on the stack
b6   0004       # invokevirtual, 4                   ## Method: java/io/PrintStream.println:(Ljava/lang/String;)V / / execute the method
b1              # return
0000        # exception_table_length, 0
0001        # attributes_count, 1
000a        # 10                                     ## LineNumberTable
0000 000a   # 10
0002            # line_number_table_length, 2
0000 0005           # 0 -> 5
0008 0006           # 8 -> 6

27. Bytecode instruction

The JVM designs an instruction set for the operand stack. Each instruction is represented by a 1-byte opcode followed by 0 or more operands. Refer to Java bytecode instruction lists for the instruction set list

• For most instructions related to data types, their opcode symbols will be prefixed with type. For example, the i prefix represents the operation int, and the remaining correspondence is b:byte, c:char, s:short, f:float, d:double, l:long, a:reference
• Because the instruction set size is limited (256), Boolean, byte, char and short will be converted to int operation

Byte codes can be roughly divided into six categories:

• Load and store instructions: load variables from the local variable table slot to the top of the operand stack, and store them in reverse

// Load slot 0, 1, 2, 3 and N to the top of the stack. T represents the type abbreviation prefix, which can take I, l, F, D and a
Tload_0, Tload_1, Tload_2, Tload_3, Tload n
// Write stack top data back to the specified slot
Tstore_0, Tstore_1, Tstore_2, Tstore_3, Tstore n
// Load constant values in different ranges to the top of the stack. Since 0 ~ 5 constants are too common, there are separate corresponding instructions, and ldc loads ordinary constants
bipush, sipush, Tconst_[0,1,2,3,4,5], aconst_null, ldc

• Operation instruction

Tadd, Tsub, Tmul, Tdiv, Trem     // Arithmetic operations: addition, subtraction, multiplication, division, remainder
Tneg, Tor, Tand, Txor            // Bit operation: inverse, or, and, XOR
dcmpg, dcmpl, fcmpg, fcmpl, lcmp // Comparison operation: suffix g is greater, and l is less than
iinc                             // Local auto increment operation, used with iload

• Cast instruction: when narrowing to type T (length n), other bits except the lower N bits will be directly discarded, which may lead to data overflow, uncertain sign, and loss of precision when converting floating-point numbers to integers

i2b // int -> byte
i2c, i2s; l2i, f2i, d2i; d2l, f2l; d2f

• Object creation and access instructions: class instances and arrays are objects. The creation and access instructions are different due to different storage structures

new                                      // Create class instance
newarray, annewarray, multianewarry      // Create basic type array, reference type array and multidimensional reference type array
getfield, putfield; getstatic, putstatic // Read / write class instance fields; Read / write static fields
Taload, Tastore; arraylength             // Read and write array elements; Calculate array length
instanceof; checkcast                    // Verify whether the object is a class instance; Perform cast

• Operand stack management instruction

pop, pop2       // Pop up stack top 1 and 2 elements
dup, dup2; swap // Copy 1 and 2 elements at the top of the stack and put them back on the stack; Swap the top two elements of the stack

• Control transfer instruction: if the judgment condition is true, jump to the specified instruction line (modify the PC point)

if_<icmpeq,icmpne;icmplt,icmple;icmpgt,icmpge;acmpe,acmpne> // Integer comparison, reference equality judgment
if<eq,lt,le,gt,ge,null,nonnull>                             // Used with other types of comparison instructions

• Method call and return instructions

invokevirtual   // Dispatch according to the actual type of the object and call the corresponding method (such as method rewriting after inheritance) 
invokespecial   // Call special methods, such as < cint > () V, < init > () V and other initialization methods, private methods and parent methods
invokestatic    // Calling a static method of a class
invokeinterface // Call interface methods (class objects that implement interfaces but are declared as interface types, call methods)
invokedynamic   // TODO
Treturn, return // Returns the specified type and void

• Exception handling instruction: athrow throws an exception, and exception is used for exception handling_ Table description
• Synchronization instruction: the synchronized object lock is implemented by monitorenter, monitorexit and the object's monitor lock

28. Class loading

29. Class loading process

1. Loading

Principle: delegate ClassLoader to read the Class binary byte stream, load it into the memory of the method area, and generate the corresponding java.lang.Class objects in the heap memory for mutual reference

2. Verification

Verify byte stream to ensure compliance with Class file format, perform semantic analysis to ensure compliance with Java syntax, and verify the legitimacy of bytecode instructions

3. Preparation

Allocate the memory of class variable (static) in the heap and initialize it to zero value. It is not yet in the initialization stage of performing the assignment of putstatic instruction, except for the static constant attribute:

public class ClassX {
final static int n = 2;          // The value of the constant is known at compile time, the assignment is completed at the preparation stage, and the value is stored in ConstantValue
final static String str = "str"; // The same is true for string static constants
}

static final java.lang.String str;
descriptor: Ljava/lang/String;
flags: ACC_STATIC, ACC_FINAL
ConstantValue: String str

4. Analysis

Replace the symbol reference (Class_info, Fieldref_info, Methodref_info) in the constant pool with a direct reference (memory address)

5. Initialization

javac will combine the static variable assignment and static statement blocks in the class from top to bottom to generate a class constructor () V, which will be executed in the initialization stage. The JVM ensures thread safety in the execution of this method; Note that there are only six case s specified by the JVM that will immediately trigger class initialization

public class ClassX {
static {
  println("main class ClassX init"); // 1. The main class of main () is always initialized first
}

public static void main(String[] args) throws Exception {
  // Class initialization is triggered for the first time
  // SubX b = new SubX();  // new object / / 2. new, getsatic, putstatic, invokestatic instructions
  // println(SuperX.a);    //  Read and write the static variable of the class, or call the static method 
  // println(SubX.c);      // 3. Child class initialization will trigger parent class initialization
  // println(SubX.a);      //     Subclasses accessing the static variables of the parent class will only trigger the initialization of the parent class
  
  // Class initialization is not triggered
  // println(SubX.b);      // 1. Static constants of access class (basic type, string literal)
  // println(SubX.class);  // 2. Access class objects
  // println(new SubX[2]); // 3. Create an array of classes
}
}

class SuperX {
static int a = 0;
static {
  println("class SuperX initiated");
}
}

class SubX extends SuperX {
final static double b = 0.1;
static boolean c = false;
static {
  println("class SubX initiated");
}
}

30. Class loader

Hierarchical relationship

Parental delegation mechanism

• Principle: when a class loader receives a request to load a class, it will first delegate the upper parent class loader to load it layer by layer. When the parent class loader can't load this class layer by layer, the class loader will try to load it by itself; This model ensures that java.lang.Object classes, such as those in rt.jar, must be loaded by the Bootstrap class loader no matter what kind of loader at the bottom. This is the only one in the JVM to ensure consistency
• realization

// java/lang/ClassLoader
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
    synchronized (getClassLoadingLock(name)) {
        // 1. First check whether your loader has loaded this class
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            long t0 = System.nanoTime();
            try {
                if (parent != null) {
                    // 2. The upper layer is delegated to the upper layer to load
                    c = parent.loadClass(name, false);
                } else {
                    // 3. If there is no superior, it is delegated to Bootstrap to load
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
                // class does not exist
            }

            if (c == null) {
                // 4. Find classes in your classpath. The user-defined ClassLoader has customized the search rules
                long t1 = System.nanoTime();
                c = findClass(name);
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

31. Bytecode execution engine

32. Runtime stack frame structure

public static void main(String[] args) {
int a = 1008611;
int b = ++a;
}

Corresponding runtime stack frame structure:

• Local variable table: the size is determined at the compile time. It is used to store arguments and local variables. The minimum unit is the variable slot with the size of 32 bit s
• Long and double types are divided into two slot s and read and write at the same time (single thread operation, wireless path security issues)
• When a method is called by a class object, slot 0 is fixed as the reference of the current object, that is, the implicit argument of this
• The variable slot has reuse optimization. When the pc instruction exceeds the scope of the variable in a slot, the slot will be reused by other variables

public static void main(String[] args) {
  {
      byte[] buf = new byte[10 * 1024 * 1024];
  }
  System.gc();  // buf is also in slot 0 of the local variable table and cannot be recycled as a GC Root
  // int v = 0; //  Variable V reuses slot 0 and gc takes effect
  // System.gc(); 

• Operand stack: the maximum depth is determined at compile time, and bytecode instructions are executed in combination with local variable table by entering, executing and exiting the stack
• Return address: when a return family instruction is encountered, the normal call is completed. When an exception occurs, but there is no corresponding handler in the exception table, the exception call is completed; After exiting the upper layer method normally, if there is a return value, it will be pushed into the stack, and the program counter will be restored to the next instruction of the method call instruction

33. Method call

34. Virtual method and non virtual method

Non virtual method: a method known at compile time (uniquely determined before the program runs) and immutable at run time. In the class loading stage, the symbolic reference of the method will be resolved to a direct reference. There are 5 types:

• Static method (uniquely associated with class): invokestatic call
• Private method (not accessible externally), constructor method, parent method: invokespecial call
• final method (cannot be inherited): called by invokevirtual (historical reason)

public class StaticResolution {
 public static void doFunc() {
  System.out.println("do func...");
 }
 public static void main(String[] args) {
  StaticResolution.doFunc();
 }
}

stack=0, locals=1, args_size=1    // The calling version of the static method stores the bytecode parameters in the form of constants at compile time
0: invokestatic  #5           // Method doFunc:()V
  3: return

Virtual method: the directly referenced method needs to be dynamically determined at runtime and called by invokevirtual and invokeinterface

35. Static dispatch and dynamic dispatch

Background: methods can be overloaded (different parameter types or numbers) and overridden (overridden after subclass inheritance)

Dispatch: an object can be declared as a class, parent class, implemented interface and other types. When an object is used as an argument or calls a method, the version of the method to be called can be determined according to its static type or actual type, and then its direct reference can be determined. This process is the dispatch of methods

2 types of reference variable

• Static type: the declared type of a variable. It will not change. It can be known at compile time
• Actual type: the object pointed to by the variable can be replaced and may be modified at run time

Static Dispatch

• Principle: when a method is overloaded, it depends on the static type of the parameter to determine which overloaded version of the method to use
• Features: in the compilation stage, javac determines the overloaded version of the type "with the highest matching degree" as the parameter of invokevirtual

public class StaticDispatch {
 static abstract class Human {}
 static class Man extends Human {}
 static class Woman extends Human { }

 public void f(Human human) {System.out.println("f(Human)");}
 public void f(Man man) {System.out.println("f(Man)");}
 public void f(Woman woman) {System.out.println("f(Woman)");}

 public static void main(String[] args) {
  Human man = new Man();     // Static types are Human
  Human woman = new Woman(); // The actual types are man and woman
  StaticDispatch sd = new StaticDispatch();
  sd.f(man);   // f(Human) // invokevirtual #13 // Method f:(Lcom/ch08/StaticDispatch$Human;)V
  sd.f(woman); // f(Human) / / the overloaded version is determined at the compile time and written into the bytecode
 }
}

Dynamic dispatch

• Principle: when overriding a method, it depends on the actual type of the Receiver object to determine which class version of the method to use
• Features: when it occurs at runtime, it depends on the invokevirtual instruction to determine the version of the calling method, so as to realize polymorphism. The parsing process is

Note: class method lookup is a high-frequency operation. The JVM will create a virtual method table vtable for the class in the method area to realize fast method lookup

public class DynamicDispatch {
static abstract class Human {
    protected abstract void f();
}

static class Man extends Human {
    @Override
    protected void f() {
        System.out.println("Man f()");
    }
}

static class Woman extends Human {
    @Override
    protected void f() {
        System.out.println("Woman f()");
    }
}

public static void main(String[] args) {
    Human man = new Man(); // Although static types are Human
    Human woman = new Woman();
    man.f();   // Man f()   // invokevirtual #6 // Method com/ch08/DynamicDispatch$Human.f:()V
    woman.f(); // Woman f() / / although the parameters of bytecode instructions are symbolic references of statically typed methods
    man = new Woman();
    man.f(); // Woman f() / / however, invokevirtual will resolve to the direct reference of the actual class at runtime according to the actual type of Receiver
}
}

Note that the field read / write instructions getfield and putfield of the class do not have the dynamic dispatch mechanism of invokevirtual, that is, the fields with the same name of the subclass will directly overwrite the fields of the parent class. Example:

public class FieldHasNoPolymorphic {
static class Father {
    public int money = 1;
    public Father() {
        money = 2;
        showMoney();
    }
    public void showMoney() { System.out.println("Father, money = " + money); }
}

static class Son extends Father {
    public int money = 3; // The subclass field is assigned a zero value in the preparation phase of class loading
    public Son() { // The first line of subclass constructor is hidden by default, and super() is called
        money = 4;
        showMoney();
    }
    public void showMoney() { System.out.println("Son, money = " + money); }
}

public static void main(String[] args) {
    Father guy = new Son(); 
    System.out.println("guy, money = " + guy.money);
}
}

// Son, money = 0 / / the father class constructor executes Son::showMoney() dynamically
// Son, money = 4 / / access the latest and own money field in the son class constructor
// guy, money = 2 / / there is no dynamic allocation for reading and writing fields. Whoever the static type is, the field will be accessed

36. Single dispatch and multiple dispatch

The Receiver of the method and the parameters of the method are the quantities of the method. Selecting the target method according to one quantity is called single dispatch. Multiple quantities are required to determine the method, which is called multiple dispatch

• The static dispatch mechanism allows the compiler to select the target method with the highest parameter matching for multiple overloaded methods at the compilation stage
• When the dynamic dispatch mechanism is running, it relies on the actual type of Receiver and cooperates with invokevirtual to locate the unique instance method as the target method

To sum up, Java is a static multi dispatch and dynamic single dispatch language

Note: Chapters 10 and 11 talk about the front and back-end compilation of Java, and learn the bytecode implementation of common syntax sugar such as automatic packing. The rest will be learned together with dragon book when you have time; The contents of chapters 12 and 13 are highly coincident with Java Concurrency In Practice and other books, which will not be repeated here

37. Summary

After studying the deep understanding of JVM 3ed, I have preliminarily mastered the partition model of JVM memory area, the theory of GC algorithm and the principle of common recyclers, the interpretation of data items in Class file structure, Class loading process, method execution and dispatch, and gained a lot. However, most of them are theories. If you have the opportunity, you still need to study the source code implementation of openjdk: (yinzige.com/2020/03/08/understanding-jvm-3ed)/