【Java】NIO零拷贝：最清晰易懂的逐层递进方式带你了解

23.

688人浏览 · 2026-03-09 00:44:37

23. · 2026-03-09 00:44:37 发布

简单说说内核

内核。通俗地说，就是操作系统的“大脑”和“大管家”。

它是操作系统中最基本、最核心的部分。如果把整个计算机系统比作一家大型公司，那么内核就是这家公司的CEO兼人事部经理兼保安队长。

从以下几个维度来解释：

1.它是“中间人”

计算机硬件（CPU、内存、硬盘、显卡、键盘等）是非常“笨”的，它们只懂接受指令干活。

应用程序（微信、浏览器、游戏、Java程序）想要使用硬件（比如微信要发语音，需要用到麦克风），但应用程序不能直接命令硬件（否则每个软件都要学会怎么驱动所有型号的麦克风，那太乱了）。

内核的作用就是连接硬件和软件的桥梁：

软件说：“我要保存文件。”
内核翻译并指挥：“好的，硬盘控制器，请把数据写入扇区X。”
硬件干完活后，内核再告诉软件：“保存成功。”

2.它的四大核心职责

内核主要负责管理计算机的四大资源：

1.CPU管理（进程调度）：

决定哪个程序先运行，哪个后运行，运行多久。

比如：你一边听歌一边打字，内核在极短的时间内快速切换CPU去处理这两个任务，让你感觉它们是同时进行的。

2.内存管理：

决定哪个程序用哪块内存，用多大空间。

比如：防止微信占用了浏览器的内存空间，或者在程序关闭后把内存收回来给别人用。

3.设备管理（驱动）：

管理键盘、鼠标、打印机、显示器等外设。

它是硬件的“翻译官”，让软件不用关心硬件的具体细节。

4.文件系统管理：

管理数据在硬盘上怎么存储、怎么读取。

3.为什么要有“内核态”和“用户态”？

为了安全，操作系统把内存和权限分成了两块，内核拥有至高无上的权力。

用户态（User Space）：应用程序（如浏览器、Word、Java程序）通常运行在这里。它们权力很小（权限低），不能直接访问硬件，也不能访问内核内存。如果程序在这里崩溃了，通常只会关闭这个程序，不会影响整个电脑。
内核态（Kernal Space）：内核运行在这里。它拥有对硬件、内存等的完全控制权（权限高）。

当你双击一个文件时，计算机其实经历了一个过程：

程序在用户态发起请求 -> 切换到内核态 -> 内核读取硬盘数据 -> 切换回用户态 -> 程序显示内容。

这种隔离机制防止了由于一个小程序的错误导致整个系统死机（著名的“蓝屏”或“Kernel Panic”通常就是内核态出了严重错误）。

4.常见的内核有哪些？

不同的操作系统使用不同的内核架构：

Linux内核：目前世界上最著名、使用最广泛的内核。安卓手机、服务器、超级计算机都在用。它是宏内核架构（所有功能都打包在一起，效率高但代码复杂）。
Windows内核（NT内核）：微软 Windows 系统的核心。它是混合内核架构。
XNU内核：苹果 macOS 和 iOS 系统的核心。
微内核：只把最核心的功能（如进程通信）放在内核，其它功能（如驱动）放在用户态。虽然安全且易于扩展，但效率通常不如宏内核。Google 正在开发的 Fuchsia 系统就使用微内核。

5.总结

内核就是那个躲在幕后，默默为你管理CPU、内存和硬件，确保所有软件能够和平共处、高效工作的那个“隐形管理者”。没有内核，你的电脑就是一堆毫无生气的金属和硅片。

聊聊NIO中的DMA

DMA = Direct Memory Access，直接内存访问

它是硬件机制，让“设备（磁盘/网卡）可以自己直接读写内存，不需要 CPU 一条条指令搬运”。在 Java NIO 的“零拷贝”里，DMA 负责：把磁盘文件内容直接搬进内核缓冲区，或者把内核缓冲区里的数据直接搬到网卡，整个过程几乎不占用CPU。

