Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Wiki Markup
    According to the Java Language Specification \[[JLS 052005|AA. Java References#JLS 05]\] Section 12.6.2 "Finalizer Invocations are Not Ordered":

    Wiki Markup
    The Java programming language imposes no ordering on {{finalize}} method calls. Finalizers \[of different objects\] may be called in any order, or even concurrently.

    This can be a problem as slow running finalizers tend to block others in the queue.

...

  • Wiki Markup
    It is not advisable to use any lock or sharing based mechanisms within a finalizer because of the inherent dangers of deadlock and starvation. On the other hand, it is easy to miss that there can be synchronization issues with the use of finalizers even if the source program is single-threaded. This is because the {{finalize()}} methods are called from their own threads (not from the {{main()}} thread). If a finalizer is necessary, the cleanup data structure should be protected from concurrent access (See \[[Boehm 052005|AA. Java References#Boehm 05]\]).

...

Wiki Markup
According to the Java API \[[API 062006|AA. Java References#API 06]\] class {{System}}, {{runFinalizersOnExit()}} method documentation:

...

Wiki Markup
Joshua Bloch \[[Bloch 082008|AA. Java References#Bloch 08]\] suggests implementing a {{stop()}} method explicitly such that it leaves the class in an unusable state beyond its lifetime. A {{private}} field within the class can signal whether the class is unusable. All the class methods must check this field prior to operating on the class. This is akin to *EX1* discussed in [OBJ04-J. Do not allow partially initialized objects to be accessed]. As always, a good place to call the termination logic is in the {{finally}} block.

...

Wiki Markup
Alternatively, a more expensive solution is to declare an anonymous class so that the {{finalize()}} method is guaranteed to run for the superclass. This solution is applicable to {{public}} non-final classes. "The finalizer guardian object forces {{super.finalize}} to be called if a subclass overrides {{finalize()}} and does not explicitly call {{super.finalize}}". \[[JLS 052005|AA. Java References#JLS 05]\] 

...

References

Wiki Markup
\[[JLS 052005|AA. Java References#JLS 05]\] Section 12.6, Finalization of Class Instances
\[[API 062006|AA. Java References#API 06]\] [finalize()|http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#finalize()]
\[[Bloch 082008|AA. Java References#Bloch 08]\] Item 7, Avoid finalizers 
\[[Darwin 042004|AA. Java References#Darwin 04]\] Section 9.5, The Finalize Method
\[[Flanagan 052005|AA. Java References#Flanagan 05]\] Section 3.3, Destroying and Finalizing Objects
\[[Coomes 072007|AA. Java References#Coomes 07]\] "Sneaky" Memory Retention
\[[Boehm 052005|AA. Java References#Boehm 05]\] 
\[[MITRE 092009|AA. Java References#MITRE 09]\] [CWE ID 586|http://cwe.mitre.org/data/definitions/586.html] "Explicit Call to Finalize()", [CWE ID 583|http://cwe.mitre.org/data/definitions/583.html] "finalize() Method Declared Public", [CWE ID 568|http://cwe.mitre.org/data/definitions/568.html] "finalize() Method Without super.finalize()"

...