Finalizers - The not so good, the bad and the ugly
summary
Shows measured harm: a JMH benchmark finds finalized objects cost about 3x allocation and force 50–200x GC time in tests, often requiring 2 GC cycles to reclaim due to resurrection. Demonstrates changing one hot class removed heavy finalize usage, reducing GC from about 5% of runtime to near zero in load tests and eliminating production restarts. Explains why finalize creates extra tracker objects, delays collection, can resurrect objects, swallows exceptions, and causes unpredictable, long-latency cleanup.
AI-written summary · about
chapters (21)
- 0:00Work Day
- 0:10Analyzing Thread Dump
- 1:03What is Finalizer?
- 1:49Finalizable Object life Cycle
- 3:22Benchmark Results
- 5:54Load Test Result (Before)
- 6:18Load Test Result (After)
- 6:55Problem with Finalizers
- 7:14Dead Object Resurrection(Bad)
- 8:19Increase Allocation Cost(Bad)
- 9:04Cause more GCs(Ugly)
- 10:07No Guarantee, when called (Ugly)
- 10:45No Guarantee (Example)
- 11:49Make object concurrent(Ugly)
- 13:11Problem Class(Fixed)
- 14:08When to use Finalizer(Not so Good)
- 15:26Do you really need finalizer?
- 15:46Provide explicit termination method.
- 16:05Reduce data overhead(Before)
- 16:31Utilize Cache or Object pool
- 16:42References
related talks
55mThe Performance Engineer's Guide To Java HotSpot
44mGarbage Collector: How to Tame the Beast and Make It Your Best Ally
47mManaging and monitoring a JVM
01h 32mUnderstanding Java Garbage Collection and what you can do about it
13mHighlights
25mGarbage Collection Primer
46mFrom Final to Immutable: The not-so-final word on `final`
33mNo GC coding techniques for low latency Java