1.DMA本质是什么？

DMA（Direct Memory Access）：

一种硬件特性，允许某些硬件子系统（磁盘控制器、网卡、显卡等）直接访问系统主内存（RAM），而不需要 CPU 逐字节参与搬运。

系统里有 DMA 控制器（DMAC），在 CPU 的“指挥”下完成：

CPU给 DMA 发：源地址、目的地址、长度、方向（读/写）。
DMA 自己把数据从设备->内存或内存->设备搬完。
搬完后 DMA 给 CPU 发一个中断，通知完成。

形象点说：

没有 DMA：搬东西的是“老板（CPU）亲自搬”。
有 DMA：老板只下命令，“搬运工（DMA）”自己去搬，老板可以去做别的事。

2.没有DMA时的I/O拷贝长什么样？

以“读取磁盘文件 -> 通过网络发送”为例（传统 I/O）：

CPU 先把磁盘数据读到内核缓冲区（DMA 或 CPU 搬，但传统讨论中常把这次也算作 CPU 参与）。
CPU 再把内核缓冲区的数据拷贝到用户态缓冲区（用户进程的 byte[]/ByteBuffer）。
用户程序再 write()，CPU 把用户缓冲区拷贝到内核的 socket 缓冲区。
再由内核/驱动拷贝到网卡发送缓冲区（通常是指 CPU 更新了网卡环行缓冲区的指针，告诉网卡数据在内存哪里，而不是真的把数据搬运到网卡硬件里），最后由网卡利用 DMA 发送到网络上。

关键点：中间有好几次“内存到内存”的拷贝都是 CPU 在干活，CPU 又忙又慢。

3.在NIO零拷贝里，DMA起什么作用？

sendfile的演进：早期模式与现代模式

在Java NIO的FileChannel.transferTo()/transferFrom()这类“零拷贝”场景中，底层在 Linux 上会用到类似sendfile系统调用。典型流程大致是这样（早期模式）：

DMA从磁盘 -> 内核文件缓冲区
磁盘控制器通过 DMA，把文件内容直接读到内核的 page cache（文件缓冲区）。
内核从文件缓冲区 -> socket缓冲区
这一步是内核里的一次“内存拷贝”，通常需要 CPU 参与。（现代模式下仅复制描述符/元数据，CPU开销极小）
DMA从socket缓冲区 ->网卡
DMA 把 socket 缓冲区里的数据直接搬给网卡，网卡再发到网络。

对比一下：

传统I/O：
磁盘 -> 内核缓冲区 -> 用户缓冲区 -> socket缓冲区 -> 网卡【一共4次拷贝】
NIOtransferTo零拷贝：
磁盘（DMA）-> 内核文件缓冲区 -> socket缓冲区 ->（DMA）网卡
减少了一次“内核->用户->内核”的往返，也减少上下文切换，只有一次 CPU 参与的内存拷贝（早期模式，现代模式 CPU 只是拷贝元数据信息到 Socket 缓冲区）。

所以这里说的“DMA”，就是负责“设备<->内存”之间搬运的硬件加速器，让：

磁盘到内存
内存到网卡

这两段不再消耗 CPU 周期。

4.和Java NIO的关系

在 Java 层面你不会“直接操作DMA”，而是：

NIO 的FileChannel.transferTo()/transferFrom()
底层调用操作系统的零拷贝接口（如 Linux 的sendfile）。
操作系统内部利用 DMA + 内核态拷贝（CPU参与） 实现高效传输。
对你来说，只是“看起来像是一次方法调用就把文件发到网络”，但背后：
- CPU 参与的拷贝次数更少。
- 大量“设备<->内存”的搬运工作由 DMA 完成。

很多人讲“NIO零拷贝就是DMA拷贝”，这句话更准确的理解是：

