Take the 2-minute tour ×

I'm chasing a production bug that's intermittent enough to be a real bastich to diagnose properly but frequent enough to be a legitimate nuisance for our customers. While I'm waiting for it to happen again on a machine set to spam the logfile with trace output, I'm trying to come up with a theory on what it could be.

Is there any way for competing file read/writes to create what amounts to a deadlock condition? For instance, let's say I have Thread A that occasionally writes to config.xml, and Thread B that occasionally reads from it. Is there a set of circumstances that would cause Thread B to prevent Thread A from proceeding?

My thanks in advance to anybody who helps with this theoretical fishing expedition.

Edit: To answer Pyrolistical's questions: the code isn't using FileLock, and is running on a WinXP machine. Not asked, but probably worth noting: The production machines are running Java 1.5.

share|improve this question
Do you know what the thread stack looks like when it hangs? You can use jvisualvm to attach to the hung jvm and dump the thread stack. –  Devon_C_Miller Apr 8 '10 at 18:28
Are you using FileLock? If not then I think you'll get partial reads or errors but never deadlock. Also this is OS and FS dependent –  Pyrolistical Apr 8 '10 at 18:29
@Devon: No, I don't. I'm not familiar with jvisualvm, but based on a quick trip to Google, this is clearly something I need to correct, thanks! @Pyrolistical: Nope, not using FileLock, and the code is running under WinXP. –  BlairHippo Apr 8 '10 at 18:42
Do you use buffered I/O or unbuffered I/O? What makes you so sure it is the file access that causes the deadlock? –  rsp Apr 8 '10 at 18:45
You can use a tool called JConsole to detect deadlock and find out which threads are causing deadlock (plus their stacktrace). It's included with the JDK, I believe. You can connect to your live running app without changing the startup parameters, too. –  Jonathon Faust Apr 8 '10 at 18:54

4 Answers 4

Temporarily setup your production process to startup with debugging support, add this to how you're starting your java program or to say the tomcat startup:


Then attach to it:

jdb -connect com.sun.jdi.SocketAttach:hostname=localhost,port=8000

And take a look at your stack(s).

share|improve this answer

FileLock is an inter-process locking mechanism. It does nothing within the same JVM, so that isn't it. I would look at your synchronizations, and specifically at making sure you always acquire multiple locks in the same order.

share|improve this answer
up vote 0 down vote accepted

I've gotten some useful tips for chasing the underlying bug, but based on the responses I've gotten, it would seem the correct answer to the actual question is:


Damn. That was anti-climactic.

share|improve this answer

I know this is old, but to add some clarity on a "No" answer (for those of us who need to know why):

Deadlocking happens when exactly two distinct processes (transactions) update alternate dependent rows or records, but in reverse order. Basically both hang waiting for the other to complete an action which will never occur (as they are both waiting on the other). This is generally found in faulty database design.

If I recall, Wikipedia has a good definition here: http://en.wikipedia.org/wiki/Deadlock

Simple file access should not create dependencies like this. A more common issue would be your resource being used by another process and unavailable to the one trying to access it.

share|improve this answer

Your Answer


