首先给大家分享一个巨牛巨牛的人工智能教程,是我无意中发现的。教程不仅零基础,通俗易懂,而且非常风趣幽默,还时不时有内涵段子,像看小说一样,哈哈~我正在学习中,觉得太牛了,所以分享给大家!点这里可以跳转到教程
首先说本机的性能,采用AS SSD Benchmark进行评测,写入能力大约在422M每秒,计划连续写入文本数据,直到达到要求为止(5G数据与10G数据),测试环境如下:
环境 | 版本 |
---|---|
JDK | 1.8.0_131 |
操作系统 | Windows 10 专业版 x64 |
CPU | Inter i7-3740QM |
内存 | 16G |
硬盘 | 三星512G SSD |
1. FileOutputStream与BufferedWriter
原以为FileOutputStream的性能会很低,BufferedWriter会有一定的性能提升,但结果却让我大吃一惊,测试数据如下:
测试编次 | 采用方式 | 文件大小 | 花费时间(秒) |
---|---|---|---|
1 | BufferedWriter | 4.5G | 10.678399057 |
2 | BufferedWriter | 4.5G | 10.808078377 |
3 | FileOutputStream | 4.5G | 9.755711962 |
4 | FileOutputStream | 4.5G | 9.457581885 |
BufferedWrirter竟然还稍稍慢于FileOutputStream,并且FileOutputStream的性能如此惊人,已经完全达到了硬盘的性能巅峰,这说明JAVA的IO优化还是令人非常满意的,相关代码如下:
// FileOutputStream的写入方式类似,在此略static void writeBuffer(File file) throws IOException { FileOutputStream fos = new FileOutputStream(file); BufferedWriter writer = new BufferedWriter(new OutputStreamWriter(fos)); int i = 1000000; while(i > 0) { // word2048为字符串常量,刚好4800个字节 writer.write(word2048); i --; } writer.close(); fos.close();}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
2. ByteBuffer与直接缓冲区
几乎所有的人都推荐,nio性能极佳,那真实的性能到底怎样?
文件大小 | 采用方式 | 花费时间(秒) |
---|---|---|
4.5G | 采用直接内存 | 8.598730553 |
4.5G | 不采用直接内存 | 8.581370111 |
从上面的数据可以看出,采用ByteBuffer后,性能约有10%的提升,但令人惊讶的,采不采用直接缓冲区竟然没有差异,这与理论推测又有显著差异(具体请参见《JAVA NIO》第45页),在这里还有一个可优化的地方,如何选择ByteBuffer的大小是决定写入速度的关键,相关代码如下:
FileOutputStream fos = new FileOutputStream(file);FileChannel fc = fos.getChannel();// 此数字可优化int times = 100;// word2048为字符串常量,刚好4800个字节byte[] datas = word2048.getBytes();ByteBuffer bbuf = ByteBuffer.allocate(4800 * times);int i = 10000;while(i > 0) { for(int j = 0; j < times; j++) { bbuf.put(datas); } bbuf.flip(); fc.write(bbuf); bbuf.clear(); i --;}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
从这里来看,跟BIO相比,NIO性能提升并不明显。
3. FileChannel与文件空洞
在nio中,FileChannel可以决定文件的写入位置,这也是能产生文件空洞的主要方法,那么这样,产生大量的文件空洞,是否能加快文件的创建速度呢?
文件大小 | 采用方式 | 花费时间 |
---|---|---|
5.1G | 改变Channel Position 步进2 | 13.214593475S |
11G | 改变Channel Position 步进2 | 25.849560829S |
可以看出,写入速度主要还是受限与磁盘IO,即使少写数据,依旧不能提升速度,反而还有较大幅度的下降,相关代码如下:
FileOutputStream fos = new FileOutputStream(file);FileChannel fc = fos.getChannel();ByteBuffer bbuf = ByteBuffer.allocateDirect(1024);long value = 10 * 1024 * 1024;// 为什么不一步到位?直接将position设置10Gfor(int i = 1; i < 1025; i = i * 2) { bbuf.put((byte)1); bbuf.flip(); fc.position(i * value); fc.write(bbuf); bbuf.clear();}fc.close();fos.close();
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
在这里需要强调的一点是,文件大小的速度不能增长太快,否则必然出现“IllegalArgumentException”错误,这也是上述代码中需要划分多次循环的原因。
4. 惊人的MappedByteBuffer
早就听说直接内存映射提升IO性能惊人,那到底有多惊人呢?请看测试数据:
文件大小 | 采用方式 | 花费时间(秒) |
---|---|---|
4.5G | 内存映射 | 2.537650656 |
9G | 内存映射 | 5.303423243 |
跟前面的最快的NIO方法相比,性能竟然提升了244%,写入速度竟然达到了1.8G每秒,这是怎么做到的?相关代码如下:
// 必须采用RandomAccessFile,并且是rw模式RandomAccessFile acf = new RandomAccessFile(file, "rw");FileChannel fc = acf.getChannel();byte[] bs = word2048.getBytes();int len = bs.length * 1000;long offset = 0;int i = 2000000;while(i > 0) { MappedByteBuffer mbuf = fc.map(FileChannel.MapMode.READ_WRITE, offset, len ); for(int j = 0; j < 1000; j ++) { mbuf.put(bs); } offset = offset + len; i = i - 1000;}fc.close();
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
当然,性能提升的代价也是很明显的,内存消耗至少增加了2G(直接内存,不是JAVA堆内存),而前面的方法内存消耗都很少,大多只在30M左右。
5. 其他的现象
- 同样的文件名,删除了再创建,速度又有10~20%的提升;
- 字符串转换为字节数组的速度极快,比直接写入字符串的速度更快,这也是BufferedWrirter比FileOutputStream慢的原因;
结论
直接内存映射、直接缓冲区都能提升IO写入的性能,背后的核心技术还是分页技术(请参加操作系统原理),如何组织分页的范围与写入的频次,是提升性能的关键,另外,写入对内存与CPU性能消耗都不高。