2 ms·
If you are leaking file descriptors in a production service it will absolutely break things. Generally most servers that aren't pushing the FD limit can get awa
by kevincox 5y ago
If you are leaking file descriptors in a production service it will absolutely break things. Generally most servers that aren't pushing the FD limit can get away with delayed reclamation of FDs but if you never claim them you will run into problems.
Plus most code probably handles this poorly. I suspect it will often result in exceptions opening new files or connection which are just caught and retried forever, resulting in your server locking up after some period of time. If you are lucky it just crashes and restarts. (The ultimate garbage collection.)
- mmastrac 5y agoI believe reference queues are the way to go about this now. Once you wrap your brain around them, it's far simpler to reason about. The only really issue is that you effectively need to litter your code with queue checks, or dedicate a thread to watching them.
- papercrane 5y agoYou can use the Cleaner API instead. It's pretty straightforward to use. https://download.java.net/java/early_access/jdk18/docs/api/java.base/java/lang/ref/Cleaner.html https://download.java.net/java/early_access/jdk18/docs/api/j...
- mmastrac 5y agoThanks for the pointers - my Java knowledge is apparently out-of-date!
- kaba0 5y agoJava has the Cleaner API as a possible solution for this. (Also, try-with-resources is really great generally) But I agree with you, it is anecdotically a problem for me right now as well: intellij under osx can’t index/import a bigger work project due to getting too many files IO exceptions all around, even though I tried increasing both the system limit, the java vm flag, everything..