Java 流io和块io

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

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

然而，在大多数情况下，Java 应用程序并非真的受着 I/O 的束缚。操作系统并非不能快速传送数据，让 Java 有事可做；相反，是 JVM 自身在 I/O 方面效率欠佳。 操作系统与 Java 基于流的 I/O模型有些不匹配。操作系统要移动的是大块数据（缓冲区），这往往是在硬件直接存储器存取（DMA）的协助下完成的。而 JVM 的 I/O 类喜欢操作小块数据——单个字节、几行文本。结果，操作系统送来整缓冲区的数据，java.io 的流数据类再花大量时间把它们拆成小块，往往拷贝一个小块就要往返于几层对象。操作系统喜欢整卡车地运来数据，java.io 类则喜欢一铲子一铲子地加工数据。有了 NIO，就可以轻松地把一卡车数据备份到您能直接使用的地方（ ByteBuffer 对象）。 

1)面向流I/O的系统：一次处理一个字节的数据。一个输入流每次会读入一个字节的数据，一个输出流同样每次次消费一个字节的数据。对于流式数据，很容易创建过滤器。可以相对简单地把几个过滤器连接在一起，每个过滤器完成自己的工作，也是按字节进行过滤，精细的处理机制。另一方面，面向流I/-O的通信往往比较缓慢。 


2)面向块I/O的系统：以块为单位处理数据。每个操作步骤会生成或消费一个块的数据。以块为单位处理数据，其处理速度远快于以字节流为单位的方式。但是，与面向流I/O的通信相比，面向块I/O的通信缺乏优雅和简洁。 

新的抽象把重点放在了如何缩短抽象与现实之间的距离上面。NIO 抽象与现实中存在的实体有着非常真实直接的交互关系。 

关于何时该采用传统io，何时应该采用nio： 
1) 扩展性考虑：例如在进行Socket编程通信时每一个Socket都应占据一个线程。使用NIO虽然更富有效率，但相对难以编码和扩展。(当然这一现象在不断的被新的设计和NIO库的特性所改善) 
2) 性能考虑：在处理成千上万的连接时，你可能需要更好的传统IO的扩展性；但是如果连接数量较低时，你可能更注重NIO的高吞吐率。 
3) 当使用SSL (Secure Sockets Layer，安全套接字层) 工作时，选择NIO则实现难度很大 

转载于:https://my.oschina.net/OutOfMemory/blog/95853