AsynchronousFileChannel.finalize()? (original) (raw)

Vitaly Davidovich vitalyd at gmail.com
Thu Mar 29 06:00:37 PDT 2012

Opening a new one per request will create mem churn plus involve a syscall to open the file (so user --> kernel transition, which isn't cheap, relatively speaking). You're right in that the actual i/o workload will probably not change due to page cache.

I say try out the simplest solution (new channel per request) and monitor performance; if you see an issue, try a refcounted approach and compare.

Sent from my phone On Mar 28, 2012 10:40 PM, "Zhong Yu" <zhong.j.yu at gmail.com> wrote:

You are right, we can't wait till GC to close a file; user code has to trigger close() asap.

In the use case, how much overhead can we really save by using a shared channel? If instead a new channel is opened for every new request, the added overhead won't be significant, considering OS caching, correct? If there's not much advantage to share a channel, my use case can be simply dismissed. Zhong Yu On Wed, Mar 28, 2012 at 7:16 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote: > Relying on finalization is far from ideal given its nondeterminism. It > seems like you may want to have a ref count associated with the channel, > which is checked during eviction. This will require some bookkeeping and > maybe locking in a few places, which may reduce throughput somewhat, but at > least you'll have full control and deterministic behavior. Just a thought > ... > > Sent from my phone > > On Mar 28, 2012 7:36 PM, "Zhong Yu" <zhong.j.yu at gmail.com> wrote: >> >> It appears that if close() is not invoked before an >> AsynchronousFileChannel becomes unreachable, the file handle remains >> open, and we get a resource leak. >> >> We can blame the programer for not properly closing the channel. >> However, would the nio team consider to add a feature anyway that will >> automatically invoke close() in finalize() (or something like >> sun.misc.Cleaner)? >> >> I have a use case where this feature could be helpful. A server has a >> file that's constantly requested by clients. The server opens one >> AsynchronousFileChannel and caches it. The same channel is used to >> serve all client requests to the file. When the server evicts the >> channel from the cache, it cannot immediately close() the channel >> right away, because the channel could still be referenced by request >> processors reading the file. The channel should be closed only after >> nobody references it. >> >> The point is that an AsynchronousFileChannel can be shared and >> accessed concurrently by multiple users; then it is difficult to >> pre-assign a user with the responsibility of closing the channel. It >> should be the last user that uses the channel - which is better >> handled in JDK. >> >> (In comparison, FileInputStream/FileChannel should have only one user >> at any given time, therefore it's clear who is responsible to do the >> close(). I wouldn't request the feature on these two classes.) >> >> Zhong Yu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120329/c400cf79/attachment.html

More information about the nio-dev mailing list