Br0kenB1ts | java.io.File.deleteOnExit() is evil
Non intuitively (but to be fair as stated in the javadoc!), once deletion has been requested, there is no way to cancel it, even if you delete the file!
The implementation of java.io.File.deleteOnExit() simply keeps a list of String representing all the files that need to be deleted when the VM exits. And this list grows and grows as the cat method is called (which in this specific scenario was every 15 seconds, so the leak took many weeks to manifest itself!).
Looking back at the issue and this specific java call, I actually do not see a real use for it and I have decided to ban it from my code for several reasons as I actually think it is evil:
- it gives you a false sense of security: "oh the VM will take care of it…" which is not true: if the VM does not terminate properly, for any particular reason (power outage,
kill -9,…) then the files will simply not be deleted. If your code relies on the fact that those files should not be present on VM restart then one day you will have a nasty surprise. - calling this method will eventually lead to a memory leak (granted of course it is called repeatedly, even if the frequency is very slow!)
In the end, dealing with files is hard. If you generate a lot of temporary files you need to delete them at some point or another or you will fill up the disk. It is not always easy to know when a temporary file is safe to be deleted, especially if a method creates it and returns it. I think this is where java.io.File.deleteOnExit() totally fails: it gives you the impression that it implements GC for files but as I mentionned before there are a lot of shortcommings.
Read full article from Br0kenB1ts | java.io.File.deleteOnExit() is evil
No comments:
Post a Comment