Files.readLines(new File(path), Charsets.UTF_8)FileUtils.readLines(new File(path))
这种方法带来的问题是文件的所有行都被存放在内存中,当文件足够大时很快就会导致程序抛出OutOfMemoryError 异常。
java读取txt文件内容。可以作如下理解:首先获得一个文件句柄。File file = new File()file即为文件句柄。两人之间连通电话网络了。接下来可以开始打电话了。
通过这条线路读取甲方的信息:new FileInputStream(file) 目前这个信息已经读进来内存当中了。接下来需要解读成乙方可以理解的东西
既然你使用了FileInputStream()。那么对应的需要使用InputStreamReader()这个方法进行解读刚才装进来内存当中的数据
解读完成后要输出呀。那当然要转换成IO可以识别的数据呀。那就需要调用字节码读取的方法BufferedReader()。同时使用bufferedReader()的readline()方法读取txt文件中的每一行数据哈。
优化一:采用内存硬盘(RamDisk)内存硬盘可以极大地提高文件的读写速度,行情的读写是应用内存硬盘的绝好情况:
1,可以把行情小站的行情文件地址配置在内存硬盘上。这样可以加速行情小站写文件的速度。
2,本系统再从内存硬盘读取,又可以加快读取速度。
3,内存硬盘掉电后会丢失文件,这里基本不在乎这个缺点,因为行情文件本来就是临时的,如果有持久化的需要,大部分内存硬盘也支持持久化的功能。
优化二:采用JNotify,用通知替代轮询由于行情小站会不断的更新行情dbf文件,系统需要探测到一旦行情文件被更新,就立即读取。传统的策略是不断轮询行情文件的状态,如果发现行情文件的最后修改日期(或者再加上文件大小)改变时,就认为文件被更新。但是这种方式既低效,时延又高且不稳定。假设即使把轮询时间设置为10ms一次(这意味着1秒钟就要轮询100次), 平均时延也要5ms。
JNotify库支持Windows,Linux和MacOS,允许监视一个文件夹,当这个文件夹下的文件被增删改时,发起回调通知。代码示例如下:
以上代码:
1,只要监视文件修改,因此只要设置mask = JNotify.FILE_MODIFIED
2,不需要递归地监视子目录,设置watchSubtree = false
3,由于监视的是文件夹,而不是文件,在fileModified方法中,要判断修改的是不是关心的文件(即行情文件),如果不是,则忽略。如果是,就调用readHangqingFile开始读取。
JNotify是基于 *** 作系统API实现的,即使用JNI实现的,因此除了jar文件,还包含.dll文件和.so文件。用eclipse开发时,需要指定这些本地库的目录,如下图所示:
部署时,需要将本地库放在执行根目录下,或者用-Djava.library.path=/native/library/path 指定本地库的位置。
采用JNotify,用(基于 *** 作系统的)通知而不是轮询,可以非常快地发现文件被更新,根据测试时间<1ms (我觉得应该远小于1ms,但是由于文件修改时间单位是毫秒,没办法更精确的测量)。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)