Develop Reference

Can the finalize() method be called twice if the garbage collector retains memory twice in the same code?

I found it in many places that the finalize() method in java is called when the garbage collector or System.gc() has successfully retained the memory consumed by the redundant object with no more references to it. Also found that this method is called not more than a single time. I am not new to java but also not pretty much experienced. I may have a wrong understanding of it but let's say a piece of code
public class Solution {
#Override
protected void finalize(){
System.out.print("method called");
}
public static void main(String... args){
Solution obj1= new Solution();
Solution obj2 = new Solution();
Solution obj3 = new Solution();
System.gc();
obj1=obj2;
System.gc();
obj3=null;
System.gc();
}
}
Here, the finalize method is called twice because the memory heap becomes eligible for garbage cleaning two times. So, I am a bit confused whether I know the whole thing right or if it is supposed to behave the way it's behaving.

No. The finalize() method will only be called once by the GC on an object. The JVM sets a flag in the object header (I think) to say that it has been finalized, and won't finalize it again.
The javadoc states this explicitly:
" The finalize method is never invoked more than once by a Java virtual machine for any given object. "
Of course, there is nothing to stop an object method from calling this.finalize() any number of times.
Note that finalize() is deprecated in Java 9 and later for reasons stated in the javadoc. It is recommended that you switch to using one of the following instead:
AutoCloseable + try with resources
Cleaner
PhantomReference
Someone commented thus:
finalize() is called for every Object that is collected.
This is not true for a couple of reasons.
The javadoc explicitly states that there are no guarantees that finalize will ever be called. The thing that is guaranteed is that it will be called (once) before an object's storage is reclaimed. That is a weaker statement than the statement that the comment makes.
One scenario where garbage collected objects may not be finalized is if the JVM exits soon after a GC run.
Another (pathological) scenario occurs when a classes finalize method never returns1. When an instance of that class is finalized, the finalizer thread will get stuck. When all finalizer threads are stuck in that way, no more finalizable objects can be finalized2.
If the Object::finalize is not overridden in a class, the JVM will skip the finalization step for that class.
1 - This could be due to an infinite loop, or because the finalize() method gets stuck waiting on a lock or waiting for an internal or external "event" that never happens. Note also that "never" could mean "not for a long time" in this context. The overall impact can be the same.
2 - The objects will sit in the finalization queue indefinitely. This is a memory leak.

finalize() not getting called

Why is finalize() not being called here. The code compiled and ran successfully but there wasn't any output.
package temp;
public class Temp {
int i;
Temp(int j) {
i = j;
}
public void finalize() {
if (i == 10) {
System.out.println("Finalize called.");
}
}
public static void main(String[] args) {
Temp obj = new Temp(10);
System.gc();
}
}

Your call to System.gc(); makes no difference, since your Temp instance has a reference (obj) so it's not eligible for garbage collection.
Even if it was eligible for garbage collection, calling System.gc(); doesn't necessarily collect all the objects that have no reference to them immediately.

It so happen that im reading Effective Java
ITEM 7: AVOID FINALIZERS
Finalizers are unpredictable, often dangerous, and generally
unnecessary. -Effective Java (page 50)
another one from pdf.
Don’t be seduced by the methods System.gc and System.runFinalization .
They may increase the odds of finalizers ge tting executed, but they
don’t guaran- tee it. The only methods that claim to guarantee
finalization are System.runFi- nalizersOnExit and its evil twin,
Runtime.runFinalizersOnExit . These methods are fatally flawed and
have been deprecated [ThreadStop].
based on this using System.gc will only increase the odds of finalizers getting executed and importantly using it will not guarantee that it will run the Garbage Collection, it is only suggesting to the jvm.
another one.
Not only does the language specification provide no guarantee that
finalizers will get executed promptly; it provides no guarantee that
they’ll get executed at CHAPTER 2 CREATING AND DESTROYING OBJECTS 28
all. It is entirely possible, even likely, that a program terminates
without executing finalizers on some objects that are no longer
reachable

while creating an object the constructor is called but not the finalise() method so you need to refer the function from instance obj and here System.gc(); has not made any difference or called the method finalize();

