|
锁定老帖子 主题：Java 文件监控，实时监控文件加载
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-10-20
theoffspring 写道 sziitjiang 写道 freezingsky 写道 java7想实现windows下的filewatch的功能，使用过，感觉确实不是很好，后来，通过JNI的方式，自己实现。楼主这种通过轮询的方式，在文件少的时候，还行，文件数量稍微多一些估计效率就很明显了。另外，common里，已有该功能的具体实现，不过，记得好像也是用轮询的方式来完成。
嗯，确实是轮循，当然大师级的代码跟我这个菜鸟级的代码肯定不一样，肯定是还有优化的空间的，谢谢，谢谢，呵呵...不过我没仔细研究common里面的代码是怎么样的，在公司上班的时候，技术总监跟我说，不要依赖于第三方的jar包，要自己去实现，呵呵，后来我就慢慢感觉不带第三方jar包的感觉真是爽，呵呵 这种人也能当上技术总监，他干嘛不直接写个spring,struts,hibernate 呵呵，他真有一个，云计算的，不过不开源 |
| 返回顶楼 | |
|
发表时间：2012-10-20
theoffspring 写道 sziitjiang 写道 freezingsky 写道 java7想实现windows下的filewatch的功能，使用过，感觉确实不是很好，后来，通过JNI的方式，自己实现。楼主这种通过轮询的方式，在文件少的时候，还行，文件数量稍微多一些估计效率就很明显了。另外，common里，已有该功能的具体实现，不过，记得好像也是用轮询的方式来完成。
嗯，确实是轮循，当然大师级的代码跟我这个菜鸟级的代码肯定不一样，肯定是还有优化的空间的，谢谢，谢谢，呵呵...不过我没仔细研究common里面的代码是怎么样的，在公司上班的时候，技术总监跟我说，不要依赖于第三方的jar包，要自己去实现，呵呵，后来我就慢慢感觉不带第三方jar包的感觉真是爽，呵呵 这种人也能当上技术总监，他干嘛不直接写个spring,struts,hibernate 呵呵，他真有一个，云计算的，不过不开源 |
| 返回顶楼 | |
|
发表时间：2012-10-20
第一反映就是收藏
强大的人类，顶楼主 |
| 返回顶楼 | |
|
发表时间：2012-10-20
122829827 写道 第一反映就是收藏
强大的人类，顶楼主 哈哈，灰常感谢，呵呵.... |
| 返回顶楼 | |
|
发表时间：2012-10-21
对于刚参加工作的工程师能写这样的代码，说明还是有相当的发展空间的，若能专注于技术，日后定能有所成就。
JDK7已经实现了file monitor的功能，jdk的开发小组说这个功能是基于jni实现的，而且依赖与文件系统是否有“主动通知”的功能，如果没有，就是采用轮询的方式。对于主流的文件系统来说，比如ntfs,ext3是支持“主动通知”的，如果在这些文件系统上使用jdk7的file monitor没有得到明显的改善，需要检查一下文件系统的该功能是否被关闭了。 楼主的代码中，用MD5比较来判断是否需要更新cache这种是中规中矩的，还可以从数据模型的层面上进行优化的空间。 另外，这个方案里一个重大的问题是MD5是如何得到的？因为没有仔细下载你的源码看，这里只提一点思路供楼主参考 1，如果MD5是通过java代码实现计算的，那这个时间的消耗是相当的大的，对于整个monitor的性能影响至关重要 2，如果MD5是外部计算然后输入的，这个解决方案在工程中的实际应用要受到很大的限制 |
| 返回顶楼 | |
|
发表时间：2012-10-21
sziitjiang 写道
先说说我设计的思路：启动一个不断循环的守护线程，不断检测某目录下的文件列表，并将这些文件名称和文件MD5校验码缓存起来，在下一个循环的时候直接从缓存中取出数据，进行对比，如果发现MD5校验不一样，说明文件被更新，
使用lastModified()，进行时间比较，可以检测出文件是否被更新。 |
| 返回顶楼 | |
|
发表时间：2012-10-22
代码挺多的，没有细读，觉得你那个run代码应该抽出来。一个方法里面代码太多，影响阅读
|
| 返回顶楼 | |
|
发表时间：2012-10-22
jimmycheng 写道 代码挺多的，没有细读，觉得你那个run代码应该抽出来。一个方法里面代码太多，影响阅读
嗯，对，run里面的代码多了，看起来就不爽，呵呵...楼上也有人提过这个建议，真是太对了，呵呵...3Q |
| 返回顶楼 | |
|
发表时间：2012-10-22
beidou321 写道
sziitjiang 写道
先说说我设计的思路：启动一个不断循环的守护线程，不断检测某目录下的文件列表，并将这些文件名称和文件MD5校验码缓存起来，在下一个循环的时候直接从缓存中取出数据，进行对比，如果发现MD5校验不一样，说明文件被更新，
使用lastModified()，进行时间比较，可以检测出文件是否被更新。 此法甚好，我去试试，测试一下性能怎么样，谢谢谢谢您的指点 |
| 返回顶楼 | |
|
发表时间：2012-10-22
Mojarra 写道 对于刚参加工作的工程师能写这样的代码，说明还是有相当的发展空间的，若能专注于技术，日后定能有所成就。
JDK7已经实现了file monitor的功能，jdk的开发小组说这个功能是基于jni实现的，而且依赖与文件系统是否有“主动通知”的功能，如果没有，就是采用轮询的方式。对于主流的文件系统来说，比如ntfs,ext3是支持“主动通知”的，如果在这些文件系统上使用jdk7的file monitor没有得到明显的改善，需要检查一下文件系统的该功能是否被关闭了。 楼主的代码中，用MD5比较来判断是否需要更新cache这种是中规中矩的，还可以从数据模型的层面上进行优化的空间。 另外，这个方案里一个重大的问题是MD5是如何得到的？因为没有仔细下载你的源码看，这里只提一点思路供楼主参考 1，如果MD5是通过java代码实现计算的，那这个时间的消耗是相当的大的，对于整个monitor的性能影响至关重要 2，如果MD5是外部计算然后输入的，这个解决方案在工程中的实际应用要受到很大的限制 谢谢您的指点，写了那么多呵呵.. 回答一下您的疑问,呵呵，MD5值是使用java自带的MessageDigest，性能不知道行不行，呵呵.. 关于从数据模型层面上优化，之前没怎么了解过，得去研究研究，非常感谢您的指点.... |
| 返回顶楼 | |
