운영 체제는 데이터 보안을 보호하기 위해 사용자 공간과 시스템 공간을 분리해야 하기 때문에 정확히 말하면 운영 체제는 파일을 읽을 때 파일을 시스템 공간으로 읽어 들인 다음 응용 프로그램의 사용자에게 복사합니다. 프로세스 공간, 즉 질문에서 언급한 것처럼 프로그램 자체의 버퍼입니다. 사용자 프로세스가 운영체제 공간의 버퍼에 직접 접근하도록 허용한다면 운영체제는 안전하지 않을까요?

FileInputStream/FileOutputStream은 read()/write()가 호출될 때마다 IO 작업을 트리거합니다.
BufferedInputStream/BufferedOutputSteam이 read()/write()를 호출하면 매번 IO 작업이 트리거되지 않습니다. 단지 내부 버퍼에 쓰기만 하면 됩니다. IO 작업은 내부 버퍼가 가득 차거나 플러시()가 호출될 때만 트리거됩니다. .

IO 작업이 적을수록 성능이 향상됩니다.

IO를 수행할 때 JVM은 자체 힙 공간에 버퍼로 바이트 배열을 생성합니다. 일반적으로 사용자는 JVM을 통해 메모리(다이렉트버퍼)를 직접 호출할 수 없습니다. 힙 공간 버퍼와 메모리 간의 상호 작용은 다음과 같이 관리됩니다. JVM. 이러한 방식으로 우리는 GC 메커니즘 및 Java 고급 캡슐화 API와 같은 JVM 이점을 활용할 수 있습니다.

운영 체제는 하드 디스크의 파일을 메모리로 읽어 들여 캐시로 사용할 뿐만 아니라 메모리의 데이터를 캐시하기 위해 메모리에 또 다른 공간을 열어줍니다.
요점이 무엇인가요? 관리 및 효율성을 위해.
메모리와 메모리 사이의 데이터 교환 속도는 메모리와 하드 디스크 사이의 데이터 교환 속도보다 두 자릿수 더 높습니다.
메모리에 있는 프로세스에 데이터가 필요할 때 메모리 캐시에 일치하는 데이터가 있으면 캐시 영역에서 직접 가져옵니다.
그렇지 않으면 하드 디스크에서 읽습니다. (글쓰기도 마찬가지)

IO 작업을 위한 Java 캐시 설계의 중요성도 여기에 있습니다.
차이점은 Java가 캐시한 데이터는 현재 Java 실행 환경에서만 사용할 수 있다는 것입니다.
운영 체제 캐시에서 데이터를 자주 가져오는 것과 비교하면 실행 효율성이 향상됩니다.
코드에 빈번한 IO 작업이 필요한 경우 특히 그렇습니다.

대부분의 버퍼는 하드 디스크 하드웨어에 의해 인터페이스 영역에 캡슐화되어 있으며 버퍼 영역이 크지 않습니다. 운영 체제는 파일 내용을 메모리에 캐시하지 않습니다.

하드 드라이브 속도가 충분히 빠르지 않기 때문입니다!