NIO 利用操作系统提供的零拷贝接口，让 DMA 承担了设备层面的搬运，尽量减少 CPU 在“拷来拷去”上浪费时间。

5.总结

DMA：设备自己直接访问内存，不再占用 CPU 搬运。
在 NIO“零拷贝”语境下，DMA 负责：
- 磁盘 -> 内核缓冲区
- 内核 socket 缓冲区 -> 网卡

这两段“设备级”拷贝，从而让 CPU 更专注于业务逻辑，提升吞吐。

认识NIO“零拷贝”中的内核

简单来说，内核（Kernal）是操作系统的核心，它是计算机硬件和你运行的软件（如微信、浏览器、Java程序）之间的“大管家”。

在 NIO 和 DMA 的上下文中，内核扮演着“控制者”和“中转站”的角色。

1.形象比喻：公司的“行政总管”

如果把计算机比作一家大公司：

硬件（CPU、内存、硬盘、网卡） = 公司的资源（会议室、车辆、库房）
应用程序（Java程序、浏览器） = 公司的业务员（你、我）
内核 = 公司的行政总管

为什么需要内核？

业务员（应用程序）不能随便自己去拿库房（磁盘）里的东西，也不能随便占用会议室（内存）。必须向行政总管（内核）申请。

权力大：内核拥有对硬件的完全控制权（Ring 0 最高权限）。
权力小：普通应用程序权限很低（Ring 3），不能直接操作硬件。

2.核心作用：内核在 NIO 拷贝中干了什么？

A.管理“缓冲区”（Kernel Buffer）

磁盘上的文件 = 存在公司仓库里的货物
Java程序想要的数据 = 业务员手里的文件
内核缓冲区 = 行政总管桌子上的托盘

DMA 只是把货物（文件数据）从仓库（磁盘）搬到了总管的托盘（内核缓冲区）上。

因为安全原因，DMA 不允许直接把数据搬给业务员（Java程序），必须先放在总管（内核）这里中转一下。

B.调度“DMA”这个搬运工

DMA 虽然是硬件，但它是个“没脑子的搬运工”，它不知道要搬什么、搬多少、搬到哪里去。

必须由内核（CPU执行内核代码）来下命令：

内核告诉 DMA：“去磁盘把 A 文件的前 1KB 数据，搬运到内存地址 X 处（内核缓冲区）”。
DMA 干活，干完后通知内核。
内核再把数据从内核缓冲区交给应用程序（传统 IO），或者通过零拷贝技术直接发给网卡。

3.传统IO的“慢”在哪里？

就是数据需要在“用户态”和“内核态”之间来回倒手：

磁盘 -> 内核缓冲区（DMA 搬运）
内核缓冲区 -> 用户缓冲区（CPU 搬运，涉及权限切换，耗时）
用户缓冲区 -> 内核 Socket 缓冲区（CPU搬运）
内核 Socket 缓冲区 -> 网卡（DMA 搬运）

4.NIO零拷贝的“快”在哪里？

它利用内核提供的特殊功能（如sendfile），跳过了“用户缓冲区”这个中转站。数据全程都在内核态里转悠（磁盘 -> 内核缓冲区 -> 网卡），不需要把数据搬运到用户态给 Java 程序看一眼再送回去。

5.总结

内核就是操作系统的“大脑和管家”。

在 NIO 数据传输中：

它负责指挥：配置 DMA 控制器，告诉它去哪读、往哪写。
它负责中转：提供内核缓冲区作为数据在硬件之间流转的临时站点。
它负责安全：确保应用程序不能直接乱改硬件数据。

我们说的“内核拷贝”，指的就是数据在内核管理的内存区域（内核缓冲区）里进行的传输，这比把数据搬到应用程序手里要安全且高效得多。

NIO零拷贝原理与实现及应用

在Java NIO（New I/O）中，零拷贝是一项非常重要的优化技术，它主要用于提高数据传输的效率，减少CPU的上下文切换和内存拷贝次数。

