首先说本机的性能，采用AS SSD Benchmark进行评测，写入能力大约在422M每秒，计划连续写入文本数据，直到达到要求为止(5G数据与10G数据)，测试环境如下：
原以为FileOutputStream的性能会很低，BufferedWriter会有一定的性能提升，但结果却让我大吃一惊，测试数据如下：
BufferedWrirter竟然还稍稍慢于FileOutputStream，并且FileOutputStream的性能如此惊人，已经完全达到了硬盘的性能巅峰，这说明JAVA的IO优化还是令人非常满意的，相关代码如下：
几乎所有的人都推荐，nio性能极佳，那真实的性能到底怎样？
从上面的数据可以看出，采用ByteBuffer后，性能约有10%的提升，但令人惊讶的，采不采用直接缓冲区竟然没有差异，这与理论推测又有显著差异(具体请参见《JAVA NIO》第45页)，在这里还有一个可优化的地方，如何选择ByteBuffer的大小是决定写入速度的关键，相关代码如下：
从这里来看，跟BIO相比，NIO性能提升并不明显。
在nio中，FileChannel可以决定文件的写入位置，这也是能产生文件空洞的主要方法，那么这样，产生大量的文件空洞，是否能加快文件的创建速度呢？
可以看出，写入速度主要还是受限与磁盘IO，即使少写数据，依旧不能提升速度，反而还有较大幅度的下降，相关代码如下：
在这里需要强调的一点是，文件大小的速度不能增长太快，否则必然出现“IllegalArgumentException”错误，这也是上述代码中需要划分多次循环的原因。
早就听说直接内存映射提升IO性能惊人，那到底有多惊人呢？请看测试数据：
跟前面的最快的NIO方法相比，性能竟然提升了244%，写入速度竟然达到了1.8G每秒，这是怎么做到的？相关代码如下：
当然，性能提升的代价也是很明显的，内存消耗至少增加了2G（直接内存，不是JAVA堆内存），而前面的方法内存消耗都很少，大多只在30M左右。
- 同样的文件名，删除了再创建，速度又有10～20%的提升；
- 字符串转换为字节数组的速度极快，比直接写入字符串的速度更快，这也是BufferedWrirter比FileOutputStream慢的原因；
直接内存映射、直接缓冲区都能提升IO写入的性能，背后的核心技术还是分页技术(请参加操作系统原理)，如何组织分页的范围与写入的频次，是提升性能的关键，另外，写入对内存与CPU性能消耗都不高。
到此这篇bytebuffer（Bytebuffer 性能）的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/hd-xnyh/37178.html