What destroys a local variable in java?

Question

I suspect that the local variables of the method live only as the method executes. In addition, the GC starts when the Eden or Long-generation blocks overflow (low / main GC), etc. So, what if the Eden method is not crowded at the end of the body, so there is no need for a GC trigger. Despite the fact that the main / minor GC does not start, we will destroy the entire local variable. How it's done?

Answer 1

The garbage collector - the Reaper, as it is sometimes called, works according to its own schedule and collects objects that are not true. Local variables, of course, cannot be specified after the method exits, because they go beyond the scope, so they are dead in your program, but they still exist on the heap until the GC finishes.

Under normal circumstances (and most abnormal ones) you do not need to tell Reaper when he is doing his job. He will come, quietly, when necessary, and take away those things that are no longer needed. This is one of the main advantages of working in a high-level language: it is safe to assume that you never need to think about such things as controlling the shutdown of dead objects. You can simply throw them over your shoulder and know that they will never bother you. I believe that there are some high-performance, high-demand applications that need to be bothered with GC, but an optimization that should always be considered premature unless you have really good evidence to the contrary.

Answer 2

Method local variables (or simply “local variables,” as they are usually called) are distributed across each stack of threads. Variables themselves are not garbage collected. They are automatically restored when the method call ends (usually or abnormally).

Objects are another matter. Objects (including arrays) are usually ¹ allocated on the heap, and they are subject to garbage collection.

---

What about an object (or array) that is allocated by a method and assigned to a local variable?

First of all, the local variable contains a reference to the object. The object is stored on the heap (see above).

When the garbage collector starts (and you usually don’t know when it will be!), It will check for any existing local variables for method calls that are still in process. These variables contain references to objects, these objects are added to the list of objects that need to be saved ... and they are checked for links to other objects, etc.

---

So, in the end, local variables are automatically destroyed at the end of the method call, but the objects that these variables belong to will continue to exist until the GC (in the end) finds out that they are not available.

---

^{1 - Recent JIT compilers Hotspot JITs have an additional optimization called "escape analysis", which is used to search for cases when objects created by a method call can be allocated on the thread stack. This is not enabled by default. If an object is allocated on the stack, it will be restored after the method call is completed. GC is not involved.}

^{2 - You said: "The GC is triggered when the Eden or Long-generation (minor / major GC) blocks are full, etc." This is not necessarily the case. Some of the low pause collectors run before filling in the corresponding spaces. However, this does not change any of the above.}

Answer 3

The Java virtual machine uses a linear stack to control (store / access) local variables and method parameters, so it simply sets the stack pointer to a point where none of the local residents and parameters has been declared and moved. No need to use GC