Java NIO深入解析与实战应用

需积分: 48 69 浏览量更新于2024-07-17 1 收藏 1.41MB PDF 举报

"Java.NIO资源下载资源下载" Java NIO（Non-blocking Input/Output）是Java平台中的一个重要特性，自Java 1.4版本引入，它提供了与传统I/O流不同的处理方式。传统I/O基于流（Stream）和套接字（Socket），采用阻塞式读写操作，而NIO则引入了选择器（Selector）、通道（Channel）和缓冲区（Buffer）等概念，旨在提高I/O操作的性能和效率。这本书《Java™ NIO》由Ron Hitchens撰写，由O'Reilly出版社于2002年8月出版，共312页，ISBN为0-596-00288-2。书中详细探讨了Java 1.4版本引入的NIO特性，并展示了如何利用这些新功能来显著提升Java代码的效率。作者分析了Java程序员在进行I/O操作时常见的挑战，并通过实际的、有代表性的I/O问题示例，展示了如何利用NIO新特性来解决这些问题，从而提高响应速度、可扩展性和可靠性。书中的内容包括但不限于： 1. **NIO基础**：介绍NIO的基本概念，如缓冲区（Buffer）、通道（Channel）和选择器（Selector），以及它们相对于传统I/O的优势。 2. **非阻塞I/O**：解释如何使用NIO实现非阻塞I/O操作，使得程序在等待数据时可以执行其他任务，从而提高系统资源利用率。 3. **多路复用**：通过选择器，演示如何管理多个通道并监听它们的事件，这对于高并发场景尤其有用。 4. **文件系统操作**：NIO提供了对文件系统的高效访问，包括大文件处理和随机访问能力。 5. **网络编程**：讲解如何使用NIO进行高效的网络通信，如TCP和UDP连接，以及服务器端的并发处理。 6. **对比和选择**：由于NIO是对1.3版本I/O的补充而非替代，书中还指导读者了解何时应该使用NIO，何时应继续使用传统的1.3 I/O API，以适应特定的应用场景。此外，书中的章节结构清晰，便于读者按需查阅。前言部分阐述了编写本书的目的和受众，同时也指明了书中使用的约定和软件版本信息。书末通常会有作者的致谢和读者评论，以供读者参考。通过学习这本书，Java开发者不仅可以深入了解NIO的工作原理，还能掌握实际应用中如何有效地利用NIO优化代码，提高程序性能，这对于开发高并发、低延迟的系统至关重要。对于任何想要提升Java I/O性能的开发者来说，这是一本不可多得的参考资料。

powerful new framework that encompasses the high-performance I/O features commonly

available on commercial operating systems today. Additionally, a new Service Provider

Interface (SPI) is provided in java.nio.channels.spi that allows you to plug in new

types of channels and selectors without violating compliance with the specifications.

With the addition of NIO, Java is ready for serious business, entertainment, scientific and

academic applications in which high-performance I/O is essential.

The JDK 1.4 release contains many other significant improvements in addition to NIO.

As of 1.4, the Java platform has reached a high level of maturity, and there are few

application areas remaining that Java cannot tackle. A great guide to the full spectrum of

