What is escape analysis and stack allocation in the JVM?

Three escape states

• NoEscape — object stays local to one method: stack allocation or scalar replacement possible.
• ArgEscape — object passed as argument to a method that doesn't let it escape further: synchronisation on it can be eliminated.
• GlobalEscape — object reachable from a static field or returned/stored beyond the current method: must be heap-allocated normally.

// Example 1: loop-local point — likely stack-allocated by JIT
record Point(double x, double y) {}

void computeCentroid(double[] xs, double[] ys) {
    double sumX = 0, sumY = 0;
    for (int i = 0; i < xs.length; i++) {
        // Point does not escape this loop body (not stored anywhere)
        var p = new Point(xs[i], ys[i]);  // JIT may scalar-replace this
        sumX += p.x();
        sumY += p.y();
    }
}

import java.util.ArrayList;
import java.util.List;

// Example 2: object escapes — heap allocation required
List<Point> points = new ArrayList<>();
void processAll(double[] xs, double[] ys) {
    for (int i = 0; i < xs.length; i++) {
        var p = new Point(xs[i], ys[i]);
        points.add(p);   // p escapes into the list — heap allocated
    }
}

Lock elision (bonus optimisation enabled by escape analysis)

// StringBuffer is synchronized. If sb doesn't escape, JIT removes all locks.
String buildKey(String prefix, int id) {
    var sb = new StringBuffer();   // local, doesn't escape
    sb.append(prefix).append(id);  // JIT elides synchronisation entirely
    return sb.toString();          // string result escapes, not sb
}

Practical impact for QA automation

• Short-lived helper objects (request builders, response wrappers) used only within a test method may be stack-allocated, reducing GC pauses in high-frequency test loops.
• Avoid storing test helpers in instance fields unless necessary — it forces heap allocation and increases GC pressure.
• Enabled by default since Java 6u23 (-XX:+DoEscapeAnalysis).