Develop Reference

Can Java GC local variables that are in scope but no longer used? [duplicate]

I've been looking into a bug in my code that seems to be caused by some "ugly" finalizer code. The code looks roughly like this
public class A {
public B b = new B();
#Override public void finalize() {
b.close();
}
}
public class B {
public void close() { /* do clean up our resources. */ }
public void doSomething() { /* do something that requires us not to be closed */ }
}
void main() {
A a = new A();
B b = a.b;
for(/*lots of time*/) {
b.doSomething();
}
}
What I think is happening is that a is getting detected as having no references after the second line of main() and getting GC'd and finalized by the finalizer thread - while the for loop is still happening, using b while a is still "in scope".
Is this plausable? Is java allowed to GC an object before it goes out of scope?
Note: I know that doing anything inside finalizers is bad. This is code I've inherited and am intending to fix - the question is whether I'm understanding the root issue correctly. If this is impossible then something more subtle must be the root of my bug.

Can Java finalize an object when it is still in scope?
Yes.
However, I'm being pedantic here. Scope is a language concept that determines the validity of names. Whether an object can be garbage collected (and therefore finalized) depends on whether it is reachable.
The answer from ajb almost had it (+1) by citing a significant passage from the JLS. However I don't think it's directly applicable to the situation. JLS §12.6.1 also says:
A reachable object is any object that can be accessed in any potential continuing computation from any live thread.
Now consider this applied to the following code:
class A {
#Override protected void finalize() {
System.out.println(this + " was finalized!");
}
public static void main(String[] args) {
A a = new A();
System.out.println("Created " + a);
for (int i = 0; i < 1_000_000_000; i++) {
if (i % 1_000_000 == 0)
System.gc();
}
// System.out.println(a + " was still alive.");
}
}
On JDK 8 GA, this will finalize a every single time. If you uncomment the println at the end, a will never be finalized.
With the println commented out, one can see how the reachability rule applies. When the code reaches the loop, there is no possible way that the thread can have any access to a. Thus it is unreachable and is therefore subject to finalization and garbage collection.
Note that the name a is still in scope because one can use a anywhere within the enclosing block -- in this case the main method body -- from its declaration to the end of the block. The exact scope rules are covered in JLS §6.3. But really, as you can see, scope has nothing to do with reachability or garbage collection.
To prevent the object from being garbage collected, you can store a reference to it in a static field, or if you don't want to do that, you can keep it reachable by using it later on in the same method after the time-consuming loop. It should be sufficient to call an innocuous method like toString on it.

