论坛首页 → Java企业应用论坛 →

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

浏览 7884 次
锁定老帖子 主题：是Thread.sleep的问题还是IO的问题
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
  • seasons
  • 等级: 初级会员
  • 文章: 12
  • 积分: 40
  • 来自: 北京
   发表时间：2007-03-03  
最近在调查测试中的一个错误, 是这样的, jsp compiler如果设置forceGeneration的话,则不管jsp是否改变,都应该重新生成class文件.
但在linux上就时不时case会fail. 即两次生成的文件的timestamp相同了.

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

于是做了这么一个实验
java 代码
 
  1. package robin.test;  
  2.   
  3. import java.io.File;  
  4. import java.io.FileNotFoundException;  
  5. import java.io.FileOutputStream;  
  6. import java.io.IOException;  
  7. import java.io.OutputStream;  
  8.   
  9. public class FileTimeExam {  
  10.     private static final String FILENAME = "C:/1.txt";  
  11.   
  12.     public static void main(String[] args) throws InterruptedException {  
  13.         int n = 1;  
  14.         while (true) {  
  15.             System.out.println("=== n="+n+" ===");  
  16.               
  17.             File f1 = new File(FILENAME);  
  18.             writeFile(f1);  
  19.             long t1 = f1.lastModified();  
  20.             System.out.println("t1=" + t1);  
  21.   
  22.             Thread.sleep(300);  
  23.   
  24.             File f2 = new File(FILENAME);  
  25.             writeFile(f2);  
  26.             long t2 = f2.lastModified();  
  27.             System.out.println("t2=" + t2);  
  28.   
  29.             if (t1 == t2) {  
  30.                 System.out.println("time is the same");  
  31.                 return;  
  32.             }  
  33.   
  34.             n++;  
  35.               
  36.         }  
  37.     }  
  38.   
  39.     public static void writeFile(File f) {  
  40.         try {  
  41.             OutputStream o = new FileOutputStream(f);  
  42.             o.write(10);  
  43.             o.close();  
  44.         } catch (FileNotFoundException e) {  
  45.             e.printStackTrace();  
  46.         } catch (IOException e) {  
  47.             e.printStackTrace();  
  48.         }  
  49.     }  
  50. }  

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

开始觉得是文件没有flush, 但加了flush也没有改变.
看来问题是在sleep上, 也许是因为在linux上, java的Thread.sleep太不精确, 而这个写文件操作也比较快, 所以就没怎么sleep就进行了第二次文件写操作, 从而使两次timestamp相同.
但这个不好验证. 还不能确定是否根本原因.
返回顶楼
         
  • 歆渊
  • 等级: 二钻会员
  • 性别:
  • 文章: 424
  • 积分: 1219
   发表时间：2007-03-03  
文件系统记录文件访问时间一般都不是精确到毫秒的, 在原始的zip打包中甚至文件时间是两秒的整倍数.

这个问题很可能是 ext2 和 NTFS 文件系统的差别.
返回顶楼
          回帖地址
0 请登录后投票
  • vagrant1984
  • 等级: 初级会员
  • 文章: 42
  • 积分: 2
   发表时间：2007-03-03  
  在windows中也不是一直运行的，如文件系统为FAT32则t1==t2，如果为NTFS才能一直运行，why？
返回顶楼
          回帖地址
0 请登录后投票
  • seasons
  • 等级: 初级会员
  • 文章: 12
  • 积分: 40
  • 来自: 北京
   发表时间：2007-03-04  
zip打包有两秒的的误差, 是因为打zip包的函数有bug.
返回顶楼
          回帖地址
0 请登录后投票
  • 歆渊
  • 等级: 二钻会员
  • 性别:
  • 文章: 424
  • 积分: 1219
   发表时间：2007-03-04  
你可以把 File.lastModified(); 的返回值在不同文件系统上统计一下, 看看是不是都是一个单位时间的整倍数.
返回顶楼
          回帖地址
0 请登录后投票
  • seasons
  • 等级: 初级会员
  • 文章: 12
  • 积分: 40
  • 来自: 北京
   发表时间：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明确说明.
返回顶楼
          回帖地址
0 请登录后投票
  • xuehongliang
  • 等级: 初级会员
  • 性别:
  • 文章: 60
  • 积分: 74
  • 来自: 辽宁
   发表时间：2007-03-05  
哦,涨知识了!
返回顶楼
          回帖地址
0 请登录后投票
论坛首页 → Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics