Java NIO 实战：提升高性能应用开发

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

"Java Nio - Ron Hitchens, O'REILLY & ASSOC INC" Java NIO，即非阻塞I/O（Non-blocking Input/Output），是Java 1.4版本引入的一个重大改进，旨在提高应用程序的性能和效率。这本书由Ron Hitchens撰写，详细介绍了这个新包，并填补了早期Java版本中关于高效率编程的关键信息空白。本书的主要内容包括对Java NIO包的全面介绍，该包提供了与传统I/O（基于流的I/O）不同的处理方式。传统的I/O模型通常基于阻塞操作，意味着一个线程在等待数据读取或写入时会被阻塞，无法执行其他任务。相比之下，NIO允许程序在等待数据时进行其他工作，从而提高了并发性和系统的整体吞吐量。书中深入探讨了Java程序员在处理I/O时经常面临的挑战，如响应速度、可扩展性和可靠性问题。通过具体的、现实世界的I/O问题示例，读者将学习如何利用NIO的新特性来解决这些问题。作者还比较了NIO API和旧的1.3版本I/O API，指导读者在不同场景下选择合适的API。书中的章节结构可能包括如下内容： 1. 引言部分可能详细阐述了NIO的基本概念和引入背景。 2. 接下来的章节可能涵盖了NIO的核心组件，如通道（Channels）、缓冲区（Buffers）和选择器（Selectors）。 3. 可能有专门的章节讨论如何使用NIO进行文件操作，包括异步文件读写。 4. 网络编程方面，可能会讲解如何使用NIO构建高性能的服务器，如TCP和UDP通信。 5. 还可能包含关于多线程和并发控制在NIO中的应用，以及如何有效地管理这些资源。 6. 整体性能优化策略和最佳实践也是书中不可或缺的部分。 7. 作者可能会给出一些实际案例，展示如何在实际项目中迁移旧的I/O代码到NIO体系。 8. 最后，书中可能会提供错误报告和反馈的方式，以便读者能够参与到书籍的更新和完善中。这本书适合有一定Java基础，希望提升应用程序性能的开发者阅读。无论是初学者还是经验丰富的专业人员，都能从中获得有关如何充分利用Java NIO的知识，以提高他们的代码效率和系统性能。

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页未读，继续阅读

r_x_y

粉丝: 2
资源: 2

Java NIO 实战：提升高性能应用开发

Java NIO Ron Hitchens著

Java NIO 中英文版

java nio 详_java NIO 详解

java nio应用场景

java nio和aio_java的NIO和AIO

Java nio源码解析

java nio 写事件_Java NIO

java nio 用在哪些场景

java nio这么复杂，还要学吗，还是直接学Netty

讲讲Java nio原理

最新资源