JLS §12.6.1:
Optimizing transformations of a program can be designed that reduce the number of objects that are reachable to be less than those which would naively be considered reachable. For example, a Java compiler or code generator may choose to set a variable or parameter that will no longer be used to null to cause the storage for such an object to be potentially reclaimable sooner.
So yes, I think it's allowable for a compiler to add hidden code to set a to null, thus allowing it to be garbage-collected. If this is what's happening, you may not be able to tell from the bytecode (see #user2357112's comment).
Possible (ugly) workaround: Add public static boolean alwaysFalse = false; to the main class or some other classes, and then at the end of main(), add if (alwaysFalse) System.out.println(a); or something else that references a. I don't think an optimizer can ever determine with certainty that alwaysFalse is never set (since some class could always use reflection to set it); therefore, it won't be able to tell that a is no longer needed. At the least, this kind of "workaround" could be used to determine whether this is indeed the problem.

Java - Can objects which are executing methods be garbage-collected?

In Java, I've done things like the following without thinking much about it:
public class Main {
public void run() {
// ...
}
public static void main(String[] args) {
new Main().run();
}
}
However, recently I've become unsure as to whether doing that is safe. After all, there is no reference to the Main object after it's created (well, there is the this reference, but does that count?), so it looks like there's a danger that the garbage collector might delete the object while it's in the middle of executing something. So perhaps the main method should look like this:
public static void main(String[] args) {
Main m = new Main();
m.run();
}
Now, I'm pretty sure that the first version works and I've never had any problems with it, but I'd like to know if it's safe to do in all cases (not only in a specific JVM, but preferably according to what the language specification says about such cases).

If an object method is being executed, it means someone is in possession of that reference. So no, an object can't be GC'd while a method is being executed.

For the most part garbage collection is transparent. It's there to remove the unnecessary complication of manual memory management. So, it will appear not to be collected, but what actually happens is more subtle.
Trivially, a compiler may completely elide the construction of the object. (By compiler, I mean a lower level compiler than javac. The bytecodes will be a literal transliteration of the source.) More obscurely, garbage collection typically runs in separate threads and actually remove the unaccessed object as a method on it is being run.
How can this be observed? The usual suspect in a finaliser. It may run concurrently with a method running on the object. Typically you would get around this problem with synchronized blocks in both the finaliser and the normal methods, which introduces the necessary happens-before relationship.

m is just a variable which has reference stored. This will be used by programmer to use the same object further to write logic on same object.
While execution, program will be converted to OP-CODES / INSTRUCTIONS .
These INSTRUCTION will have the reference to object(it is a memory location after all).
In case m is present, location of object will be accessed via INDIRECT REFERENCE.
If m is absent, the reference is DIRECT.
So here, object is being used by CPU registers, irrespective of use of reference variable.
This will be available till the flow of execution is in scope of main() function.
Further, as per GC process, GC only removes objects from memory, once GC is sure that the object will not be used any further.
Every object is given chance to survive a number of times(depends on situation and algorithm). Once the number of chances are over, then only object is garbage collected.
In simpler words, objects which were used recently, will be given chance to stay in memory.
Old objects will be removed from memory.
So given your code:
public class Main {
public void run() {
// ...
}
public static void main(String[] args) {
new Main().run();
}
}
the object will not be garbage collected.
Also, for examples, try to look at anonymous class examples. Or examples from event handling in AWT / SWING.
There, you will find a lot of usage like this.

The accepted answer is not correct. Whether the object can be GCed or not depends on if your public void run() {// ...} method has a reference to the class instance (this). Try:
public class FinalizeThis {
private String a = "a";
protected void finalize() {
System.out.println("finalized!");
}
void loop() {
System.out.println("loop() called");
for (int i = 0; i < 1_000_000_000; i++) {
if (i % 1_000_000 == 0)
System.gc();
}
// System.out.println(a);
System.out.println("loop() returns");
}
public static void main(String[] args) {
new FinalizeThis().loop();
}
}
The above program always outputs
loop() called
finalized!
loop() returns
in Java 8. If you, however, uncomment System.out.println(a), the output changes to
loop() called
a
loop() returns
There is no GC this time because the method called references the instance variable (this.a).
You can take look at this answer

How to ensure finalize() is always called (Thinking in Java exercise)

I'm slowly working through Bruce Eckel's Thinking in Java 4th edition, and the following problem has me stumped:
Create a class with a finalize( ) method that prints a message. In main( ), create an object of your class. Modify the previous exercise so that your finalize( ) will always be called.
This is what I have coded:
public class Horse {
boolean inStable;
Horse(boolean in){
inStable = in;
}
public void finalize(){
if (!inStable) System.out.print("Error: A horse is out of its stable!");
}
}
public class MainWindow {
public static void main(String[] args) {
Horse h = new Horse(false);
h = new Horse(true);
System.gc();
}
}
It creates a new Horse object with the boolean inStable set to false. Now, in the finalize() method, it checks to see if inStable is false. If it is, it prints a message.
Unfortunately, no message is printed. Since the condition evaluates to true, my guess is that finalize() is not being called in the first place. I have run the program numerous times, and have seen the error message print only a couple of times. I was under the impression that when System.gc() is called, the garbage collector will collect any objects that aren't referenced.
Googling a correct answer gave me this link, which gives much more detailed, complicated code. It uses methods I haven't seen before, such as System.runFinalization(), Runtime.getRuntime(), and System.runFinalizersOnExit().
Is anybody able to give me a better understanding of how finalize() works and how to force it to run, or walk me through what is being done in the solution code?

When the garbage collector finds an object that is eligible for collection but has a finalizer it does not deallocate it immediately. The garbage collector tries to complete as quickly as possible, so it just adds the object to a list of objects with pending finalizers. The finalizer is called later on a separate thread.
You can tell the system to try to run pending finalizers immediately by calling the method System.runFinalization after a garbage collection.
But if you want to force the finalizer to run, you have to call it yourself. The garbage collector does not guarantee that any objects will be collected or that the finalizers will be called. It only makes a "best effort". However it is rare that you would ever need to force a finalizer to run in real code.

Outside of toy scenarios, it's generally not possible to ensure that a finalize will always be called on objects to which no "meaningful" references exist, because the garbage collector has no way of knowing which references are "meaningful". For example, an ArrayList-like object might have a "clear" method which sets its count to zero, and makes all elements within the backing array eligible to be overwritten by future Add calls, but doesn't actually clear the elements in that backing array. If the object has an array of size 50, and its Count is 23, then there may be no execution path by which code could ever examine the references stored in the last 27 slots of the array, but there would be no way for the garbage-collector to know that. Consequently, the garbage-collector would never call finalize on objects in those slots unless or until the container overwrote those array slots, the container abandoned the array (perhaps in favor of a smaller one), or all rooted references to the container itself were destroyed or otherwise ceased to exist.
There are various means to encourage the system to call finalize on any objects for which no strong rooted references happen to exist (which seems to be the point of the question, and which other answers have already covered), but I think it's important to note the distinction between the set of objects to which strong rooted references exist, and the set of objects that code may be interested in. The two sets largely overlap, but each set can contain objects not in the other. Objects' finalizers` run when the GC determines that the objects would no longer exist but for the existence of finalizers; that may or may not coincide with the time code they cease being of interest to anyone. While it would be helpful if one could cause finalizers to run on all objects that have ceased to be of interest, that is in general not possible.

A call to garabage collecter (System.gc()) method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse (i.e its just a suggestion to the jvm, and does not bind it to perform the action then and there, it may or may not do the same). When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all discarded objects. finalize() is called by the garbage collector on an object when garbage collection determines that there are no more references to the object

run new constructor() and System.gc() more than twice.
public class Horse {
boolean inStable;
Horse(boolean in){
inStable = in;
}
public void finalize(){
if (!inStable) System.out.print("Error: A horse is out of its stable!");
}
}
public class MainWindow {
public static void main(String[] args) {
for (int i=0;i<100;i++){
Horse h = new Horse(false);
h = new Horse(true);
System.gc();
}
}
}

Here's what worked for me (partially, but it does illustrate the idea):
class OLoad {
public void finalize() {
System.out.println("I'm melting!");
}
}
public class TempClass {
public static void main(String[] args) {
new OLoad();
System.gc();
}
}
The line new OLoad(); does the trick, as it creates an object with no reference attached. This helps System.gc() run the finalize() method as it detects an object with no reference. Saying something like OLoad o1 = new OLoad(); will not work as it will create a reference that lives until the end of main(). Unfortunately, this works most of the time. As others pointed out, there's no way to ensure finalize() will be always called, except to call it yourself.

How to prevent an object from getting garbage collected?

How to prevent an object from getting garbage collected?
Are there any approaches by finalize or phantom reference or any other approaches?
I was asked this question in an interview. The interviewer suggested that finalize() can be used.

Hold a reference. If your object is getting collected prematurely, it is a symptom that you have a bug in the design of your application.
The garbage collector collects only objects to which there is no reference in your application. If there is no object that would naturally reference the collected object, ask yourself why it should be kept alive.
One usecase in which you typically have no references, but want to keep an object is a singleton. In this case, you could use a static variable. One possible implementation of a singleton would look like this:
public class Singleton {
private static Singleton uniqueInstance;
private Singleton() {
}
public static synchronized Singleton getInstance() {
if (uniqueInstance == null) {
uniqueInstance = new Singleton();
}
return uniqInstance;
}
}
Edit: Technically, you can store a reference somewhere in your finalizer. This will prevent the object from being collected until the collector determines again that there are no more references. The finalizer will only be called at most once, however, so you must ensure that your object (including its superclasses) need not be finalized after the first collection. I would advise you, however, not to use this technique in actual programs. (It will leave colleagues like me yelling WTF!? ;)
protected void finalize() throws Throwable {
MyObjectStore.getInstance().store(this);
super.finalize(); // questionable, but you should ensure calling it somewhere.
}

The trick answer your interviewer was looking for is probably that he wants you to know that you can prevent garbage collection from removing an object by forcing a memory leak.
Obviously, if you keep a reference to the object in some long-lived context, it won't be collected, but that's not what the OP's recruiter asked about. That's not something which happens in the finalize method.
What you can do to prevent garbage collection from within the finalize method is to write an infinite loop, in which you call Thread.yield();(presumably to keep an empty loop from being optimized away):
#Override
protected void finalize() throws Throwable {
while (true) {
Thread.yield();
}
}
My reference here is an article by Elliot Back, in which describes forcing a memory leak by this method.
Just another way in which finalize methods are evil.

The best way is to use Unsafe, although ByteBuffer might be a possible workaround for some cases.
Also search for the keyword "off-heap" memory.
Unsafe
Advantages over ByteBuffer:
allows objects to be represented directly, without for serialization and thus faster
no bounds checking, so faster
explicit deallocation control
can allocate more than the JVM limit
It is not however easy to get working. The method is described in the following articles:
http://mishadoff.com/blog/java-magic-part-4-sun-dot-misc-dot-unsafe/
https://highlyscalable.wordpress.com/2012/02/02/direct-memory-access-in-java/
http://java.dzone.com/articles/understanding-sunmiscunsafe
They all consist of the following steps:
we need a sizeof operator, which Unsafe does not have. How to make one was asked at: In Java, what is the best way to determine the size of an object?. The best options is likely the instrument API, but that requires you to create a Jar and use special command line options...
once we have sizeof, allocate enough memory with Unsafe#allocateMemory, which is basically a malloc and returns an address
create a regular on heap object, copy it to the allocated memory with Unsafe#copyMemory. To do this, you need to the address of the on-heap object, and the size of the object
set an Object to point to the allocated memory, then cast the Object to your class.
It does not seem possible to set the address of a variable directly with Unsafe, so we need to wrap the object into an array or wrapper object, and use Unsafe#arrayBaseOffset or Unsafe#objectFieldOffset.
once you are done, free the allocated memory with freeMemory
If I ever get this to not segfault I will post an example :-)
ByteBuffer
Advantages over Unsafe:
stable across Java versions while Unsafe may break
does bound checking, so safer than... Unsafe, which allows for memory leaks and SIGSEGV
JLS says:
The contents of direct buffers may reside outside of the normal garbage-collected heap.
Example of usage with primitives:
ByteBuffer bb = ByteBuffer.allocateDirect(8);
bb.putInt(0, 1);
bb.putInt(4, 2);
assert bb.getInt(0) == 1;
assert bb.getInt(4) == 2;
// Bound chekcs are done.
boolean fail = false;
try {
bb.getInt(8);
} catch(IndexOutOfBoundsException e) {
fail = true;
}
assert fail;
Related threads:
Difference between "on-heap" and "off-heap"

If there is still a reference to the object, it won't get garbage collected. If there aren't any references to it, you shouldn't care.
In other words - the garbage collector only collects garbage. Let it do its job.

I suspect what you might be referring to is if your finalize method stashes away a reference to the object being finalized. In this case (if my reading of the Java Language Spec is correct) the finalize method will never be re-run, but the object will not yet be garbage collected.
This is not the sort of thing one does in real life, except possibly by accident!

This sounds like one of those interview-only-time-you'll-see-it questions. finalize() is run when your object is getting garbage collected, so it'd be pretty perverse to put something in there to prevent collection. Normally you just hold a reference and that's all you need.
I'm not even sure what would happen if you'd create a new reference for something in the finalizer - since the garbage collector's already decided to collect it would you then end up with a null ref? Seems like a poor idea, in any case. e.g.
public class Foo {
static Foo reference;
...
finalize (){
reference = this;
}
}
I doubt this would work, or it might work but be dependant on the GC implenetation, or be "unspecified behavior". Looks evil, though.

The key point is if we set the real reference variable pointing to the object null,although we have instance variables of that class pointing to that object not set to null.
The object is automatically eligible for garbage collection.if save the object to GC, use this code...
public class GcTest {
public int id;
public String name;
private static GcTest gcTest=null;
#Override
protected void finalize() throws Throwable {
super.finalize();
System.out.println("In finalize method.");
System.out.println("In finalize :ID :"+this.id);
System.out.println("In finalize :ID :"+this.name);
gcTest=this;
}
public static void main(String[] args) {
GcTest myGcTest=new GcTest();
myGcTest.id=1001;
myGcTest.name="Praveen";
myGcTest=null;
// requesting Garbage Collector to execute.
// internally GC uses Mark and Sweep algorithm to clear heap memory.
// gc() is a native method in RunTime class.
System.gc(); // or Runtime.getRuntime().gc();
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("\n------- After called GC () ---------\n");
System.out.println("Id :"+gcTest.id);
System.out.println("Name :"+gcTest.name);
}
}
Output :
In finalize method.
In finalize :ID :1001
In finalize :ID :Praveen
------- After called GC () --------
Id :1001
Name :Praveen

I wonder if what they're going for is the pattern with resource pools (e.g. for network/db connections, or threads) where you use finalize to return a resource to the pool so that the actual object holding the resource isn't GC'ed.
Stupid example, in Java-like pseudocode and missing any kind of synchronization:
class SlowResourceInternal {
private final SlowResourcePool parent;
<some instance data>
returnToPool() {
parent.add(this);
}
}
class SlowResourceHolder {
private final SlowResourceInternal impl;
<delegate actual stuff to the internal object>
finalize() {
if (impl != null) impl.returnToPool();
}
}

I believe there is a pattern out there for this. Not sure if it the factory pattern. But you have one object that creates all your objects and holds a reference to them. When you are finished with them, you de-reference them in the factory, making the call explicit.

We have three ways to achieve same -
1) Increasing the Heap -Eden space size .
2) Create Singleton class with Static reference .
3) Override finalize() method and never let that object dereference.

There are 3 ways to prevent an Object from Garbage Collection as following:-
Increase the Heap Size of JVM
// Xms specifies initial memory to be allocated
// and Xmx specifies maximum memory can be allocated
java -Xms1024m -Xmx4096m ClassFile
Use a SingleTon Class Object as #Tobias mentioned
public class MySingletonClass {
private static MySingletonClass uniqueInstance;
// marking constructor as private
private MySingletonClass() {
}
public static synchronized MySingletonClass getInstance() {
if (uniqueInstance == null) {
uniqueInstance = new Singleton();
}
return uniqInstance;
}
}
We can override finalize method. That is last method executed on an object. Hence, it will remain in memory.
// using finalize method
class MyClassNotGc{
static MyClassNotGc staticSelfObj;
pubic void finalize() {
// Putting the reference id
//Object reference saved.
//The object won't be collected by the garbage collector
staticSelfObj = this;
}
}

Java and manually executing finalize

If I call finalize() on an object from my program code, will the JVM still run the method again when the garbage collector processes this object?
This would be an approximate example:
MyObject m = new MyObject();
m.finalize();
m = null;
System.gc()
Would the explicit call to finalize() make the JVM's garbage collector not to run the finalize() method on object m?

According to this simple test program, the JVM will still make its call to finalize() even if you explicitly called it:
private static class Blah
{
public void finalize() { System.out.println("finalizing!"); }
}
private static void f() throws Throwable
{
Blah blah = new Blah();
blah.finalize();
}
public static void main(String[] args) throws Throwable
{
System.out.println("start");
f();
System.gc();
System.out.println("done");
}
The output is:
start
finalizing!
finalizing!
done
Every resource out there says to never call finalize() explicitly, and pretty much never even implement the method because there are no guarantees as to if and when it will be called. You're better off just closing all of your resources manually.

One must understand the Garbage Collector(GC) Workflow to understand the function of finalize. calling .finalize() will not invoke the garbage collector, nor calling system.gc. Actually, What finalize will help the coder is to declare the reference of the object as "unreferenced".
GC forces a suspension on the running operation of JVM, which creates a dent on the performance. During operation, GC will traverse all referenced objects, starting from the root object(your main method call). This suspension time can be decreased by declaring the objects as unreferenced manually, because it will cut down the operation costs to declare the object reference obsolete by the automated run. By declaring finalize(), coder sets the reference to the object obsolete, thus on the next run of GC operation, GC run will sweep the objects without using operation time.
Quote: "After the finalize method has been invoked for an object, no further action is taken until the Java virtual machine has again determined that there is no longer any means by which this object can be accessed by any thread that has not yet died, including possible actions by other objects or classes which are ready to be finalized, at which point the object may be discarded. " from Java API Doc on java.Object.finalize();
For detailed explanation, you can also check: javabook.computerware

The finalize method is never invoked more than once by a JVM for any given object. You shouldn't be relying on finalize anyway because there's no guarantee that it will be invoked. If you're calling finalize because you need to execute clean up code then better to put it into a separate method and make it explicit, e.g:
public void cleanUp() {
.
.
.
}
myInstance.cleanUp();