是Thread.sleep的问题还是IO的问题

最近在调查测试中的一个错误, 是这样的, jsp compiler如果设置forceGeneration的话,则不管jsp是否改变,都应该重新生成class文件.
但在linux上就时不时case会fail. 即两次生成的文件的timestamp相同了.

跟踪code发现确实做了写class文件这个动作. 也就是说jsp compiler的逻辑没问题.

于是做了这么一个实验

java 代码

package robin.test;

import java.io.File;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.OutputStream;

public class FileTimeExam {
    private static final String FILENAME = "C:/1.txt";

    public static void main(String[] args) throws InterruptedException {
        int n = 1;
        while (true) {
            System.out.println("=== n="+n+" ===");

            File f1 = new File(FILENAME);
            writeFile(f1);
            long t1 = f1.lastModified();
            System.out.println("t1=" + t1);

            Thread.sleep(300);

            File f2 = new File(FILENAME);
            writeFile(f2);
            long t2 = f2.lastModified();
            System.out.println("t2=" + t2);

            if (t1 == t2) {
                System.out.println("time is the same");
                return;
            }

            n++;

        }
    }

    public static void writeFile(File f) {
        try {
            OutputStream o = new FileOutputStream(f);
            o.write(10);
            o.close();
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

这个程序在Windows下能一直运行下去, 就是说两次文件的lastmodify的timestamp不同, 但在linux下则很快就停下来了.
但如果把那个Thread.sleep改成3000的话, 就可以一直run了.

开始觉得是文件没有flush, 但加了flush也没有改变.
看来问题是在sleep上, 也许是因为在linux上, java的Thread.sleep太不精确, 而这个写文件操作也比较快, 所以就没怎么sleep就进行了第二次文件写操作, 从而使两次timestamp相同.
但这个不好验证. 还不能确定是否根本原因.

评论

6 楼 xuehongliang 2007-03-05  

哦,涨知识了!

5 楼 seasons 2007-03-04  

最后查了一下,确实应该是跟文件系统有关系.
在SUN的JDK bug 4697792上说明了这个情况:
Without having a good reference source:  FAT12, FAT16, and FAT32 file systems have a 2 second file time resolution.  NTFS has a 100 nanosecond file time resolution.  Unix/Linux has a 1 second file time resolution.

So - depending on the underlying system, the values will either be accurate to the millisecond (NTFS) or rounded to the nearest 2 second (FAT32).

不过这也不能完全说是SUN JDK的bug,应该是SUN DOC上的bug,没有把这个limitation明确说明.

4 楼 歆渊 2007-03-04  

你可以把 File.lastModified(); 的返回值在不同文件系统上统计一下, 看看是不是都是一个单位时间的整倍数.

3 楼 seasons 2007-03-04  

zip打包有两秒的的误差, 是因为打zip包的函数有bug.

2 楼 vagrant1984 2007-03-03  

  在windows中也不是一直运行的，如文件系统为FAT32则t1==t2，如果为NTFS才能一直运行，why？

1 楼 歆渊 2007-03-03  

文件系统记录文件访问时间一般都不是精确到毫秒的, 在原始的zip打包中甚至文件时间是两秒的整倍数.

这个问题很可能是 ext2 和 NTFS 文件系统的差别.