GC执行优先级咨询：局部变量与对象的回收顺序

Great question—let's break this down clearly, since garbage collection (GC) behavior can feel a bit black-box if you don't dig into the implementation details. I'll cover both the priority/order of GC execution and your specific question about local variables vs. eligible objects.

First, it's important to note that exact behavior depends on the GC algorithm (e.g., Parallel GC, G1, ZGC) and the runtime environment (like the JVM for Java), but there are universal patterns to follow:

Core Foundation: Marking Unreachable Objects #

Before any prioritization happens, all GC implementations first run a mark phase to identify every object in the heap that's no longer reachable (i.e., no reference chain connects it to a GC Root—things like active stack frame variables, static class references, or JNI global references). This is the baseline for what gets collected.

Priority Tied to Generational Memory (Most Modern GC) #

Nearly all production-grade GCs use a generational memory model, which prioritizes collection based on how long objects have existed:

• Young Generation (Eden + Survivor Spaces)：Highest priority. Most objects die almost immediately after creation, so collecting this space is fast and efficient. Minor GCs (which target only the young gen) trigger frequently whenever the Eden space fills up.
• Old Generation (Tenured Space)：Lower priority than the young gen. Major GCs (or Full GCs, which include the old gen) only run when:
  • Minor GC can't promote surviving objects to the old gen due to insufficient space
  • The old gen itself reaches a memory usage threshold
    These take longer because old-gen objects have a much higher survival rate.
• Metaspace (or PermGen in older JVMs)：Lowest priority. This space stores class metadata, and collection only happens when classes are unloaded (e.g., when their class loader is reclaimed) or when Metaspace runs out of memory.

Priority Based on GC Triggers #

The reason for triggering GC also affects priority:

• Automatic triggers (like young gen full) have high priority—they'll pause the application (briefly, for modern GCs) to free up critical memory.
• Explicit calls like System.gc() have very low priority—the runtime can ignore this request entirely (and usually does, unless configured otherwise).

Let's clarify a key misunderstanding here: local variables themselves don't get collected by GC. Here's why:

• Local variables (references to objects, or primitive values) live on the thread's stack, not the heap. When a method finishes executing, its stack frame is popped off the stack, and the memory used by local variables is immediately reclaimed by the thread's stack manager—this is not GC's job, and it happens instantly.
• The objects that local variables point to live in the heap. Once the local variable goes out of scope (and no other references to the object exist), the object becomes unreachable. It will then be marked in the next GC mark phase and reclaimed during the cleanup phase (usually in the next Minor GC if it's in the young gen).

To put this in context, take this simple code example:

public void processData() {
    User user = new User(); // 'user' is a stack-local reference; the User object lives in the heap
    // Use the user object here
} // Method ends: stack frame is popped, 'user' stack memory is freed immediately
  // The User object is now unreachable, and will be collected in the next Minor GC

So to directly answer your question: The local variable's stack memory is reclaimed before the heap object is touched by GC. If you're asking about heap objects that were referenced by local variables vs. other unreachable heap objects—they're all marked in the same phase and collected based on their generation priority, not their former reference source.

内容的提问来源于stack exchange，提问作者mittapalli hareesh