彻底转变流，第2部分：优化Java内部I/O - 编程入门网
| gzip = new GZIPOutputStream (sink);
Streams.io (in, gzip);
gzip.close ();
} catch (IOException ex) {
try {
sink.setException (ex);
} catch (IOException ignored) {
}
}
}
}.start ();
return source;
}
性能结果 在下面的表中显示的是这些新的流和标准流的性能，测试环境是运行 Java 2 SDK，v1.4.0 的 800MHz Linux 机器。性能测试程序与我在上一篇文章中用的相 同： 管道流 15KB：21ms；15MB：20675ms 新的管道流 15KB：0.68ms；15MB：158ms 字节数组流 15KB：0.31ms；15MB：745ms 新的字节数组流 15KB：0.26ms；15MB：438ms 与上一篇文章中的性能差异只反映了我的机器中不断变化的环境负载。您可 以从这些结果中看到，在大容量数据方面，新的管道流的性能远好于蛮力解决方 案；但是，新的管道流的速度仍然只有我们分析的工程解决方案的速度的一半左 右。显然，在现代的 Java 虚拟机中使用多个线程的开销远比以前小得多。 结束语 我们分析了两组可替代标准 Java API 的流的流： BytesOutputStream 和 BytesInputStream 是字节数组流的非同步替代者。因为这些类的预期的用例涉 及单个线程的访问，所以不采用同步是合理的选择。实际上，执行时间的缩短（ 最多可缩短 40%）很可能与同步的消灭没有多大关系；性能得到提高的主要原因 是在提供只读访问时避免了不必要的复制。第二个示例 PipeInputStream 可替 代管道流；为了减少超过 99% 的执行时间，这个流使用宽松的约定、改进的缓 冲区大小和基于数组的操作。在这种情况下无法使用不同步的代码；Java 语言 规范排除了可靠地执行这种代码的可能性，否则，在理论上是可以实现最少锁定 的管道。 字节数组流和管道流是基于流的应用程序内部通信的主要选择。虽然新的 I/O API 提供了一些其它选择，但是许多应用程序和 API 仍然依赖标准流，而 且对于这些特殊用途来说，新的 I/O API 并不一定有更高的效率。通过适当地 减少同步的使用、有效地采用基于数组的操作以及最大程度地减少不必要的复制 ，性能结果得到了很大的提高，从而提供了完全适应标准流框架的更高效的操作 。在应用程序开发的其它领域中采用相同的步骤往往能取得类似地性能提升。 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
