2

In this amazing book the author Josh Bloch mentions:

"Oh, and one more thing: there is a severe performance penalty for using finalizers. On my machine, the time to create and destroy a simple object is about 5.6 ns. Adding a finalizer increases the time to 2,400 ns. In other words, it is about 430 times slower to create and destroy objects with finalizers."

Is there a way we can delete and object in java?
I thought we can simply let the objects fall out of scope or reset them to null.
I intend to experiment this on my machine, seems like a fun idea but I am not sure how to delete and object.

arne.b
  • 4,212
  • 2
  • 25
  • 44
EMM
  • 1,812
  • 8
  • 36
  • 58
  • Unless you have a specific *need* for a finalizer, you don't need to use one. – Dave Newton Oct 15 '14 at 12:03
  • 2
    check [here](http://stackoverflow.com/questions/158174/why-would-you-ever-implement-finalize) – TheLostMind Oct 15 '14 at 12:07
  • @Dave Yeah, you are right. I understand this and also see the reply comment to Eran below, but I was wondering how the author managed to calculate the time between creation and deletion. It seems pretty clear that he IS talking abt deletion and not about eligible to deletion state of the object. Thanks for taking time out for helping me. – EMM Oct 15 '14 at 12:09

2 Answers2

2

Once you make the reference variable refers to null (assuming last reference) and that variable gets out of its scope, then the object is eligible to be garbage-collected at next garbage-collection cycle.

Eng.Fouad
  • 115,165
  • 71
  • 313
  • 417
  • Hey! thanks for the quick response. I was wondering how may I figure the time between creating and deletion b/c resetting to null just make it *eligible*, it doesn't actually delete it. – EMM Oct 15 '14 at 11:58
  • 1
    @mohit - Actually, you need to reset *all the references* to null. The object should be *unreachable* (which happens when it goes out of scope and the references are popped from the stack). – TheLostMind Oct 15 '14 at 11:59
  • 1
    @mohit *Nothing* "deletes" it except the JVM, and technically, you cannot control when GC runs. You can *suggest* it should run, and many implementations *do* run it when you suggest it. – Dave Newton Oct 15 '14 at 12:02
  • @mohit Try to use Java profiler like JProfiler or YourKit. – Eng.Fouad Oct 15 '14 at 12:24
2

An object will cease to exist when there are no longer any strong rooted references to it; in most cases that's exactly what should happen. In some cases, however, an object will ask an outside entity to do something on its behalf, possibly to the detriment of other entities, in exchange for a promise to let that other entity know when its services are no longer required. For example, a "File" object might ask the OS for exclusive access to a file; until the OS is told that such access is no longer required, it will block everyone else's ability to use that file.

If an object which had made such a promise were abandoned and simply ceased to exist, the outside entity would keep on doing whatever it had been asked to do, to the detriment of everyone else, even though its actions were no longer of any benefit to anyone. To avoid this situation, Java allows objects to request notification when the GC notices that they seem to have been abandoned. Such notifications will be given (i.e. Finalize will be called on such objects) before the objects cease to exist, but there's no real guarantee of timeliness beyond that. An object which is finalized can then notify any and all entities acting on its behalf that they should stop doing so.

The creators of Java may have expected finalizers to be the primary mechanism by which objects could notify outside entities that their services are no longer required, but finalization really doesn't work very well. Other mechanisms such as AutoCloseable or PhantomReference are better in many cases.

supercat
  • 77,689
  • 9
  • 166
  • 211