Java I/O 操作最终由JVM的native方法调用C库read/write函数触发系统调用，经syscall指令陷入内核执行sys_read/sys_write；因硬件权限限制，用户态JVM无法绕过内核直接访问设备，必须依赖内核完成权限校验与硬件交互。
Java程序本身不直接调用 sys_read 或 sys_write，JVM 作为运行时环境，在执行 I/O 操作（如 System.out.println()、FileInputStream.read()）时，最终会通过本地方法（native method）委托给操作系统的系统调用。此时真正触发用户态→内核态切换的，是 JVM 内部调用的 read() 和 write() 库函数，它们底层封装了对 sys_read（系统调用号 0）和 sys_write（系统调用号 1）的调用。
用户态到内核态切换的实际发生点
JVM 运行在用户态，所有 Java 字节码都在用户空间执行。当执行到需要读写文件、网络或标准输出的操作时：
- JVM 的 native 方法（如
FileInputStream.socketRead0或UnixPrintStream.writeBytes）会调用 C 标准库的read()/write()函数 - 这些库函数内部通过
syscall指令（x86_64）或int 0x80（旧式）陷入内核 - CPU 将寄存器状态（
%rax存系统调用号，%rdi~%r10存参数）保存，切换至内核栈，跳转到system_call入口 - 内核根据
%rax查sys_call_table，调用sys_read或sys_write处理函数
JVM 层面对系统调用开销的缓解策略
为避免频繁陷入内核造成性能瓶颈（例如日志高频打印导致 sys CPU 占用飙升），JVM 和上层应用常采用以下方式降低切换频率：
-
缓冲写入：
PrintStream默认使用BufferedOutputStream，将多次小写合并为一次较大的write()系统调用 -
零拷贝优化：NIO 中
FileChannel.transferTo()在支持的场景下可绕过用户缓冲区，由内核直接 DMA 传输，减少一次用户态/内核态往返 -
异步 I/O 配合：配合 Linux
io_uring的 JNI 封装（如某些高性能日志库），把多个 I/O 请求批量提交，单次系统调用完成多件事
为什么不能绕过系统调用直接访问硬件
这是由硬件权限机制决定的：
- x86_64 中用户态运行在 Ring 3，无法执行
in/out指令，也不能直接映射设备内存（如 GPIO 寄存器） - JVM 进程没有物理内存页表控制权，无法保证访问磁盘或网卡的地址合法、安全
- 所有 I/O 必须经内核驱动校验：文件权限、缓冲区合法性、设备就绪状态等——这些检查只能在内核态完成
- 即便使用
mmap()映射文件，首次缺页仍需sys_mmap触发内核分配页表项；后续访问虽不触发新系统调用，但仍是内核已授权的受控内存访问
可观测性：如何确认是否发生了切换
可通过工具验证 JVM I/O 是否引发系统调用：
-
strace -e trace=read,write,syscalls java YourApp可捕获每次read/write调用及耗时 -
perf record -e syscalls:sys_enter_read,syscalls:sys_enter_write java YourApp定位热点系统调用 - 观察
vmstat 1中sy（system CPU）占比突增，往往对应大量 I/O 导致的上下文切换
