Java NIO 学习：IO与CPU处理时间的关系

2019独角兽企业重金招聘Python工程师标准>>>

  我们在开发中，往往注重程序性能，代码优化，但是代码优化所带来的回报，可能轻易就被低效的 I/O 所抵销。 I/O 操作比在内存中进行数据处理任务所需时间更长。

  前三行显示了处理阶段的效率提升会如何影响吞吐率。把单位处理时间减半，仅能提高吞吐率2.2％。而另一方面，仅仅缩短 I/O 延迟 10％，就可使吞吐率增加 9.7％；把 I/O 时间减半，吞吐率几乎翻番。

  JAVA早期 JVM 在解释字节码时往往很少或没有运行时优化。这就意味着， Java 程序往往拖得很长，其运行速率大大低于本地编译代码，因而对操作系统 I/O 子系统的要求并不太高。现在 JVM 运行字节码的速率已经接近本地编译代码，借助动态运行时优化，其表现甚至还有所超越。这就意味着，多数 Java 应用程序已不再受 CPU 的束缚（把大量时间用在执行代码上），而更多时候是受 I/O 的束缚（等待据传数输）。

  操作系统与 Java 基于流的 I/O模型有些不匹配。操作系统要移动的是大块数据（缓冲区），这往往是在硬件直接存储器存取（ DMA）的协助下完成的。而 JVM 的 I/O 类喜欢操作小块数据——单个字节、几行文本。结果，操作系统送来整缓冲区的数据， java.io 的流数据类再花大量时间把它们拆成小块，往往拷贝一个小块就要往返于几层对象。操作系统喜欢整卡车地运来数据， java.io 类则喜欢一铲子一铲子地加工数据。有了 NIO，就可以轻松地把一卡车数据备份到您能直接使用的地方（ ByteBuffer 对象）。当然，并不是说传统的 I/O 模型无法移动大量数据。具体地说， RandomAccessFile 类在这方面的效率就不低，只要坚持使用基于数组的 read( )和 write( )方法。这些方法与底层操作系统调用相当接近，尽管必须保留至少一份缓冲区拷贝

转载于:https://my.oschina.net/HerrySun/blog/727757