Finalizer method not executed when object dies

Question

I have a situation where on construction of an object a static variable is incremented by 1. Now, I want this variable to be decremented as soon as object dies.

Overriding finalize is one way, but that does not ensure as soon as part and is not guaranteed too.

is there any other way to achieve this?

EDIT : real problem is, I require thread sequencing like, "Thread-1" "Thread-2" etc. and if "Thread-2" dies, you want the next created thread to become "Thread-2"

@Stunner My question is "is there any other way to achieve this?" — codingenious, Apr 15 '14 at 08:56
Are you trying to do this in order to solve some real problem? Or are you just asking out of interest? If you have a real problem, this is almost certainly *not* the right way to try to solve it. Perhaps you could spell out what you really want to achieve. For example, perhaps making your class `Closeable` and using try-with-resources might help. (Depending on the real goal.) — Paul, Apr 15 '14 at 08:59
real problem is - it's a thread and count is worker id, so need to be in sequence. — codingenious, Apr 15 '14 at 08:59
If `GC` is not reliable, then `finalize` is not reliable. http://stackoverflow.com/questions/2506488/java-finalize-method-call — sybear, Apr 15 '14 at 08:59
Never put business logic in finalize method. As its not guaranteed when the GC would be called, it depends on many factors. — Jay, Apr 15 '14 at 09:01
@Batty Have you considered using one of Java's built-in thread pool classes rather than writing your own? E.g. see [`Executors`](http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Executors.html). — Duncan Jones, Apr 15 '14 at 09:07

Kayaman · Answer 1 · 2014-04-15T09:02:37.717

1

The GC probably doesn't bother running at all, since that code is ridiculously simple. Imagine if the GC ran every time an object were eligible for GC? It would run constantly.

Don't try to rely on things that aren't guaranteed.

What are attempting to do with your object counting? Perhaps there's a more elegant solution.

Edit: If you are interested in keeping track of Threads and not just normal objects, you're probably more interested in knowing whether a Thread is running or not. You can track that without messing around with GC.

What's the actual use case you're trying to do?

Here's an example with threads (if I understood what you're trying to do):

Thread[] myThreads = new Thread[10];

public Thread getNewThread(Runnable r) {
    for(int i = 0;i < myThreads.length;i++) {
        if(myThreads[i] == null || !myThreads[i].isAlive()) {
            // Found an unused index
            Thread t = new Thread(r);
            myThreads[i] = t;
            return t;
        }
    }
    return null; // Return null, because there aren't places available
}

edited Apr 15 '14 at 09:02

answered Apr 15 '14 at 08:53

Kayaman

72,141
5
83
121

Ok. Can there be any other way? – codingenious Apr 15 '14 at 08:53
say, it's a thread and count is worker id, so need to be in sequence. – codingenious Apr 15 '14 at 08:54
@Batty Create more objects in a loop and make the reference null in the next statement. The more objects you create and make them available for GC , the more chances the GC will execute – Stunner Apr 15 '14 at 08:56
1

@Stunner That's not really a solution. – Kayaman Apr 15 '14 at 08:56
@Batty Do you mean that you need to have "Thread-1" "Thread-2" etc. and if "Thread-2" dies, you want the next created thread to become "Thread-2"? – Kayaman Apr 15 '14 at 08:57
@kayaman Maybe.. But there are chance.We don't know. As OP is stressing the same thing again that he wants to achieve it. It's one of the possible solution – Stunner Apr 15 '14 at 08:58
@Batty Please edit your question to include this useful information. – Duncan Jones Apr 15 '14 at 09:04
@Batty Updated the answer with a code snippet to examine whether a Thread is alive or not. Basically a weird way to create a Thread pool of sorts for 10 simultaneous Runnables. – Kayaman Apr 15 '14 at 09:07

score 1 · Answer 2 · answered Apr 15 '14 at 08:56

1

There is usually no case to use the finalizer method. Maybe in JNI.

Even IO cleanup shouldn't be called in finalize, because it is not sure when it is called.

For resources the Closable interface is the pattern used.

answered Apr 15 '14 at 08:56

keiki

3,260
3
30
38

score 1 · Answer 3 · answered Apr 15 '14 at 09:01

is there any other way to achieve this?

I think a neat way is to implement AutoCloseable and do your tidying up in the close() method. Modern IDEs will complain if your object is used in a way that doesn't ensure the close() method is called. It will also work with a try-with-resources statement:

try (A a = new A()) {
  // blah
}

score -3 · Answer 4 · answered Apr 15 '14 at 08:56

-3

Just put System.gc(); after new Prac().call(); line.. your finalize would be called..(It is not guarantee) your code will look like this..

public static void main(String[] args) throws InterruptedException
{
    new Prac().call(); //line 1
    System.gc();
    Thread.sleep(1000); //line 2 object a is eligible for GC.

}

answered Apr 15 '14 at 08:56

niiraj874u

2,180
1
12
19

The call to `gc()` might cause it to be garbage collected, and finalized. Or it might not. Or it might when you test it once, and not another time. Or it might do different things on different machines, JVMs, etc. – Paul Apr 15 '14 at 08:57

Finalizer method not executed when object dies

4 Answers4