在测试虚拟硬盘的时候,查了一下基本的读取文件的方法,现在将各个方法列举如下,以及测试速度的时间,供大家作为参考,以后如果用到了,可选用合适的读取方式。
1. BufferedReader,BufferedWriter
这一种方法是实验室常用的一种方式,这种方式的好处是可以读取一行,然后针对每一行进行处理,他是构造一个缓冲流,然后进行读写,但是这种方法是相对比较慢的。
参考代码如下: 参数可以自己选用。
2. RandomAccessFile
这一种方法不常用,是随机读取的方式,这种方式比较特殊,他不隶属于InputStream,OutputStream类系,他是直接继承自Object类的。RandomAccessFile的工作方式是,把DataInputStream和DataOutputStream粘起来,再加上它自己的一些方法,比如定位用的getFilePointer( ),在文件里移动用的seek( ),以及判断文件大小的length( )。此外,它的构造函数还要一个表示以只读方式("r"),还是以读写方式("rw")打开文件的参数 (和C的fopen( )一模一样)。它不支持只写文件,从这一点上看,假如RandomAccessFile继承了DataInputStream,它也许会干得更好。
参考代码如下: 参数选择可以根据后边标记读写的进行选择,比如说第二个参数是"r",说明这是一个读文件的,如果是"rw",说明是写文件的。
3. FileInputStream,FileOutputSteam
这是一个最基本的读写文件的方式,这种读写一般是读取一个字节,或者定义长度的字节个数,如果为了节约时间的话,建议用缓冲区读写,这样速度会快一点。
参考代码如下: 参数和第一个选择一样。
4. 内存直接映射
这是一个内存直接映射读取的方式,如果文件大小合适,其他读取方式相对于他来说就是浮云啊,等一下我把各个大小的比对时间放上,大家应该可以看出来。但是这有一个限制,就是如果文件太大的话,映射内存会出现问题,要么就是内存不够,或者就是读取很慢,我觉得应该是文件太大,映射内存会出现不够的现象,然后内存会启动换入换出之类的,会浪费时间。但是基本的文件读写,他还是秒杀的。
参考代码如下: 参数同上。
下边我列出以下各个大小文件,各种读取方式所花费的时间,仅作参考。
表格里边我会用Buffer作为BufferedReader的简写,Random作为RandomAccessFile的简写,FileInput作为FileInputStream的简写,Map作为内存直接映射的简写。我给出两次测试结果。
除了BufferedReader之外,其他的读取时间基本上没有太大区别。
由以上图表可以看出,在文件大小一般的情况下,随着文件大小的增加,内存映射基本保持在1秒以下,基本0.2s左右,而其他的都会随着文件的增大有明显的变化,这就是内存直接映射秒杀的地方,但是就是文件增加到了998M之后,时间突然之间会增加很大,不知道是不是因为文件太大,以致于内存里边需要执行操作系统提供的一些保护算法而浪费时间了,这个有待考证,也可能是每次运行完之后没有清理内存,导致数据堵塞,因为内存映射方式,java没有提供相应的直接回收MappedByteBuffer区域的方法,这也会导致另外一种异常就是内存不够。
然后我在网上搜了两种解决方式,但是我自己也没有实验出来,代码是执行了,但是不知道从哪里看出他执行前后的区别。这里也把代码放上。
第一种方式: 第二种方式: 但是执行这个之后,会把时间拖慢,也是一个问题,所以这个问题待解决。
上边是我测试了几个方式的读取方式,这样以后实验室的使用读取文件的方式的时候,可以选用最适合的方式,如果时间是最紧要的,那么可以选用内存直接映射,但是这个要保证内存够用,而且文件合适的情况下,至于上边的那个问题,下边我会继续关注,如果谁了解了,欢迎提示~
如果谁熟悉其他的方式的,欢迎跟帖~
1. BufferedReader,BufferedWriter
这一种方法是实验室常用的一种方式,这种方式的好处是可以读取一行,然后针对每一行进行处理,他是构造一个缓冲流,然后进行读写,但是这种方法是相对比较慢的。
参考代码如下: 参数可以自己选用。
2. RandomAccessFile
这一种方法不常用,是随机读取的方式,这种方式比较特殊,他不隶属于InputStream,OutputStream类系,他是直接继承自Object类的。RandomAccessFile的工作方式是,把DataInputStream和DataOutputStream粘起来,再加上它自己的一些方法,比如定位用的getFilePointer( ),在文件里移动用的seek( ),以及判断文件大小的length( )。此外,它的构造函数还要一个表示以只读方式("r"),还是以读写方式("rw")打开文件的参数 (和C的fopen( )一模一样)。它不支持只写文件,从这一点上看,假如RandomAccessFile继承了DataInputStream,它也许会干得更好。
参考代码如下: 参数选择可以根据后边标记读写的进行选择,比如说第二个参数是"r",说明这是一个读文件的,如果是"rw",说明是写文件的。
3. FileInputStream,FileOutputSteam
这是一个最基本的读写文件的方式,这种读写一般是读取一个字节,或者定义长度的字节个数,如果为了节约时间的话,建议用缓冲区读写,这样速度会快一点。
参考代码如下: 参数和第一个选择一样。
4. 内存直接映射
这是一个内存直接映射读取的方式,如果文件大小合适,其他读取方式相对于他来说就是浮云啊,等一下我把各个大小的比对时间放上,大家应该可以看出来。但是这有一个限制,就是如果文件太大的话,映射内存会出现问题,要么就是内存不够,或者就是读取很慢,我觉得应该是文件太大,映射内存会出现不够的现象,然后内存会启动换入换出之类的,会浪费时间。但是基本的文件读写,他还是秒杀的。
参考代码如下: 参数同上。
下边我列出以下各个大小文件,各种读取方式所花费的时间,仅作参考。
表格里边我会用Buffer作为BufferedReader的简写,Random作为RandomAccessFile的简写,FileInput作为FileInputStream的简写,Map作为内存直接映射的简写。我给出两次测试结果。
除了BufferedReader之外,其他的读取时间基本上没有太大区别。
由以上图表可以看出,在文件大小一般的情况下,随着文件大小的增加,内存映射基本保持在1秒以下,基本0.2s左右,而其他的都会随着文件的增大有明显的变化,这就是内存直接映射秒杀的地方,但是就是文件增加到了998M之后,时间突然之间会增加很大,不知道是不是因为文件太大,以致于内存里边需要执行操作系统提供的一些保护算法而浪费时间了,这个有待考证,也可能是每次运行完之后没有清理内存,导致数据堵塞,因为内存映射方式,java没有提供相应的直接回收MappedByteBuffer区域的方法,这也会导致另外一种异常就是内存不够。
然后我在网上搜了两种解决方式,但是我自己也没有实验出来,代码是执行了,但是不知道从哪里看出他执行前后的区别。这里也把代码放上。
第一种方式: 第二种方式: 但是执行这个之后,会把时间拖慢,也是一个问题,所以这个问题待解决。
上边是我测试了几个方式的读取方式,这样以后实验室的使用读取文件的方式的时候,可以选用最适合的方式,如果时间是最紧要的,那么可以选用内存直接映射,但是这个要保证内存够用,而且文件合适的情况下,至于上边的那个问题,下边我会继续关注,如果谁了解了,欢迎提示~
如果谁熟悉其他的方式的,欢迎跟帖~
![](http://datamining.xmu.edu.cn/bbs/static/image/smiley/QQ/tongue.gif)