Java NIO深入解析与实战应用

Java

newio

需积分: 10 101 浏览量更新于2023-07-18 收藏 1.41MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"Java NIO 是Java编程语言中非阻塞I/O（New Input/Output）的简称，是自Java 1.4版本引入的一种新的I/O模型，它提供了与传统I/O（基于流的I/O）不同的工作方式。本书《Java™ NIO》由Ron Hitchens撰写，由O'Reilly出版社于2002年8月出版，旨在深入探讨Java 1.4版中的新I/O功能，并展示如何利用这些特性来大幅提升Java代码的效率。" Java NIO的主要特点包括以下几个方面： 1. **通道(Channel)**：与传统的流(Stream)相比，通道是一种双向数据传输的接口，可以读也可以写。通道可以从一个数据源（如文件、套接字）读取数据，或者向目标（如网络连接）写入数据。 2. **缓冲区(Buffer)**：在Java NIO中，所有I/O操作都涉及缓冲区。缓冲区是存储数据的区域，可以高效地读取和写入数据，同时提供了对数据进行检查和修改的便利方法。 3. **选择器(Selector)**：选择器允许程序在一个或多个通道上进行非阻塞I/O操作。通过注册通道到选择器，可以监听多个通道的事件（如连接就绪、数据可读、写操作完成等），而无需为每个通道创建单独的线程，从而提高了系统的并行性和可扩展性。 4. **多路复用(I/O Multiplexing)**：Java NIO的多路复用是通过选择器实现的，它可以同时处理多个连接，使得服务器端能更好地处理并发连接，尤其适用于高并发的网络应用，如服务器端编程。 5. **文件系统API增强**：Java NIO提供了一些新的文件系统操作，如文件映射（Memory-Mapped Files）、文件通道（File Channels）以及异步文件操作等，这些特性增强了对文件操作的灵活性和性能。 6. **字符集集**：NIO还改进了字符集的支持，引入了`Charset`、`CharsetDecoder`和`CharsetEncoder`等类，使得字符编码和解码更加方便。这本书《Java™ NIO》不仅涵盖了这些基本概念，还详细讨论了何时应该使用NIO API，以及在哪些情况下传统的1.3 I/O API可能更适合特定的应用场景。作者通过真实的例子和常见的I/O问题来展示如何应用NIO，帮助读者理解新特性如何直接影响程序的响应性、可扩展性和可靠性。 Java NIO的引入极大地丰富了Java的I/O能力，对于开发高并发、高性能的Java应用程序至关重要。本书作为学习Java NIO的参考资料，可以帮助开发者更好地理解和掌握这一强大的工具集，提升其在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页未读，继续阅读

pister

粉丝: 4
资源: 12

会员权益专享

Java NIO深入解析与实战应用

JavaNIO.pdf

java nio.pdf

单元学习JavaNIO.pdf

java nio pdf教程下载

java.nio.file.DirectoryNotEmptyException: D:\opt\upFiles\pdf\2023-07-26

java html转pdf

jdk8 获取pdf页数

itext7通过html生成pdf怎么写

java ofd转PDF

java ofd转pdf

javahtml转pdf

加载pdf_Java 插入附件到PDF文档

java html动态模板替换生成pdf

java ofd的base64字符串转pdf的base64字符串

java pdf转byte[]

FileInputStream下载文件

java pdf 转html 还原其格式

Java html2pdf将长HTML分成多个页面代码

pdf文件转成base64 java代码示例

使用itextpdf 将string版的html 转成byte[] 版的pdf

会员权益专享

最新资源