add obj = null; to make reference null, then your finalize method will be called. Thsi is again not a guranteed behaviour, for me 1-2 times i was able to call it out of 5 times.
public static void main(String[] args) {
Temp obj = new Temp(10);
obj = null;
System.gc();
}
Output
hi10
Finalize called.

Should i use finalize() or not in java? [duplicate]

This question already has answers here:
When is the finalize() method called in Java?
(18 answers)
Closed 8 years ago.
Why execution of finalize() isn't guaranteed at all in Java? Is finalize() method shouldn't be used???
Consider below program.
class Test{
protected void finalize()
{
System.out.println("Will i execute?");
}
public static void main(String args[])
{
Test t=new Test();
}
}
There is an empty output when this program runs. We know that finalize() is used to cleanup any external resources before the object becomes eligible for garbage collection & finalize() will be called by JVM. Inside finalize() we will specify those actions that must be performed before an object is destroyed. Is finalize() method evil??

Javadoc link, because many quotes will follow.
We know that finalize() is used to cleanup any external resources before the object becomes eligible for garbage collection
No. Once the object becomes eligible for garbage collection, then finalize() can get invoked. finalize could theoretically make the object no longer eligible for garbage collection and the garbage collector would then skip it. As stated
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
Why execution of finalize() isn't guaranteed at all in Java?
It is guaranteed to run. As the Javadoc states
The general contract of finalize is that it is invoked if and when the
Java™ virtual machine has determined that there is no longer any means
by which this object can be accessed by any thread that has not yet
died, except as a result of an action taken by the finalization of
some other object or class which is ready to be finalized.
What isn't guaranteed is when or if garbage collection will occur.
Should i use finalize() or not in java?
That depends on your use case. Start by reading the javadoc and understand the implications.

finalize() is Called by the garbage collector on an object when garbage collection determines that there are no more references to the object. .
You could use System.gc() to explicitly call for garbage collection and check if your statement gets printed.
But the JVM has the liberty to ignore your request (depends on the JVM implementation actually..). Only when the JVM's internal state tells it that there is too much garbage and it needs to be collected, then it will run GC (and the line will I execute) will be printed.

If I understand your question, you can use the System.gc() to request garbage collection with something like this,
#Override
protected void finalize() {
System.out.println("I will execute.");
}
public static void main(String args[]) {
Test t = new Test();
t = null; // <-- make it eligible for gc.
System.gc(); // <-- request gc.
System.runFinalization(); // <-- run finalization(s).
System.out.println("Exit"); // <-- exit.
}
Depending on your JVM, you might find the order of output swaps if you comment out System.runFinalization(); -
public static void main(String args[]) {
Test t = new Test();
t = null; // <-- make it eligible for gc.
System.gc(); // <-- request gc.
// System.runFinalization(); // <-- run finalization(s).
System.out.println("Exit"); // <-- exit.
}

Before removing an object from memory Garbage collection thread invokes finalize () method of that object and gives an opportunity to perform any sort of cleanup operations.
Generally an object becomes eligible for garbage collection in Java on following cases:
All references of that object explicitly set to null e.g. object = null.
Object is created inside a block and reference goes out scope once control exit that block.
Parent object set to null, if an object holds reference of another object and when you set container object's reference null, child or contained object automatically becomes eligible for garbage collection.
If an object has only live references via WeakHashMap it will be eligible for garbage collection.
public Test(){
System.out.println("Object created");
}
protected void finalize(){
System.out.println("Will i execute?");
}
public static void main(String args[]){
Test test = new Test();
test = null;
new Test();
System.gc();
}

finalize() of any particular class is called by jvm just before collecting the object of that class as a garbage.
Now next question is when an object of a class is collected as garbage?
Answer is:
When there is no more objects reference to that object or simply no more object reference is pointing to that allocated memory space or an object has only live references via WeakHashMap it will be eligible for garbage collection.
Read more here.
As an option we can use System.gc() or Runtime.gc() that will give a request to jvm to consider the garbage collection. But whether your request will be listened or ignored by jvm that depends upon following factors:
Internal implementation of JVM & its Garbage Collection algorithm
Java Heap size
Free memory available in Heap

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;
}
}