首先说本机的性能,采用AS SSD Benchmark进行评测,写入能力大约在422M每秒,计划连续写入文本数据,直到达到要求为止(5G数据与10G数据),测试环境如下:
环境 | 版本 |
---|---|
JDK | 1.8.0_131 |
操作系统 | Windows 10 专业版 x64 |
CPU | Inter i7-3740QM |
内存 | 16G |
硬盘 | 三星512G SSD |
原以为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();
}
几乎所有的人都推荐,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 --;
}
从这里来看,跟BIO相比,NIO性能提升并不明显。
在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设置10G
for(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();
在这里需要强调的一点是,文件大小的速度不能增长太快,否则必然出现“IllegalArgumentException”错误,这也是上述代码中需要划分多次循环的原因。
早就听说直接内存映射提升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();
当然,性能提升的代价也是很明显的,内存消耗至少增加了2G(直接内存,不是JAVA堆内存),而前面的方法内存消耗都很少,大多只在30M左右。
直接内存映射、直接缓冲区都能提升IO写入的性能,背后的核心技术还是分页技术(请参加操作系统原理),如何组织分页的范围与写入的频次,是提升性能的关键,另外,写入对内存与CPU性能消耗都不高。