Core Java Fundamentals: JVM, Compilation, Memory, and Types

Core Java Fundamentals

This guide covers the runtime behavior and language foundation every backend engineer needs to understand when building production services. We go beyond syntax trivia into the JVM internals that determine latency, throughput, and reliability under load.

1. The Java Platform: JDK, JRE, JVM

At the center of Java is the JVM — the abstraction layer that decouples your code from the operating system. Understanding the three layers of the platform is essential for deployment, debugging, and performance tuning.

Key distinctions

2. Compilation Pipeline

Java's compilation model is a two-stage process: source code is compiled to bytecode ahead of time, then the JVM further compiles hot paths to native code at runtime. This hybrid approach gives you portability with near-native performance.

The pipeline in detail

• Source compilation (javac): Parses Java source, performs type checking, and emits .class files containing bytecode. This stage does no optimization — it is purely a syntactic and type-level transformation.
• Class loading: The JVM loads classes lazily (on first reference). This is why startup time is proportional to the number of classes used, not the number on the classpath.
• Bytecode verification: Ensures bytecode is well-formed — no stack overflow/underflow, no illegal type casts, no unsafe jumps. This is a critical security layer.
• Interpretation: Freshly loaded methods start in interpreted mode. The JVM gathers profiling data (method call counts, branch patterns) during this phase.
• JIT compilation: The JVM first interprets bytecode. Frequently executed ("hot") methods are compiled into native machine code by the JIT compiler. With HotSpot's default tiered compilation, methods are first compiled by C1 for fast execution and profiling, then recompiled by C2 for maximum optimization once sufficient runtime profiling data has been collected. The exact thresholds are JVM-version dependent and are based on both invocation counts and loop execution counts.

Tiered compilation explained

3. Bytecode and Execution Model

Bytecode is a stack-based intermediate representation. Each method invocation creates a stack frame containing:

How a simple expression executes

Consider the expression int c = a + b; after compilation to bytecode:

// Java source
int a = 10;
int b = 20;
int c = a + b;

// Corresponding bytecode (mnemonic)
ICONST_10    // Push int constant 10 onto operand stack
ISTORE_1     // Pop top value → local variable 1 (a)
BIPUSH 20    // Push int constant 20 onto stack
ISTORE_2     // Pop top value → local variable 2 (b)
ILOAD_1      // Push local variable 1 (a) onto stack
ILOAD_2      // Push local variable 2 (b) onto stack
IADD         // Pop two ints, add them, push result
ISTORE_3     // Pop result → local variable 3 (c)

4. JVM Memory Model

The JVM divides memory into several distinct regions, each with different performance characteristics and GC behavior.

Region characteristics

Common memory configuration flags

# Heap sizing (always set both -Xms and -Xmx to avoid resize pauses)
-Xms4g -Xmx4g
 
# Young generation sizing
-Xmn2g
-XX:NewRatio=2          # Old : Young = 2 : 1
-XX:SurvivorRatio=8     # Eden : Survivor = 8 : 1 (default)
 
# Metaspace
-XX:MaxMetaspaceSize=256m
 
# Stack size per thread
-Xss512k
 
# Direct memory (for NIO)
-XX:MaxDirectMemorySize=512m

5. Garbage Collection

Garbage collection is the automatic reclamation of heap memory. The JVM uses a generational hypothesis: most objects die young.

GC algorithms compared

GC tuning by workload type

Batch / data processing (high throughput):

-XX:+UseParallelGC
-XX:ParallelGCThreads=8
-Xms8g -Xmx8g

Low-latency web services (sub-10ms p99):

-XX:+UseZGC
-XX:ZAllocationSpikeTolerance=2.0
-Xms8g -Xmx8g
-XX:ConcGCThreads=4

General purpose services (default recommended):

-XX:+UseG1GC
-XX:MaxGCPauseMillis=100
-XX:G1HeapRegionSize=4m
-Xms4g -Xmx4g

Practical guidance

• Monitor GC logs: -Xlog:gc*:file=gc.log:tags,time,uptime,level (Java 9+ unified logging)
• Watch for promotion failures: -XX:+PrintTenuringDistribution helps tune survivor space sizes
• Avoid large young gen: Pauses scale with young gen size. 2-4 GB is typical for most services
• Use jstat live: jstat -gcutil <pid> 1s shows GC utilization per second

6. Class Loading and Initialization

Class loading is a three-phase process that happens lazily — the JVM only loads a class when it is first referenced.

Class loader hierarchy

The JVM uses a delegation model for class loaders:

When initialization happens

A class is initialized (static blocks execute) only when:

1. A new instance is created
2. A static method is invoked
3. A static field is accessed
4. Class.forName() is called
5. It is the initial class of a JVM launch

public class ExpensiveInit {
    // BAD: runs during class loading, delays startup
    static {
        DatabasePool.init("jdbc:...", 50);
    }
 
    // GOOD: initialized on first use
    private static class LazyPool {
        static final DatabasePool INSTANCE = DatabasePool.init("jdbc:...", 50);
    }
 
