About causing too many open files with java?

Question

When review colleague's code , found below code

    BufferedReader br = new BufferedReader(new FileReader(PATH + fileName));
    //...

just read a file and concat these lines as a one line, but I do not found any close code, So I think it should cause resource leak，and finally cause too many open files error , so to prove this, I write a test

for (int i = 0; i < 7168; i++) { // ulimit -n ==> 7168
    BufferedReader br = new BufferedReader(new FileReader("src/main/resources/privateKey/foo.pem"));
    System.out.println(br.readLine());
}
System.in.read();

Very strange, everything is ok, does not throw expected exception.

And check the real opened files in command line

➜  ~ lsof -p 16276 | grep 'foo.pem' | wc -l
    2538

why is only 2538, not 7168?

So what's wrong? how to cause the too many open files error ?

As @GhostCat suggested, change 7168 --> Integer.MAX_VALUE, this time it caused

java.io.FileNotFoundException: src/main/resources/privateKey/foo.pem (Too many open files in system)
at java.io.FileInputStream.open0(Native Method)
at java.io.FileInputStream.open(FileInputStream.java:195)

when i is 27436, and in this case check the real opened files in command line is

➜  ~ lsof | grep foo.pem | wc -l
    7275

but where are left files(27346 - 7275)? and why ulimit number does not work?

I would start such an experiment using a `while(true)` loop ... and maybe print that counter into each file ... and also check what happens on the disk. — GhostCat, Apr 13 '17 at 14:32
And beyond that: you probably overlooked my suggestion: I would try opening different files for **writing**, and also write **different** content into each file. Unless my answer is totally bogus, it wouldn't surprise me if you find that your OS is somehow able to "optimize" on many read requests to the same file. But writing different stuff to different files is something that can't be optimized that easily. Let me know what comes out of this ;-) — GhostCat, Apr 13 '17 at 19:37

Stephen C · Accepted Answer · 2017-04-14T00:32:29.493

I presume that the garbage collector is running, finding lots of unreachable BufferedReader objects and collecting them. That causes the underlying stream objects to be finalized ... which closes them.

To make this code break, add the BufferedReader objects to a list, so that they remain reachable.

And here's why I think that changing 7168 to MAXINT is working.

When a JVM starts, it will use a relatively small heap. One of the things that happens during GC is that the JVM decides if it needs to resize the heap. So here is what could be happening:

The JVM starts with a heap that is too small to hold 7168 open files + BufferedReader objects. (Remember that each of the latter probably has a preallocated buffer!)
You start opening files.
At about N = 7168 - 2538, the heap fills up with all of the BufferedReader objects + FileInputStream objects + various detritus from JVM startup / warmup.
The GC runs, and causes a (probably) all of the BufferedReader objects to be collected / finalized / closed.
Then the GC decides that it needs to expand the heap. You now have enough heap space for more open BufferedReader objects than your ulimit allows.
You resume opening files ... and then hit the open file limit.

That's one possible pattern.

If you really want to investigate this, I advise you turn on GC logging, and see if you can correlate the number of FDs reported by lsof with GC runs.

(You could try adding sleep calls between each open to make it easier to get lsof measurements. But that could change the JVM behavior in other ways ...)

I don't think so, because each time execute `lsof` command got the same result. If gc involved the result would change, that is the value will become smaller till 0 — zhuguowei, Apr 13 '17 at 15:00
I'd agree with Stephen. But why don't you test it : override the BufferedReader, override finalize, see what happens... ? — GPI, Apr 13 '17 at 15:05
@zhuguowei - You are assuming that the GC runs all of the time. In fact, it only runs when needed; e.g. when a "space" fills up. So the behavior you propose would not happen. — Stephen C, Apr 14 '17 at 00:01

score 1 · Answer 2 · answered Apr 16 '17 at 09:09

jvm implicitly update ulimit value

String [] cmdArray = {"sh","-c","ulimit -n"};
Process p = Runtime.getRuntime().exec(cmdArray);
BufferedReader in = new BufferedReader(new InputStreamReader(p.getInputStream()));
System.out.println(in.readLine()); //it is 10240 not 7168

@Stephen C is right, GC involved.

I create a MyBufferedReader extends BufferedRead and override finalize method

@Override
protected void finalize() throws Throwable {
    System.out.printf("Thread: %s finalize it and total: %d %n",Thread.currentThread().getName(),count.getAndAdd(1));
}

Got below info

Thread: Finalizer finalize it and total: 9410

and in command line

➜  ~ lsof -p 5309 | grep 'taicredit_private_key_pkcs8' | wc -l
     830

and 9410 + 830 = 10240

score 0 · Answer 3 · answered Apr 13 '17 at 19:36

I don't have an exact explanation, but some additional thoughts: "we" have to understand that things aren't as simple as they look on the surface.

The point is: there are several layers of abstraction that come into play. There is the JVM and the JIT; and then there is the operating system below those.

Meaning: given those abstractions, it is simply too naive to expect that each new BufferReader directly leads to another file handle. It wouldn't surprise me if the Linux kernel kicks in here; and just "tells" the JVM that "yes, I opened that file; and read it for you; here is its content". But in "reality", the Linux kernel understands that this file wasn't touched and didn't change since the last read request ...

About causing too many open files with java?

3 Answers3