最近工作用到windows 访问共享目录,进行文件操作。途中遇到很多问题,在当初开始写代码的时候觉得没什么问题,
一旦线上大规模测试,问题就暴露出来;把遇到的问题总结下:
1、同一个文件的读写同时问题:
相信很多人都遇到过,在去读取一个文件的时候发现读取出错或者读取的并不是一个全文件,
而只是一部分; 特别是在分布式的情况下,当A线程往这个文件里面写内容,另一个B线程从
这个文件读取内容,文件被A占用后,其他线程就只能读, 在windows共享访问
(非商用下载工具,没测试过)的情况下,读取出来的就是部分内容。如果这时还有
C线程想往文件中写入,就会出错。
而判断一个文件是否读写完成 就通过file.renameTo 来判断,为true或者false 代表是否被占用与否;
2、共享文件夹的访问量问题:
在我们的程序中,对共享文件夹的访问是大数据量频繁访问,偶尔就会出现 “网络名不再可用”,
相信很多人在百度里面搜索一下都能看到很多, 这里所说的和网站上看到的还是有点关联;
首先,出现这个问题,说明网络共享文件夹的网络名称对外不可用,举一个最简单的例子就是(公司用
内网大部分都是局域网通过宽带接入,路由分配ip 然后pc获得ip连接上网,如果带宽为4M,
但是公司内容有几个同事开了p2p 把带宽占完了,其他人能连接上本地,但是也访问不了外网);
这里网络名不可用在我分析就是一个道理。由于线程访问数过多,加上内部网络的各种因数,
很可能出现这种情况。
采取措施:A、做好异常处理机制: 所有与网络共享文件夹访问有关的地方都加上异常处理,如果出错,
想好下步action(既然是不可避免的问题,那就去解决吧)
B、网络上有设置“客户端和服务器的并发命令的数量上限限制”,这个能解决一些小并发量得问题;
但是大并发量频繁操作的话,还是要出现网络名不可用 的情况;
C、增加共享文件夹的数量:比如之前是从一个文件夹下面读取数据, 限制设置为两个分别在
不同的ip下,降低每个共享文件夹的访问流量压力;但是为了 防止大文件比较集中的情况,
导致访问线程数一个时间段内过高,共享文件夹访问压力大,还是要对共享文件夹访问加上
异常处理机制。
个人小体会,欢迎大家喷墨