    public static DatabasePool pool() {
        return LazyPool.INSTANCE;
    }
}

7. Primitive vs Reference Types

Java's type system is split into two worlds. Understanding the distinction is critical for writing high-performance backend code.

Memory and performance comparison

Autoboxing pitfalls

// Hidden allocation: each addition creates a new Long object
Long sum = 0L;
for (long i = 0; i < 1_000_000; i++) {
    sum += i;  // ← unbox + add + box = 1M allocations!
}
 
// Better: use primitive in loop, box only at the end
long sum = 0L;
for (long i = 0; i < 1_000_000; i++) {
    sum += i;
}
Long result = sum;  // single allocation

Equality pitfalls with wrappers

Integer a = 127;
Integer b = 127;
System.out.println(a == b);      // true (cached: -128 to 127)
 
Integer c = 200;
Integer d = 200;
System.out.println(c == d);      // false (not cached!)
 
// Always use .equals() or unbox
System.out.println(c.equals(d)); // true
System.out.println((int)c == (int)d); // true

8. equals(), hashCode(), and Object Contracts

The equals() and hashCode() methods form the backbone of all hash-based collections. Getting them wrong is one of the most common sources of production bugs.

The contract

public final class UserId {
    private final String value;
 
    public UserId(String value) {
        this.value = Objects.requireNonNull(value);
    }
 
    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof UserId other)) return false;
        return value.equals(other.value);
    }
 
    @Override
    public int hashCode() {
        return value.hashCode();  // same fields as equals()
    }
}

Production patterns for equals/hashCode

Common bug: mutable fields in hashCode

// BAD: hashCode changes when setName() is called
public class BadEntity {
    private String name;
 
    @Override
    public int hashCode() { return name.hashCode(); }
}
 
// Usage
var map = new HashMap<BadEntity, String>();
var e = new BadEntity();
e.setName("Alice");
map.put(e, "value");
e.setName("Bob");
map.get(e); // → null (wrong bucket!)

9. final, finally, and finalize

These three keywords sound alike but serve completely different purposes.

final

public final class ImmutableConfig {       // cannot be subclassed
    private final int maxConnections;       // must be set once, never reassigned
 
    public ImmutableConfig(int maxConnections) {
        this.maxConnections = maxConnections;
    }
 
    public final int getMaxConnections() {  // cannot be overridden
        return maxConnections;
    }
}

finally

// Prefer try-with-resources (Java 7+)
try (Connection conn = dataSource.getConnection();
     PreparedStatement stmt = conn.prepareStatement(sql)) {
    return stmt.executeQuery();
}
// Resources are auto-closed, no finally needed
 
// Use finally only for non-Closeable cleanup
CountDownLatch latch = new CountDownLatch(1);
try {
    processAsync(latch);
} finally {
    latch.countDown();  // ensures thread unblocks even on exception
}

finalize()

// DEPRECATED — never use in production
@Override
@Deprecated(since = "9")
protected void finalize() throws Throwable {
    // Runs unpredictably, if at all
    // Use Cleaner or try-with-resources instead
}

10. Production Observations

Java fundamentals are not just theory — they shape how backend services behave under real traffic.

Performance decision tree

Key takeaways

• JVM startup and class loading affect deployment times, especially in autoscaling environments
• Heap layout and GC choices determine your latency profile — benchmark with your actual workload
• Primitive vs reference decisions matter in high-throughput code; use long not Long in hot loops
• equals()/hashCode() correctness is one of the most common backend bugs in caches, session stores, and collections
• final is a design tool, not an optimization hint — modern JIT compilers are not constrained by final for optimization
• Profile before tuning: use async-profiler or JFR (Java Flight Recorder) to identify real bottlenecks before optimizing

Essential JVM flags for production

# Always set these
-Xms4g -Xmx4g                    # Fixed heap (no resize)
-XX:+UseG1GC                     # Modern GC
-XX:MaxGCPauseMillis=100         # Pause target
-Xlog:gc*:file=gc.log:tags,time,uptime,level   # GC logging
-XX:+ExitOnOutOfMemoryError      # Fail fast on OOM
-XX:+HeapDumpOnOutOfMemoryError  # Capture heap dump
-XX:HeapDumpPath=/var/log/app/   # Dump location
-Djava.security.egd=file:/dev/urandom  # Faster secure random

Interview Questions

• What is the difference between JDK, JRE, and JVM?
• How does Java compile source code to executable form? Explain the role of javac, bytecode, and JIT compilation.
• What are the main JVM memory regions, and how do they differ?
• Why does the JVM use generational garbage collection? Describe the lifecycle of an object from Eden to Old Gen.
• What happens during class loading and initialization? Describe the three phases.
• How do primitive types differ from reference types? When does autoboxing hurt performance?
• Why must equals() and hashCode() be overridden together? What happens if only one is overridden?
• What is the difference between final, finally, and finalize()?
• How does tiered compilation work? What are the four tiers?
• What GC algorithm would you choose for a low-latency payment service? Why?
• What happens if you use mutable fields in hashCode()? How would you debug it?
• How would you reduce JVM cold start time in a serverless environment?