Digging Through a Bug in the JDK Monitoring File

Dealing with unexpected bugs

Photo by Kevin Bhagat on Unsplash

In some business scenarios, we need to implement the function of monitoring file content changes by ourselves, such as monitoring whether a file has changed, and reloading the content of the file when it changes.

It seems to be a relatively simple function, but under certain JDK versions, unexpected bugs may appear.

This article will take you to a simple implementation of a corresponding function, and analyze the corresponding bugs and advantages and disadvantages.

To monitor file changes and read files, the simple idea is as follows:

• Start a single thread and regularly obtain the timestamp of the last update of the file (unit: milliseconds)
• Compare the last time stamp, if it is inconsistent, it means that the file has been changed, and then reload

Here is a demo of a simple function implementation (excluding the timed task part):

In the above code, first, create a file (convenient for testing), then read the modification time of the file twice, and record the last modification time with LAST_TIME.

If the latest change time of the file is inconsistent with the last time, the modification time is updated and business processing is performed.

The for loop twice in the sample code is to demonstrate the two cases of change and no change.

Execute the program and print the log as follows:

File has been updated: xxxxxxx
file not updated

The execution result is as expected.

This solution obviously has two disadvantages:

It is impossible to perceive the changes in files in real-time. After all, there is a time difference in program rotation;

The time unit returned by lastModified in milliseconds. If two changes occur in the same millisecond, and the scheduled task…