Because the operating system needs to isolate user space and system space to protect data security. To be precise, when the operating system reads a file, it reads the file into the system space and then copies it to the user space of the application process. That is the program's own buffer that the questioner mentioned. If the user process is allowed to directly access the buffer of the operating system space, wouldn't the operating system be unsafe?
FileInputStream/FileOutputStream Each call to read()/write() will trigger an IO operation. BufferedInputStream/BufferedOutputSteam Calling read()/write() will not trigger an IO operation every time. It only writes to the internal buffer. IO will only be triggered when the internal buffer is full or flush() is called. operate.
The fewer IO operations, the better the performance.
When doing IO, the JVM will create a byte array as a buffer in its own heap space. Generally, users cannot directly call the memory (directbuffer) through the JVM. The interaction between the heap space buffer and the memory is managed by the JVM. In this way, we can take advantage of JVM advantages, such as GC mechanism and Java high-level encapsulated API.
The operating system will not only read the files on the hard disk into the memory for use as cache, but will also open up another space in the memory for caching the data in the memory. What’s the point? For management and efficiency. The data exchange rate between memory and memory is two orders of magnitude higher than the data exchange rate between memory and hard disk. When a process on the memory needs data, if there is matching data in the memory cache, it will be fetched directly from the cache area. If not, it will be read from the hard disk. (The same goes for writing)
The significance of Java designing cache for IO operations is also here. The difference is that the data cached by Java can only be used by the current running environment of Java. Compared with frequently fetching data from the operating system cache, this improves execution efficiency. This is especially true when your code requires frequent IO operations.
Most of the so-called buffers are encapsulated in the interface area by hard disk hardware, and the buffer area is not large. The operating system does not cache file contents into memory.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Because the operating system needs to isolate user space and system space to protect data security. To be precise, when the operating system reads a file, it reads the file into the system space and then copies it to the user space of the application process. That is the program's own buffer that the questioner mentioned. If the user process is allowed to directly access the buffer of the operating system space, wouldn't the operating system be unsafe?
FileInputStream/FileOutputStream Each call to read()/write() will trigger an IO operation.
BufferedInputStream/BufferedOutputSteam Calling read()/write() will not trigger an IO operation every time. It only writes to the internal buffer. IO will only be triggered when the internal buffer is full or flush() is called. operate.
The fewer IO operations, the better the performance.
When doing IO, the JVM will create a byte array as a buffer in its own heap space. Generally, users cannot directly call the memory (directbuffer) through the JVM. The interaction between the heap space buffer and the memory is managed by the JVM. In this way, we can take advantage of JVM advantages, such as GC mechanism and Java high-level encapsulated API.
The operating system will not only read the files on the hard disk into the memory for use as cache, but will also open up another space in the memory for caching the data in the memory.
What’s the point? For management and efficiency.
The data exchange rate between memory and memory is two orders of magnitude higher than the data exchange rate between memory and hard disk.
When a process on the memory needs data, if there is matching data in the memory cache, it will be fetched directly from the cache area.
If not, it will be read from the hard disk. (The same goes for writing)
The significance of Java designing cache for IO operations is also here.
The difference is that the data cached by Java can only be used by the current running environment of Java.
Compared with frequently fetching data from the operating system cache, this improves execution efficiency.
This is especially true when your code requires frequent IO operations.
Most of the so-called buffers are encapsulated in the interface area by hard disk hardware, and the buffer area is not large. The operating system does not cache file contents into memory.
Because your hard drive is not fast enough!