If A has a reference to B, how did B become finalizable? Is it something like this?
root ---> A ---> B root ----> null (leaving A ---> B both stranded) Will the finalizer then consider both A and B eligilble for finalization? I always assumed A was then eligible for finalization, but B isn't. ~~ Robert. On Sat, Apr 2, 2011 at 4:15 AM, Xueming Shen <xueming.s...@oracle.com> wrote: > On 04-02-2011 12:47 AM, Xueming Shen wrote: >> >> On 4/1/2011 11:56 PM, Jeroen Frijters wrote: >>> >>> Xueming Shen wrote: >>>> >>>> I'm not a GC guy, so I might be missing something here, but if close() >>>> is being explicitly invoked by some thread, means someone has a strong >>>> reference to it, I don't think the finalize() can kick in until that >>>> close() returns >>> >>> This is not correct. You can re-publish the reference from another >>> finalizer method and thereby allow another thread to access the object >>> concurrently with the finalizer. >>> >>> Here's a possible sequence of events: >>> 1) GC runs and determines that A and B are finalizable >>> 2) Finalizer thread run A.finalize() >>> 3) A.finalize publishes reference to B in static variable >> >> Jeroen, are you talking about the object resurrection from finalize()? >> >> How do you re-publish/get the reference to B inside A.finalize()? I think >> you can do that inside >> B's finalize() to assign "this" to a global static variable. > > Jeroen, > > Guess I replied too quick. I think I got what you meant. A has a reference > to B, GC finalizes A > and B the same time, then A republish reference to B and let someone else to > invoke b.close().. > I would have to admit it's a possible use scenario:-) > > -Sherman > >> >> Regard, >> -Sherman >> >>> 4a) Another thread reads the static variable and calls B.close() >>> 4b) Finalizer thread runs B.finalize() >>> >>> Regards, >>> Jeroen >>> >> >> > >
