彻底转变流，第1部分 - 编程入门网

public void close () { 　　　 eof = true; 　　 } 　 } }

敏感的读者可能注意到我应该将 writeImpl() 方法的主体直接放在输出流实 现中：内部类有权访问所有包含类的私有成员。然而，对这些字段的内部类访问 比由包含类的直接方法的访问在效率方面稍许差一些。所以，考虑到效率以及为 了使类之间的相关性最小化，我使用额外的助手方法。

应用工程解决方案：在读取期间压缩数据

清单 19 演示了这个类框架的使用来解决我最初的问题：在我读取数据时压 缩它们。该解决方案归结为创建一个与输入流相关联的 IOStreamEngine 和一个 GZIPOutputStreamFactory ，然后将 OutputEngineInputStream 与这个 GZIPOutputStreamFactory 相连。自动执行流的初始化和连接，然后可以直接从 结果流中读取压缩数据。当处理完成且关闭流时，输出引擎自动关闭，并且它关 闭初始输入流。

清单 19. 应用工程解决方案

private static InputStream engineCompress (InputStream in) 　　　 throws IOException { 　　 return new OutputEngineInputStream 　　　 (new IOStreamEngine (in, new GZIPOutputStreamFactory ())); 　 }

虽然为解决这类问题而设计的解决方案应该产生十分清晰的代码，这一点没 有什么可惊奇的，但是通常要充分留意以下教训：无论问题大小，应用良好的设 计技术都几乎肯定会产生更为清晰、更便于维护的代码。

测试性能

从效率看， IOStreamEngine 将数据读入其内部缓冲区，然后通过压缩过滤 器将它们写入 OutputStreamImpl 。这将数据直接写入 OutputEngineInputStream ，以便它们可供读取。总共只执行两次缓冲区复制， 这意味着我应该从管道式流解决方案的缓冲区复制效率和蛮力解决方案的无线程 效率的结合中获益。

要测试实际的性能，我编写了一个简单的测试工具（请参阅所附 资源中的 test.PerformanceTest ），它使用这三个推荐的解决方案，通过使用一个空过 滤器来读取一块哑元数据。在运行 Java 2 SDK，版本 1.4.0 的 800 MHz Linux 机器上，达到了下列性能：

管道式流解决方案

15KB：23ms；15MB：22100ms

蛮力解决方案

15KB：0.35ms；15MB：745ms

工程解决方案

15KB：0.16ms；15MB：73ms

该问题的工程解决方案很明显比基于标准 Java API 的另两个方法都更有效 。

顺便提一下，考虑到如果输出引擎能够遵守这样的约定：在将数据写入其输 出流后，它不修改从中写入数据的数组而返回，那么我能提供一个只使用一次缓 冲区复制操作的解决方案。可是，输出引擎很少会遵守这种约定。如果需要，输 出引擎只要通过实现适当的标记程序接口，就能宣称它支持这种方式的操作。

彻底转变流，第1部分(11)

应用工程解决方案：读取编码的字符数据

任何可以用“提供对将数据反复写入 OutputStream 的实体的读访问权”表 述的问题，都可以用这一框架解决。在这一节和下一节中，我们将研究这样的问 题示例及其有效的解决方案。

首先，考虑要读取 UTF-8 编码格式的字符流的情况： InputStreamReader 类让您将以二进制编码的字符数据作为一系列 Unicode 字符读取；它表示了从 字节输入流到字符输入流的关口。 OutputStreamWriter 类让您将一系列二进制 编码格式的 Unicode 字符写入输出流；它表示从字符输出流到字节输入流的关 口。 String 类的 getBytes() 方法将字符串转换成经编码的字节数组。然而， 这些类中没有一个能直接让您读取 UTF-8 编码格式的字符流。

清单 20 到 24 中的代码演示了以与 IOStreamEngine 类极其相似的方式使 用 OutputEngine 框架的一种解决方案。我们并不是从输入流读取和通过输出流 过滤器进行写操作，而是从字符流读取，并通过所选的字符

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