Java Class Loading and Object Creation Process
This article explains the Java Virtual Machine's class loading mechanism—including loading, verification, preparation, resolution, and initialization—and details how objects are created in memory, covering heap allocation, default values, instance initialization, and reference handling.
When a Java program creates a new object, the JVM first checks whether the class has been loaded; if not, it loads and initializes the class using the fully qualified name.
The class loading process follows the parent‑delegation model, where a ClassLoader delegates loading requests up the hierarchy until the bootstrap loader attempts to load the class, ensuring global uniqueness of classes.
The loading phase reads the class's binary byte stream into the method area and creates a java.lang.Class object.
Verification includes format verification (conformance to the class file format), semantic verification (e.g., final class constraints, method signatures), and operation verification (correct use of the operand stack and constant pool references).
Preparation allocates memory for static variables and assigns default values; final static constants receive their explicit values.
Resolution converts symbolic references in the constant pool to direct references (pointers or offsets) for fields, methods, and classes.
Initialization (the final linking step) executes static variable assignments and static blocks, with the JVM ensuring that only one thread performs initialization while others wait.
Object creation then proceeds: memory for the instance (including inherited fields) is allocated on the heap, default values are assigned to instance variables, instance initialization code runs (parent class first, then child, executing instance blocks before constructors), and a reference to the new object is stored in a stack variable.
Notes: each subclass object holds a reference to its superclass, accessible via super internally; static blocks are invoked only by the JVM; deep inheritance can affect method call performance, which the JVM mitigates using virtual method tables (v‑tables) that store a single entry per method per class.
Ultimately, the method area retains class metadata, including static variables, initialization code, instance variable definitions, instance initialization code, and method definitions, along with references to superclass information.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Java Captain
Focused on Java technologies: SSM, the Spring ecosystem, microservices, MySQL, MyCat, clustering, distributed systems, middleware, Linux, networking, multithreading; occasionally covers DevOps tools like Jenkins, Nexus, Docker, ELK; shares practical tech insights and is dedicated to full‑stack Java development.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