Java NIO 里的“零拷贝”主要指两件事：
1. 利用 OS 级别的零拷贝（如Linux 的sendfile），通过FileChannel.transferTo/transferFrom直接把文件数据从内核缓冲区“搬运”到 Socket，避免在用户空间来回拷贝。这是真正意义上的“零拷贝网络传输”。
2. 使用MappedByteBuffer（内存映射文件） + DirectBuffer，让文件内容直接映射到进程地址空间，减少一次“内核缓冲区->用户缓冲区”的拷贝，但这更多是“少拷贝”，并不等同于上面的“零拷贝网络传输”。
零拷贝主要是IO 密集场景的优化（大文件传输、静态文件服务、Kafka 这种消息队列），对 CPU 和内存带宽收益明显，但编程限制较多，也不是所有平台都一样实现。

要理解 NIO 中的零拷贝，需要先看传统的 I/O 操作有什么问题，再看 NIO 是如何解决的。

1.传统I/O的数据拷贝过程（非零拷贝）

假设我们需要从磁盘读取一个文件，并通过网络发送出去（这是服务器常见的场景，如下载文件）。在传统的Java IO（BIO）中，代码通常如下：

File file = new File("test.txt");
RandomAccessFile raf = new RandomAccessFile(file, "rw");
FileOutputStream fos = new FileOutputStream("socket");

byte[] buffer = new byte[1024];
int readLength;
while ((readLength = raf.read(buffer)) != -1) {
    fos.write(buffer, 0, readLength);
}

在这个过程中，数据经历了以下流程：

第一次拷贝（DMA）：数据从磁盘读取到内核空间的读缓冲区。（用户态->内核态）
第二次拷贝（CPU）：数据从内核读缓冲区拷贝到用户空间的应用缓冲区。（此时 CPU 参与拷贝，且发生内核态到用户态的上下文切换）
第三次拷贝（CPU）：数据从用户空间拷贝到内核空间的 Socket 缓冲区。（再次发生用户态到内核态的切换）
第四次拷贝（DMA）：数据从内核 Socket 缓冲区拷贝到网卡接口进行发送。

问题点：

4次数据拷贝（2次CPU拷贝，2次DMA拷贝）
4次上下文切换（用户态<->内核态）
数据在内核空间和用户空间之间来回搬运（中间第2、3两步），对于大文件传输，这是巨大的资源浪费（因为“用户空间充当了一个中转站”而存在的冗余拷贝）。

2.NIO中的零拷贝实现

Java NIO通过FileChannel提供了零拷贝的实现，主要有两种方式：transferTo/transferFrom和DirectBuffer（堆外内存/直接缓冲区，虽然严格来说后者是减少拷贝，但常在讨论范围内）。

方式一：FileChannel.transferTo() —— 真正的零拷贝

这是最经典的零拷贝方式，对应Linux底层的sendfile调用。

零拷贝的核心思想：让数据只在内核（或硬件）里“搬运”，不要在用户空间中转。

Linux的sendfile/splice等

Linux提供：

sendfile(out_fd, in_fd, offset, count)：可以把文件描述符的数据直接“搬到”一个 socket 描述符，内核内部只做 DMA + 一次内部拷贝（从文件缓冲拷贝到 socket 缓冲），不需要把数据拷到用户空间再拷回来。
更新的splice()/tee()、io_uring等进一步扩展零拷贝能力。

Java NIO：FileChannel.transferTo/transferFrom

Java 在FileChannel上提供了：

// 文件 -> Socket 的“零拷贝”传输
long transferTo(long position, long count, WritableByteChannel target);

在支持sendfile的系统（如Linux、UNIX）上，JDK 会通过本地代码（native）调用sendfile，实现：

