Finalization thread does not keep up with Object allocation

Question

Hi,
I'm trying to track down a memeory leak in my program. When I use OptimizeIT I find 11,690 instances of java.lang.ref.Finalizer hanging about. I also see lots of JDBC Connection, CallableStatements, and PreparedCalls hanging around. (They are actually instances of my vendor specific classes). Those objects include a finalize() method.
Why are all these java.lang.ref.Finalizers hanging about? Why doesn't the finalization thread actually let go of them or finalize them in a timely manner! Eventually, my process runs out of memory and the Finalization thread never seems to finalize these objects. The rate at which I am newing up connections seems to be faster than the finalization thread can destory the object.
charlie
p.s.
When I go into the reference graph, there are lots of Connection objects that don't have link back to the root set. But, they are never GC'ed when I push the GC button. While OptimizeIT doesn't show the finalization thread holding a reference to them, I believe OptimizeIT 4.2 hides the java.lang.ref.Finalizer reference that points to your object. The reference inside java.lang.ref.Finalizer is actually inside a super class called java.lang.ref.Reference. Why I don't know? But, someone with OptimizeIT 4.1 said that they see more information than I do in OptimizeIT 4.2. Also when I do a show Outbound References I don't see the instance members for the super class. (Namely java.lang.ref.Reference.referent) Is anyone familiar enough with OptimizeIT as to why this is occuring?

Answer 1

>
Well thanks for the advice, jschell, but I am cleaning
up my connections by calling close(). But, keep the
great advice coming. I didn't think this forum had
quite enough worthless, cynical advice. For the
benefit of developers who read this forum for some
worth while advice. I'll post my findings.
Hmmmm...others seems to think my advice is worthwhile.
Some have even come to think that my advice is worthwhile after posting remarks like the one above.
What's really interesting about this problem is that
this has nothing to do with whether you call close()
or not. In fact, you could've called close() and
cleaned up properly, and your program could still leak
memory! It hinges on objects that implement the
finalize() method.
Your program, or third party libraries, or even the JVM can leak memory.
My JDBC vendor, like many, includes a finalize()
method in the implemention classes of Connection,
ResultSet, PreparedCall, etc. Naturally, this is to
clean up a connection when a programer has lost a
reference to a connection without calling close, but
it has a serious side effect.
Could be.
And your JDBC vendor would be?
I certainly know of JDBC vendors who do use finalize. Seems reasonable since the JDBC spec suggests it.
And I have used JDBC drivers that use it in 24x7 server operations and I have not traced a leak to those drivers yet.
So to my mind that suggests that finalize by itself is not a problem.
I've tested this will a class that simply does a wait()
call in its finalize() method. Then I allocate lots
of other objects that contain a finalize() method,
and watch the free memory fall. Just as a guess I would say that that is a really bad thing to do. My first guess would be that it would just lock up the JVM. Since it doesn't that would suggest that the JVM is creating one or more threads to call finalize.
Threads take memory.
And when you call wait you suspend those thread indefinitely.
So I would expect to see memory fall.
>
Seems like to me that it's better to leak memory, than
to try to clean up for the programmer. While
researching this problem I ran across a long post on
the .NET mailing list on finalization in .NET, and
they seem to say the same thing that Sun says which is
that the use of a finalize() method that the system
will call implicitly is a bad thing. You should
always use an explicit call like close().
I would guess that memory collection in .Net is going to be less robust than in java. It simply hasn't been around long enough.
While the fix for my problem is quite simple, remove
the finalize() method from the wrapper class. But, I
haven't run across any documenation on Sun's site or
the internet that has run across a memory leak quite
like this.
I however, have read, and participated in quite a few threads on this site where many people have suggested that you should never use finalize.
I think there are even a couple examples that show exactly how using finalize can generate memory leaks.