JDK features in 1.4 is Java In A Nutshell, Fourth Edition by David Flanagan (O'Reilly).

1.4 I/O Concepts

The Java platform provides a rich set of I/O metaphors. Some of these metaphors are

more abstract than others. With all abstractions, the further you get from hard, cold

reality, the tougher it becomes to connect cause and effect. The NIO packages of JDK 1.4

introduce a new set of abstractions for doing I/O. Unlike previous packages, these are

focused on shortening the distance between abstraction and reality. The NIO abstractions

have very real and direct interactions with real-world entities. Understanding these new

abstractions and, just as importantly, the I/O services they interact with, is key to making

the most of I/O-intensive Java applications.

This book assumes that you are familiar with basic I/O concepts. This section provides a

whirlwind review of some basic ideas just to lay the groundwork for the discussion of

how the new NIO classes operate. These classes model I/O functions, so it's necessary to

grasp how things work at the operating-system level to understand the new I/O

paradigms.

In the main body of this book, it's important to understand the following topics:

• Buffer handling

• Kernel versus user space

• Virtual memory

• Paging

• File-oriented versus stream I/O

• Multiplexed I/O (readiness selection)

1.4.1 Buffer Handling

Buffers, and how buffers are handled, are the basis of all I/O. The very term

"input/output" means nothing more than moving data in and out of buffers.

Processes perform I/O by requesting of the operating system that data be drained from a

buffer (write) or that a buffer be filled with data (read). That's really all it boils down to.

All data moves in or out of a process by this mechanism. The machinery inside the

operating system that performs these transfers can be incredibly complex, but

conceptually, it's very straightforward.

Figure 1-1 shows a simplified logical diagram of how block data moves from an external

source, such as a disk, to a memory area inside a running process. The process requests

that its buffer be filled by making the read() system call. This results in the kernel issuing

a command to the disk controller hardware to fetch the data from disk. The disk

controller writes the data directly into a kernel memory buffer by DMA without further

assistance from the main CPU. Once the disk controller finishes filling the buffer, the

kernel copies the data from the temporary buffer in kernel space to the buffer specified by

the process when it requested the read() operation.

Figure 1-1. Simplified I/O buffer handling

This obviously glosses over a lot of details, but it shows the basic steps involved.

Note the concepts of user space and kernel space in Figure 1-1. User space is where

regular processes live. The JVM is a regular process and dwells in user space. User space

is a nonprivileged area: code executing there cannot directly access hardware devices, for

example. Kernel space is where the operating system lives. Kernel code has special

privileges: it can communicate with device controllers, manipulate the state of processes

in user space, etc. Most importantly, all I/O flows through kernel space, either directly (as

decsribed here) or indirectly (see Section 1.4.2).

When a process requests an I/O operation, it performs a system call, sometimes known as

a trap, which transfers control into the kernel. The low-level open(), read(), write(), and

close() functions so familiar to C/C++ coders do nothing more than set up and perform

the appropriate system calls. When the kernel is called in this way, it takes whatever steps

are necessary to find the data the process is requesting and transfer it into the specified

buffer in user space. The kernel tries to cache and/or prefetch data, so the data being

requested by the process may already be available in kernel space. If so, the data

requested by the process is copied out. If the data isn't available, the process is suspended

while the kernel goes about bringing the data into memory.

Looking at Figure 1-1, it's probably occurred to you that copying from kernel space to the

final user buffer seems like extra work. Why not tell the disk controller to send it directly

to the buffer in user space? There are a couple of problems with this. First, hardware is

usually not able to access user space directly.

[2]

Second, block-oriented hardware devices

such as disk controllers operate on fixed-size data blocks. The user process may be

requesting an oddly sized or misaligned chunk of data. The kernel plays the role of

intermediary, breaking down and reassembling data as it moves between user space and

storage devices.

[2] There are many reasons for this, all of which are beyond the scope of this book.

Hardware devices usually cannot directly use virtual memory addresses.

1.4.1.1 Scatter/gather

Many operating systems can make the assembly/disassembly process even more efficient.

The notion of scatter/gather allows a process to pass a list of buffer addresses to the

operating system in one system call. The kernel can then fill or drain the multiple buffers

in sequence, scattering the data to multiple user space buffers on a read, or gathering

from several buffers on a write (Figure 1-2

Figure 1-2. A scattering read to three buffers

This saves the user process from making several system calls (which can be expensive)

and allows the kernel to optimize handling of the data because it has information about

the total transfer. If multiple CPUs are available, it may even be possible to fill or drain

several buffers simultaneously.

1.4.2 Virtual Memory

All modern operating systems make use of virtual memory. Virtual memory means that

artificial, or virtual, addresses are used in place of physical (hardware RAM) memory

addresses. This provides many advantages, which fall into two basic categories:

1. More than one virtual address can refer to the same physical memory location.

2. A virtual memory space can be larger than the actual hardware memory available.

The previous section said that device controllers cannot do DMA directly into user space,

but the same effect is achievable by exploiting item 1 above. By mapping a kernel space

address to the same physical address as a virtual address in user space, the DMA

hardware (which can access only physical memory addresses) can fill a buffer that is

simultaneously visible to both the kernel and a user space process. (See Figure 1-3.)

Figure 1-3. Multiply mapped memory space

Aligning memory page sizes as multiples of the disk block size allows the kernel to issue

direct commands to the disk controller hardware to write memory pages to disk or reload

them when needed. It turns out that all disk I/O is done at the page level. This is the only

way data ever moves between disk and physical memory in modern, paged operating

systems.

Modern CPUs contain a subsystem known as the Memory Management Unit (MMU).

This device logically sits between the CPU and physical memory. It contains the mapping

information needed to translate virtual addresses to physical memory addresses. When

the CPU references a memory location, the MMU determines which page the location

resides in (usually by shifting or masking the bits of the address value) and translates that

virtual page number to a physical page number (this is done in hardware and is extremely

fast). If there is no mapping currently in effect between that virtual page and a physical

memory page, the MMU raises a page fault to the CPU.

A page fault results in a trap, similar to a system call, which vectors control into the

kernel along with information about which virtual address caused the fault. The kernel

then takes steps to validate the page. The kernel will schedule a pagein operation to read

the content of the missing page back into physical memory. This often results in another

page being stolen to make room for the incoming page. In such a case, if the stolen page

is dirty (changed since its creation or last pagein) a pageout must first be done to copy the

stolen page content to the paging area on disk.

If the requested address is not a valid virtual memory address (it doesn't belong to any of

the memory segments of the executing process), the page cannot be validated, and a

segmentation fault is generated. This vectors control to another part of the kernel and

usually results in the process being killed.

Once the faulted page has been made valid, the MMU is updated to establish the new

virtual-to-physical mapping (and if necessary, break the mapping of the stolen page), and

the user process is allowed to resume. The process causing the page fault will not be

aware of any of this; it all happens transparently.

This dynamic shuffling of memory pages based on usage is known as demand paging.

Some sophisticated algorithms exist in the kernel to optimize this process and to prevent

thrashing, a pathological condition in which paging demands become so great that

nothing else can get done.

1.4.4 File I/O

剩余274页未读，继续阅读

岁月如歌ios

粉丝: 1
资源: 5

Java NIO深入解析与实战应用

java NIO.zip

读取文件字符编码所需jar包

JAVA_IO/NIO(demo,压缩jar文件)

导入java.nio.charset.StandardCharsets出错

java.nio.charset.Charset.detect爆红

不用 java.nio.file.Path ,如何改?

NIO,使用通道拷贝文件后，试图将源文件删除后，程序出现java.nio.file.AccessDeniedException报错，代码如何编写将通道申请的堆外内存释放

前端报错java.nio.file.NoSuchFileException: C:\Project\javaTrunk\target\classes\static\upload\temporary\5941374724612894.xlsx

java.io.IOException: 打开的文件过多 at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method) ~[na:1.8.0_262] at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:419) ~[na:1.8.0_262] at sun.nio.ch.ServerSocketChan

最新资源