공식 문서에 따르면 Java가 Buffered Streams를 구현하는 이유 중 하나는 다음과 같습니다.
지금까지 본 대부분의 예제는 버퍼링되지 않은 I/O를 사용했습니다. 즉, 모든 읽기 또는 쓰기 요청은 기본 운영 체제에서 직접 처리됩니다. 이러한 요청은 일반적으로 디스크 액세스, 네트워크 활동 또는 기타 상대적으로 비용이 많이 드는 작업을 트리거하므로 프로그램 효율성이 크게 저하될 수 있습니다.
원천:https://docs.oracle.com/javase/tutorial/essential/io/buffers.html
여러 개의 작은 읽기/쓰기 요청에 비해 Linux에서 단일 대규모 읽기/쓰기 요청이 실제로 비용이 많이 듭니까? 전자가 후자에 비해 얼마나 효율적인가요?
답변1
거기 텍스트는 응용 프로그램 내 버퍼링을 의미한다고 생각합니다. 이는 일반적으로 C 라이브러리에 의해 수행됩니다. 예를 들어 getchar(), 전화를 getchar()하면 프로세스 내 버퍼에서 데이터를 반환하는 것은 사용자 모드에서 커널 모드로 전환해야 하는 시스템 호출보다 훨씬 빠릅니다.
여러 개의 작은 읽기/쓰기 요청에 비해 Linux에서 단일 대규모 읽기/쓰기 요청이 실제로 비용이 많이 듭니까?
대규모 요청은 여러 개의 작은 요청으로 인한 오버헤드를 절약하므로 비용이 더 저렴할 수 있습니다. 그런데 이 아이디어는 어디서 얻었나요? 크고 작은 요청을 언급하는 링크된 문서가 보이지 않습니까?
답변2
디스크 블록은 일반적으로 운영 체제에 의해 캐시되므로 대부분의 짧은 읽기 및 쓰기에는 장치에 직접 액세스할 필요가 없습니다. 또한 운영 체제는 일반적으로 두 개의 연속 블록을 읽을 때 이를 인식하고 다음 블록에 대한 선점형 미리 읽기를 실행하므로 필요할 때 이미 캐시되어 있습니다.
그러나 중요한 추가 성능 문제가 있습니다. 프로세스가 시스템 호출을 하면 실행할 준비가 된 다른 프로세스에 CPU를 제공합니다. 시스템 호출이 만족되면 프로세스는 스케줄러 큐에 들어가 차례가 실행될 때까지 기다립니다. CPU를 많이 사용하는 프로세스가 혼합되어 있는 경우 예약될 때마다 최대 시간 조각을 사용하며 프로세스는 액세스할 때마다 해당 시간 조각보다 지연됩니다.