彻底转变流，第2部分：优化Java内部I/O - 编程入门网

彻底转变流，第2部分：优化Java内部I/O

虽然新的 Java I/O 框架（ java.nio ）能解决 I/O 支持所具有的多数性能 问题，但是它并没有满足使用字节数组和管道的应用程序内部通信的所有性能需 求。本文是分两部分的系列文章的最后一篇，Java 密码专家和作家 Merlin Hughes 开发了一组新的流，以补充标准的 Java I/O 字节数组流类和管道流类 ，在设计中强调以高性能为目标。请到关于本文的 讨论论坛，与作者和其他读 者分享您对本文的看法。（您也可以单击文章顶部或底部的 讨论。）

在 本系列的第一篇文章中，您学习了解决从只能写出数据的源读取数据的问 题的一些不同方法。在可能的解决方案中，我们研究了怎样使用字节数组流、管 道流以及直接处理该问题的定制框架。定制方法显然是最有效率的解决方案；但 是，分析其它几种方法有助于看清标准 Java 流的一些问题。具体地说，字节数 组输出流并不提供可提供对它的内容进行只读访问的高效机制，管道流的性能通 常很差。

为了处理这些问题，我们将在本文中实现功能同样齐全的替换类，但在实现 时更强调性能。让我们先来简要地讨论一下同步问题，因为它与 I/O 流有关。

同步问题

一般来说，我推荐在不是特别需要同步的情况下避免不必要地使用同步。显 然，如果多个线程需并发地访问一个类，那么这个类需确保线程安全。但是，在 许多情况下并不需要并发的访问，同步成了不必要的开销。例如，对流的并发访 问自然是不确定的 ― 您无法预测哪些数据被先写入，也无法预测哪个线程读了 哪些数据 ― 也就是说，在多数情况下，对流的并发访问是没用的。所以，对所 有的流强制同步是不提供实际好处的花费。如果某个应用程序要求线程安全，那 么通过应用程序自己的同步原语可以强制线程安全。

事实上，Collection 类的 API 作出了同样的选择：在缺省的情况下，set、 list 等等都不是线程安全的。如果应用程序想使用线程安全的 Collection，那 么它可以使用 Collections 类来创建一个线程安全的包装器来包装非线程安全 的 Collection。如果这种作法是有用的，那么应用程序可以使用完全相同的机 制来包装流，以使它线程安全；例如， OutputStream out = Streams.synchronizedOutputStream (byteStream) 。请参阅附带的 源代码中 的 Streams 类，这是一个实现的示例。

所以，对于我所认为的多个并发线程无法使用的类，我没用同步来为这些类 提供线程安全。在您广泛采用这种方式前，我推荐您研究一下 Java 语言规范（ Java Language Specification）的 Threads and Locks那一章（请参阅 参考资 料），以理解潜在的缺陷；具体地说，在未使用同步的情况下无法确保读写的顺 序，所以，对不同步的只读方法的并发访问可能导致意外的行为，尽管这种访问 看起来是无害的。

更好的字节数组输出流

当您需要把未知容量的数据转储到内存缓冲区时， ByteArrayOutputStream 类是使用效果很好的流。当我为以后再次读取而存储一些数据时，我经常使用这 个类。但是，使用 toByteArray() 方法来取得对结果数据的读访问是很低效的 ，因为它实际返回的是内部字节数组的副本。对于小容量的数据，使用这种方式 不会有太大问题；然而，随着容量增大，这种方式的效率被不必要地降低了。这 个类必须复制数据，因为它不能强制对结果字节数组进行只读访问。如果它返回 它的内部缓冲区，那么在一般的情况下，接收方无法保证该缓冲区未被同一数组 的另一个接收方并发地修改。

StringBuffer 类已解决了类似的问题；它提供可写的字符缓冲区，它还支持 高效地返回能从内部字符数组直接读取的只读 String 。因为 StringBuffer 类 控制着对它的内部数组的写访问，所以它仅在必要时才复

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!