从 Java 应用程序读取的文件是否会调用系统调用？
我的理解是，请求文件系统路径（例如/aFile）的用户应用程序将调用文件系统并获取所请求文件的虚拟地址。 然后应用程序将尝试以该地址作为参数（即作为 CPU 指令）进行读/写操作？ 执行读取命令时，内存管理单元会将该地址转换为物理地址，并查看页表。如果用户没有访问该内存位置的权限（该信息携带在哪里？），则操作将中止。否则，如果在内存中找到该物理地址页，则对其进行读/写操作，否则从磁盘中带入该页并重复操作。
所以，似乎根本没有系统调用。有人可以纠正上述程序细节中可能存在的错误吗？
My understanding is that a user application requesting a file system path (eg. /aFile) will invoke the File System and get back the virtual address of the requested file.
Then the application will attempt a read/write operation with that address as argument, that as a CPU instruction?
On execution of the read command the Memory Management Unit will translate that address into the phisical address, looking into a page table. In case the user has not privilege to access that memory location (where is that information carried?) the operation is aborted. Otherwise, if the physical address page is found in memory, the read/write operation is carried on it, otherwise the page is brought in from disk and the operation is repeated.
So, there seems to be no system call at all. Could someone correct possible mistakes in the above procedure detail?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
（通常）当您在 Java 中打开/读取/写入文件时，会调用操作系统内核（又名）。系统调用，用于打开/读/写该文件。如何完成此操作以及涉及的内存管理完全掌握在内核手中，但最终从文件读取的字节被复制回通过系统调用提供的缓冲区。
(typically) when you open/read/write a file in Java, a call is made to the OS kernel , aka. a system call,for opening/read/write that file. How that is done and the memory management involved is entierly in the hands of the kernel, but eventually bytes read from the file is copied back to a buffer supplied through the system call.
在第一句话（调用文件系统）中，这意味着系统调用，因为它必须将控制器转移到内核......
In the very first sentence (invoke the filesystem) that implies a system call since it must of necessity transfer controller to the kernel....
您想知道的是操作系统设计。有许多方法可用，通过在文件抽象之上使用文件系统抽象（一切都是由字节流组成的文件），您可以做很多事情而无需更改抽象。
试想一下，与火线驱动器相比，与 Windows 网络共享相比，操作系统对待 RAM 磁盘的方式必须有多么不同。文件抽象是相同的。
现在，如果您想真正了解发生了什么，我强烈建议您下载并安装 OpenSolaris 并学习如何使用 dtrace。它允许您询问系统从主方法到物理硬件之上的各个驱动程序一直在做什么。
What you are wondering about is operating system design. Many approaches are available and by having the file system abstraction on top of the file abstraction (everything is a file consisting of a stream of bytes) you can do quite a lot without having to change the abstraction.
Just think how different an operating system must treat a RAM disk, compared to a firewire drive, compared again to a Windows network share. The file abstraction is the same.
Now, if you want to actually KNOW what happens, I can strongly recommend downloading and installing OpenSolaris and learning how to work with dtrace. It allows you to ask the system what it does all the way down from your main method to the individual drivers on top of the physical hardware.
您所描述的是内存映射IO，这绝不是唯一的方法，甚至不是标准方法。即使在这种情况下，系统调用也会发生，尽管它们可能位于应用程序的背后。
当出现页面错误时，即丢失一块内存时，内核仍然会被通知执行所有操作，将页面从块设备放入内存中。需要弄清楚从哪个设备获取信息。对于软件 raid，这可能会非常复杂，而对于其他软件，则可能很简单，只需配置 DMA 传输并让它撕裂即可。也许有些芯片组可以在某些情况下自行完成此操作，但肯定不是全部。
并不是因为您的程序没有执行这些操作，所以没有“系统调用”。然而，这样的抽象允许内核专家更自由地从硬件中榨取最后一盎司的性能。
What you are describing is Memory Mapped IO which is by no means the only way or even the standard way. And even in this scenario system calls happen although they might be behind the back of the application.
When you have a page fault, i.e. a piece of memory is missing, it will still be the kernel being notified to do all the magic to get the pages into memory from the block device. There is something that needs to figure out from which device to get the info. With software raid this can be very convoluted, with others it can be a simple as configuring a DMA transfer and let it rip. Maybe there are chipsets which can do this on their own under certain circumstances, but certainly not all.
It is not because your program is not doing them that there are no "system calls". However such an abstraction allows the kernel specialist more freedom in squeezing the last ounce of performance from the hardware.