Talk about high concurrency (iv) Presentation model and run-time memory representation of Java objects

Before you continue to understand the Java memory model, it is a good idea to understand the memory representation of Java objects first. In the Internet search for the Java object Memory representation, said is not enough system and in place. Before looking at the "hotspot Combat" a book, how the JVM represents the object this piece said very well, recommended. It is difficult to understand the Java memory model in place without understanding the various memory regions of the JVM runtime and the process of Java invocation. This is a relatively large topic, will be written in succession some JVM related. Here, the memory of the Java object is taken out to chat, the content is based on the hotspot virtual machine.

The hotspot is written in C + +, so its definition of Java object Representation model is also based on C + + implementation.

The presentation model for Java objects is called the "oop-klass" binary model , which consists of two parts:

1. OOP, which is the ordinary object point, a generic pointer. To be honest, the name is quite difficult to understand. The truth is that it's an instance of an object.

2. Klass, the Java Class C + + peer, used to describe Java classes, including metadata and method information , etc.

A Java object consists of two parts, data and methods, corresponding to OOP and Klass. The simplest way to understand this is to let yourself develop a new set of languages in the Java language, how do you represent the object of the new language? It must be a similar idea, a module is a Java class to implement the part representing the data, a module is to implement the Java class to represent the method and metadata part.

When a class is loaded by the JVM runtime, a Instanceklass object is created inside the JVM that represents the runtime metadata for this class. When creating a Java object of this class, a instanceoop is created within the JVM to represent the Java object. The students familiar with the JVM can understand that the Instanceklass object is placed in the method area, Instanceoop is placed in the heap, and the Instanceoop reference is placed on the JVM stack.

The JVM is run on a stack, and when a thread invokes a method of an object, it creates a stack frame (frame) data structure at the top of the stack of its JVM stack, which is used to hold local variables of the method, operand stacks, dynamic joins, and method return values. when a method is called, the parameters passed in by the method are saved in the local variable table, which is equivalent to creating a private copy of the thread.

Understanding this is key to understanding the Java memory model. the Java memory model is described in this way: Each thread has a workspace cache to hold temporary calculations, and maintains a common memory area to hold shared objects.

The area of memory shared here is specified as a heap (also including a run-time pool in the method area), and each thread's private workspace cache refers to the local variable area inside the stack frame of the JVM stack. This area is thread-private, so if a shared variable is used by a thread, if there is no synchronization, it is not visible to other threads at some point because it is indeterminate when the heap is written back from the JVM stack.

The Java object created in the heap actually contains only data information, and it contains three parts:

1. Object header, also known as Mark Word

2. Metadata pointers, which can be understood as class object pointers, point to Instanceklass instances of the method area

3. Instance data

If it is a data object, there is one more part, that is, the array length.

Object headers primarily store object runtime logging information, such as Hashcode, GC generational age, lock status flag, bias thread ID, bias timestamp, and so on. The length of the object header is the same as that of the JVM, such as the 32-bit JVM object header is 32 bits, and the 64-bit JVM object header is 64 bits.

As you can see here, the so-called lock on an object is actually setting some bits of the object's head. When other threads see the state of the object as a locking state, they wait for the lock to be released.

The Instanceklass object in the method area is equivalent to the run-time object created after class loading, which contains metadata for running a constant pool, field, method, and so on, when invoking an object's method, as shown in the figure above, Method metadata that is actually anchored to the Instanceklass object of the method area.

Let's use Hsdb to see what Instanceklass and Instanceoop are like at runtime using an example. In the method area

Create a person class with the name, age, and sex instance properties, with a Sayhi method

Package Main;public class Person {private String name;    private int age;        Private Boolean sex;    public void Sayhi () {System.out.println ("Say hi from Iter_zc");        } public static void Main (string[] args) {person p = new person ();                P.sayhi ();        try {thread.sleep (500000);        } catch (Interruptedexception e) {e.printstacktrace (); }    }}

The HSDB is a built-in GUI debugging tool with SA that integrates a variety of JVM monitoring tools that can be used to drill down into the internal state of the JVM.

Start Hsdb:

JAVA-CP ${java_home}/lib/sa-jdi.jar Sun.jvm.hotspot.HSDB

Run person, use JPS to view process ID

Using the HSDB attach person process

Attach success See each sub-process in the 21461 process

Find the runtime instance of the person corresponding to Instanceklass in class browser

In the Inspector view 0x000000077fc82328 This object instance, we can see Instanceklass fields, methods, run constant pool, parent class, sibling class and other meta-data information

Find the Main.person object inside the object histogram

View Main. Run-time instances of person oop

_mark is the object header, followed by the instance data information. HSDB no class object pointer displayed

Talk about high concurrency (iv) Presentation model and run-time memory representation of Java objects