第一次拷贝（DMA）：数据从磁盘读取到内核空间的读缓冲区。
第二次拷贝（CPU）：数据从内核读缓冲区拷贝到内核Socket缓冲区（早期模式：这次拷贝在内核里完成，是 CPU 拷贝）。
第三次拷贝（DMA）：数据从Socket缓冲区拷贝到网卡。

数据不再在用户空间出现，用户态只负责发起系统调用，上下文切换次数也减少。

现代模式：Linux 2.4+ 及以后
更进一步（带有 DMA Scatter/Gather 分散/聚集的 sendfile）：在现代Linux内核中，如果网卡支持 SG-DMA（Scatter/Gather DMA），sendfile可以做到真正的“零”CPU拷贝：

DMA 将数据从磁盘读取到内核读缓冲区。
不进行数据拷贝，而是 CPU 将内核读缓冲区的文件描述符、偏移量、长度等信息复制到 Socket 缓冲区中。注意：此时并没有复制实际的数据内容。
DMA 拷贝：网卡驱动读取 Socket 缓冲区中的描述符，根据描述符直接去内核读缓冲区读取数据，然后发送给网卡。

效果：

拷贝次数：从4次减少到2次（甚至理论上的0次CPU拷贝）。
上下文切换：从4次减少到2次（用户态逻辑几乎不感知数据）。

代码示例：

FileChannel sourceChannel = new FileInputStream("source.txt").getChannel();
FileChannel destChannel = new FileOutputStream("dest.txt").getChannel();
// 或者传输给网络 SocketChannel

// 一行代码搞定，底层调用操作系统的 sendfile
sourceChannel.transferTo(0, sourceChannel.size(), destChannel);

典型写法（静态文件服务器）：为何transferTo需要循环调用？

try (FileChannel fileChannel = FileChannel.open(Paths.get("large_file.bin"), StandardOpenOption.READ);
     SocketChannel socketChannel = SocketChannel.open(remoteAddress)) {

    long position = 0;
    long size = fileChannel.size();
    while (position < size) {
        long transferred = fileChannel.transferTo(position, size - position, socketChannel);
        position += transferred;
    }
}

Kafka、很多 Web 容器里的静态文件发送，底层就是利用这种机制实现零拷贝传输。

方式二：MappedByteBuffer —— 内存映射文件

除了transferTo，NIO 里的另一种“少拷贝”：MappedByteBuffer。

try (FileChannel channel = FileChannel.open(path, StandardOpenOption.READ)) {
    MappedByteBuffer mapped = channel.map(FileChannel.MapMode.READ_ONLY, 0, channel.size());
    // mapped 就是“映射到文件内容”的 direct buffer
    // 读的时候就不再需要 read() 系统调用，直接像数组一样访问
}

官方文档定义：MappedByteBuffer是“内容为内存映射文件区域的直接字节缓冲区”。

channel.map()方法将文件直接映射到虚拟内存中。

Java NIO 中的MappedByteBuffer就是mmap的封装。

狭义上：mmap是 Linux/Unix 系统下的系统调用函数名（源于 POSIX 标准）。

广义上：在讨论 Java NIO 或计算机原理时，我们常说的“mmap 技术”指的是内存映射文件这一通用机制，几乎所有现代操作系统（Windows、macOS、BSD 等）都实现了这项技术，只是调用的函数名称和内部实现细节略有不同。

核心机制

当调用mmap（Memory Map）时，操作系统并不会立即将文件内容拷贝到内存中，而是建立虚拟内存地址与文件磁盘地址之间的映射关系。（访问这段内存时，通过缺页异常触发磁盘 IO，文件内容好像直接就在内存里。）

映射过程：mmap将文件映射到用户进程的虚拟内存空间。
缺页中断：当程序试图访问这段内存时，如果数据不在物理内存中，会触发缺页中断，操作系统负责将磁盘数据直接加载到内核缓冲区（页缓存 PageCache）。
共享内存：mmap映射的区域在用户空间看来，就像是自己在使用内存，但实际上，这块虚拟内存指向的是内核空间的物理内存页。

