views:

401

answers:

6

I was given the following phrase in an interview:

The invocation of an Object's finalize() method is the last thing that happens before an object is garbaged collected.

I had to answer by:

  • True
  • False

I've chosen True but it was wrong. Can you please explain me why ?

+1  A: 

There is no guarantee that finalize() will always be called, or even that garbage collection will run at all.

Suppose that your program ends (either by calling System.exit() or when all running threads reach their end), then the JVM will just quit, it won't clean everything up and call finalize() on all objects.

Therefore, putting cleanup tasks that absolutely must run in a finalize() method is not a good idea.

Jesper
this does not answer the question
unbeli
It partly answers the question and gives some useful information about why `finalize()` isn't as useful as many programmers think.
Jesper
it might be nice to spray useful trivia around, but it's even nicer to stick to the topic.
unbeli
Thanks for the answer. Even though is not an exact answer it's a nice to know trivia.
Andrei Ciobanu
+5  A: 

I think it hints that the fact that there are actually other things that can be done / happen to the object before the GC really discards it.

To quote the reference:

[...]The finalize method may take any action, including making this object available again to other threads; the usual purpose of finalize, however, is to perform cleanup actions before the object is irrevocably discarded. For example, the finalize method for an object that represents an input/output connection might perform explicit I/O transactions to break the connection before the object is permanently discarded.[...]

So in this light, the finalizing process isn't the last thing before the GC discards it.

Bakkal
+17  A: 

The order is different:

  1. First the object is collected.
  2. Then the object is finalized.

See http://java.sun.com/docs/books/performance/1st_edition/html/JPAppGC.fm.html

Object lifecycle:

  1. Created
  2. In use (strongly reachable)
  3. Invisible
  4. Unreachable
  5. Collected
  6. Finalized
  7. Deallocated
DR
Confirmed. *collected* is not the final state of the object's life cycle, it is *deallocated*. +1 for the link and learning something today :)
Andreas_D
Thank you very this. Very useful knowledge.
Cambium
+1  A: 

If you have an exception within the finalize() method (if you override it), it halts the finalization... I think. So it's not always true. I would have probably chosen true as well.

edit: this turned out to be irrelevant, read the first answer :)

Cambium
+2  A: 

I guess you can defend both answers, finalize() is called by the garbage collector before it collects the object, but you cannot be sure that will ever be the case before the apllication ends. Not all objects that are allegible to be garbage collected have to be colected. You may never depend on the finalize() method to be called for any object.

rsp
+1  A: 

The order is wrong, as DR already showed.

An object changes its state to collected when the gc has recognized, that the object is unreachable.

So who should take action to finalize an object before this 'unreachable' condition was detected? In fact it's the garbage collector that marks collected objects for finalization (if the objects finalize method is overridden). And we really don't want to finalize objects that are still reachable, e.g. 'in use'.

Nice question anyway, because you tend to say 'yes it's true'.

Andreas_D