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

Vitaly Davidovich vitalyd at gmail.com
Wed Mar 28 17:16:45 PDT 2012

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/20120328/1e6e4731/attachment.html

More information about the nio-dev mailing list