了解核心机制：认识缺页中断和页缓存

使用mmap优化后的拷贝流程

DMA 拷贝：数据从磁盘读取到内核缓冲区。
映射关系：用户缓冲区的虚拟地址指向了内核缓冲区的物理地址。此时不需要 CPU 将数据从内核拷贝到用户空间。
CPU 拷贝：当需要将数据发送到网络时，调用write()，CPU 将数据从内核缓冲区拷贝到 Socket 缓冲区。
DMA 拷贝：数据从 Socket 缓冲区 DMA 拷贝到网卡。

总计：3 次数据拷贝（减少了 1 次内核到用户的 CPU 拷贝），上下文切换次数视具体调用而定（通常仍需 4 次切换，若配合 sendfile可进一步减少）。

核心优势：省去了传统 I/O 中数据从内核空间“搬运”到用户空间，再“搬运”回内核空间的冗余操作。用户态程序可以直接像操作内存一样操作文件数据。

但它不等同于网络零拷贝：

你仍然需要把MappedByteBuffer里的数据写到 Socket（比如socketChannel.write(mapped)），这中间可能还要再走一次内核拷贝。
真正做到“文件->网卡全程零用户态拷贝”的，还是transferTo+sendfile。

mmap在NIO中的优缺点

优点：

减少拷贝：显而易见的少了一次 CPU 拷贝，降低了 CPU 负载。
减少内存占用：不需要在用户空间额外维护一份文件数据的副本，节省了内存。
高性能读写：对于大文件的随机读写，利用操作系统的页缓存机制，效率极高。

缺点与风险（面试重点）：

文件大小限制：在 Java 中，MappedByteBuffer的大小受限于Integer.MAX_VALUE（约 2GB）。如果文件超过 2GB，需要手动分段映射。
内存释放困难：Java 没有提供直接unmap的 API。MappedByteBuffer的释放依赖于 GC 和 Cleaner 机制，可能导致文件句柄长时间无法释放。通常需要通过反射调用Cleaner来手动清理。
数据一致性问题：mmap依赖于操作系统的 PageCache。如果程序突然崩溃，内存中尚未刷盘的数据可能丢失（虽然force()方法可以强制刷盘，但性能会下降）。
写入并发问题：多个进程同时通过mmap写入同一文件区域，需要自行处理并发同步问题。

3.对比总结

特性	传统 IO (BIO)	NIO (transferTo/sendfile)	NIO
核心机制	read() + write()	sendfile()	mmap()
CPU拷贝次数	2次	0次 (理想状态下)	1次
上下文切换	4次	2次	4次 (读写分别触发)
适用场景	需要在用户态处理数据	文件传输 (Web服务器)	需要频繁修改大文件
安全性	高	高	需注意内存溢出/Unmap

4.实际应用

很多高性能中间件都大量使用了 NIO 的零拷贝技术：

Kafka：Broker 端传输日志文件给 Consumer 时，使用了FileChannel.transferTo，极大地提高了吞吐量。
Netty：作为高性能网络框架，底层大量使用FileRegion（封装了transferTo）和DirectBuffer。
Nginx / Apache：作为 Web 服务器，在发送静态文件时均采用零拷贝技术。

收益主要在：

减少 CPU 拷贝次数，降低 CPU 占用和内存带宽压力。
减少用户态/内核态上下文切换。
对“磁盘->网络”这种大流量静态内容场景，性能提升非常明显（Web Server、消息队列等）。

典型适用：

静态文件服务（HTTP 文件下载、静态资源）。
消息队列、日志采集等需要大量传输文件的组件。
大文件传输、备份场景。

不太适合：

数据在中间需要加工、修改的场景（加密、压缩、协议封装等），因为必须在用户空间处理，零拷贝的优势就没了。
小文件、低并发场景，优化收益有限，反而增加复杂度。

5.使用NIO零拷贝时的注意点

平台依赖

