Java NIO深入解析：提升效率的新技术

需积分: 10 115 浏览量更新于2024-07-26 收藏 1.41MB PDF 举报

"Java NIO英文资料，官方学习指南，适合喜欢阅读英文的读者。" Java NIO（Non-blocking Input/Output）是Java平台中用于处理I/O操作的一种高效机制，自Java 1.4版本引入。相比于传统的I/O模型（Blocking I/O），NIO提供了一种更有效率的方式来处理输入和输出，特别是在高并发和大数据量的场景下。这本书《Java™ NIO》由Ron Hitchens撰写，由O'Reilly出版社出版，详细介绍了Java 1.4版本中的新I/O特性，并提供了如何利用这些特性优化Java代码的实例。书中的章节结构通常会包括以下内容： 1. 引言部分可能涵盖了作者的写作动机、书籍的目标读者以及书中使用的约定。 2. 介绍Java NIO的基本概念，如通道（Channels）、缓冲区（Buffers）、选择器（Selectors）等核心组件，它们是NIO系统的核心。 3. 详细解释了NIO如何解决传统I/O的挑战，如性能问题、响应速度、可扩展性和可靠性。例如，通过非阻塞I/O，程序可以在等待数据读取或写入时继续执行其他任务，从而提高了效率。 4. 深入探讨了如何在实际的I/O问题中应用NIO，例如文件操作、网络通信（套接字和服务器套接字）、数据转换等。 5. 对比NIO与旧的1.3版本的I/O API，解释在何种情况下应选择使用NIO，何时应该继续使用旧的API，以便根据具体应用需求做出最佳选择。 6. 可能还包含了对NIO类库的详细解析，如FileChannel、SocketChannel、DatagramChannel等，以及相关的缓冲区类，如ByteBuffer、CharBuffer等。 7. 读者可能会发现关于错误（Errata）的信息，这通常是读者在阅读过程中发现的错误或需要澄清的地方，供后续修订参考。 8. 最后，可能包含对作者、译者和参与者的感谢，以及联系作者和出版社的方式。通过阅读这本书，Java开发者能够深入理解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页未读，继续阅读

zxcnmv

粉丝: 2
资源: 9

Java NIO深入解析：提升效率的新技术

???? ??.zip_#Java_OI8K_aow_to3ja_zip

Java OI流

fanuc oi 培训资料

oi讲课资料

FANUC OI 维修资料

Javaoi流字节流字符流

OI论文资料详细分类合集

OI-materials:这是OIer学好OI的资料合集

OI

oi

最新资源