How to find out which thread is locking a file in java?

Question

I'm trying to delete a file that another thread within my program has previously worked with.

I'm unable to delete the file but I'm not sure how to figure out which thread may be using the file.

So how do I find out which thread is locking the file in java?

Files are lokced by process, not by thread. As has been mentioned, you must close a file before you can delete it. I suggest you start by looking at where the file is openned. — Peter Lawrey, Mar 21 '10 at 08:29

BalusC · Accepted Answer · 2016-06-13T08:28:41.570

I don't have a straight answer (and I don't think there's one either, this is controlled at OS-level (native), not at JVM-level) and I also don't really see the value of the answer (you still can't close the file programmatically once you found out which thread it is), but I think you don't know yet that the inability to delete is usually caused when the file is still open. This may happen when you do not explicitly call Closeable#close() on the InputStream, OutputStream, Reader or Writer which is constructed around the File in question.

Basic demo:

public static void main(String[] args) throws Exception {
    File file = new File("c:/test.txt"); // Precreate this test file first.
    FileOutputStream output = new FileOutputStream(file); // This opens the file!
    System.out.println(file.delete()); // false
    output.close(); // This explicitly closes the file!
    System.out.println(file.delete()); // true
}

In other words, ensure that throughout your entire Java IO stuff the code is properly closing the resources after use. The normal idiom is to do this in the try-with-resources statement, so that you can be certain that the resources will be freed up anyway, even in case of an IOException. E.g.

try (OutputStream output = new FileOutputStream(file)) {
    // ...
}

Do it for any InputStream, OutputStream, Reader and Writer, etc whatever implements AutoCloseable, which you're opening yourself (using the new keyword).

_{This is technically not needed on certain implementations, such as ByteArrayOutputStream, but for the sake of clarity, just adhere the close-in-finally idiom everywhere to avoid misconceptions and refactoring-bugs.}

In case you're not on Java 7 or newer yet, then use the below try-finally idiom instead.

OutputStream output = null;
try {
    output = new FileOutputStream(file);
    // ...
} finally {
    if (output != null) try { output.close(); } catch (IOException logOrIgnore) {}
}

Hope this helps to nail down the root cause of your particular problem.

What if you don't have control of the file handlers which were opened and left opened and still you want to delete the file ? — Anirudh Kashyap, Jan 14 '19 at 03:13

score 2 · Answer 2 · edited May 23 '17 at 11:52

About this question, I also try to find out this answer, and ask this question and find answer:

Every time when JVM thread lock a file exclusively, also JVM lock some Jave object, for example, I find in my case:

sun.nio.fs.NativeBuffer

sun.nio.ch.Util$BufferCache

So you need just find this locked Java object and analyzed them and you find what thread locked your file.

I not sure that it work if file just open (without locked exclusively), but I'm sure that is work if file be locked exclusively by Thread (using java.nio.channels.FileLock, java.nio.channels.FileChannel and so on)

How to find out which thread is locking a file in java?

2 Answers2

Linked