transferTo是否真正“零拷贝”，要看 OS 和 JDK 实现：
- Linux/UNIX 上通常会用sendfile。
- Windows 有自己的实现（如TransmitFile），但底层原理类似。
如果 OS 不支持，JDK 会退化为普通的 read/write，你仍然能正常工作，只是不再有零拷贝优势。

文件大小与传输边界

transferTo的count可能不会一次性传完，需要循环调用，累加position。为何transferTo需要循环调用？

与 SSL/TLS 的冲突

零拷贝通常要求明文直接从内核 Socket 发出。如果数据需要 SSL 加密，就必须在用户空间处理，一般无法使用零拷贝。
有些实现会用sendfile先把数据读到用户空间，再做加密，这样零拷贝就退化成普通 IO。

生命周期与内存泄漏

MappedByteBuffer/DirectBuffer是堆外内存，不再使用时最好及时Cleaner清理或依靠虚引用等机制回收，避免堆外内存泄漏（尤其是在频繁映射大文件时）。

总结

NIO中的零拷贝并不是说完全没有数据拷贝（物理层面的DMA拷贝是必须存在的），而是指在CPU层面不需要参与数据的搬运工作，从而释放CPU去处理其他逻辑，同时减少了内核态与用户态之间昂贵的上下文切换。对于高并发、大文件传输的场景，性能提升非常显著。

https://edu.csdn.net/learn/39067/627173?utm_source=2019755004

汇聚全球AI编程工具，助力开发者即刻编程。

更多推荐

Codex最值得安装的5个插件

上述插件的安装方法都很简单，直接在Codex插件页面搜索对应的页面，点击安装即可。

AI编程社区

全民 Coding 时代来了？九大平台同台 PK，这次真不是噱头

AI编程社区

AI工程技能库：MattPocock开源AIAgent协作工具箱

MattPocock开源的mattpocock/skills是一个AI工程协作工具包，将软件开发流程拆解为可组合的Agent技能。该工具包包含20+个正式技能，覆盖需求澄清、任务拆分、TDD开发、Bug诊断、代码评审等全流程，通过/claude-plugin机制集成到编码Agent中。核心特色包括：1）流程编排与工程纪律分离，用户只需触发顶层流程；2）强调知识沉淀，自动生成CONTEXT.md等文

AI编程社区

所有评论(0)

查看更多评论

23.

@weixin_42383981

已为社区贡献18条内容

【Java】NIO零拷贝：最清晰易懂的逐层递进方式带你了解

23.

简单说说内核

1.它是“中间人”

2.它的四大核心职责

1.CPU管理（进程调度）：

2.内存管理：

3.设备管理（驱动）：

4.文件系统管理：

3.为什么要有“内核态”和“用户态”？

4.常见的内核有哪些？

5.总结

聊聊NIO中的DMA

1.DMA本质是什么？

2.没有DMA时的I/O拷贝长什么样？

3.在NIO零拷贝里，DMA起什么作用？

4.和Java NIO的关系

5.总结

认识NIO“零拷贝”中的内核

1.形象比喻：公司的“行政总管”

2.核心作用：内核在 NIO 拷贝中干了什么？

A.管理“缓冲区”（Kernel Buffer）

B.调度“DMA”这个搬运工

3.传统IO的“慢”在哪里？

4.NIO零拷贝的“快”在哪里？

5.总结

NIO零拷贝原理与实现及应用

1.传统I/O的数据拷贝过程（非零拷贝）

2.NIO中的零拷贝实现

方式一：FileChannel.transferTo() —— 真正的零拷贝

Linux的sendfile/splice等

Java NIO：FileChannel.transferTo/transferFrom

方式二：MappedByteBuffer —— 内存映射文件

核心机制

使用mmap优化后的拷贝流程

mmap在NIO中的优缺点

3.对比总结

4.实际应用

5.使用NIO零拷贝时的注意点

总结

所有评论(0)

温馨提示：您尚未绑定手机号

23.