我正在学习 java nio 包,我意识到 File 已经提供了很多方法,nio.Files 通过使用 Path 类再次提供了这些方法。就像我得到的那样。我实际上并没有得到 nio 包的实际用途。
我对这个包很陌生,所以我的问题可能是错误的,但一点帮助可以帮助我进一步阅读。
我正在学习 java nio 包,我意识到 File 已经提供了很多方法,nio.Files 通过使用 Path 类再次提供了这些方法。就像我得到的那样。我实际上并没有得到 nio 包的实际用途。
我对这个包很陌生,所以我的问题可能是错误的,但一点帮助可以帮助我进一步阅读。
Java 编程,I/O 直到最近才使用流隐喻进行。所有 I/O 都被视为单个字节的移动,一次一个,通过一个称为 Stream 的对象。Stream I/O 用于联系外部世界。它也在内部使用,用于将对象转换为字节,然后再转换回对象。
NIO 与原始 I/O 具有相同的作用和目的,但它使用了不同的比喻——块 I/O。java.nio (new/non-blocking I/O) ) API 是随 JDK1.4 引入的。
流 I/O 和块 I/O 有什么区别?
面向流的 I/O 系统一次处理一个字节的数据。输入流产生一字节数据,输出流消耗一字节数据。为流数据创建过滤器非常容易。将几个过滤器链接在一起也相对简单,这样每个过滤器都可以在一个单一的、复杂的处理机制中发挥作用。另一方面,面向流的 I/O 通常相当慢。
面向块的 I/O 系统以块的形式处理数据。每个操作在一个步骤中产生或消耗一个数据块。通过块处理数据可能比通过(流式)字节处理数据快得多。但是面向块的 I/O 缺乏面向流的 I/O 的一些优雅和简单。
什么时候应该使用 java.io 什么时候应该使用 java.nio ?
可扩展性可能会推动您选择软件包。java.net 每个套接字需要一个线程。编码它会容易得多。java.nio 效率更高,但很难编写代码。
一旦处理数以万计的连接,您可能会获得更好的可扩展性,但在较低的数量下,您可能会通过阻塞 IO 获得更好的吞吐量。
当使用 SSL java.nio 时,处理起来并不容易
重要提示:如果您正在使用任何一个包,除非您有令人信服的理由,否则从头开始创建框架不是一个好主意。
对于 java.nio ,Grizzly 和 Quick Server 等项目提供了可重用的非阻塞服务器组件。
值得一读java.nio 的痛点
最后归结为您的项目的特定要求以及您要实现的目标。一些最好的解决方案可能根本不需要最复杂的基础设施
更新:最近发现了自 jdk 1.7 以来存在的 NIO.2 包。NIO.2 与 NIO 不同,主要是 NIO.2 提供了异步通道功能。NIO.2 底漆
如果您正在与 NIO 合作,那么值得一试差异以及哪一个适合您的目的。
Java NIO:通道和缓冲区
在标准 IO API 中,您使用字节流和字符流。在 NIO 中,您使用通道和缓冲区。数据总是从通道读入缓冲区,或从缓冲区写入通道。
Java NIO:非阻塞 IO
Java NIO 使您能够进行非阻塞 IO。例如,线程可以要求通道将数据读入缓冲区。当通道将数据读入缓冲区时,线程可以做其他事情。一旦数据被读入缓冲区,线程就可以继续处理它。将数据写入通道也是如此。
Java NIO:选择器
Java NIO 包含“选择器”的概念。选择器是一个对象,可以监视多个通道的事件(例如:连接打开、数据到达等)。因此,单个线程可以监视多个通道的数据。
有关 orcal 的更多详细信息
由于兼容性原因,几乎每个方法java.io.File
都存在无法修复的问题,最明显的是方法boolean
在失败时返回 a。这些问题加上支持可插拔文件系统的愿望和许多其他事情需要开发一个全新的文件系统 API,所以这就是java.nio.File
创建的原因。
NIO 还引入了 Channels,抽象出 Stream 中的专业化——文件、套接字、网络。