루프의 로컬 파일 시스템에서 상대적으로 작은 파일 (몇 KB)을 많이 읽는 코드 조각이 있습니다. 각 파일에는 콘텐츠를 읽을 수 있도록 만들어진 java.io.FileInputStream이 있습니다. 그 과정은 매우 느리고 오래 걸립니다.FileInputStream 버퍼링은 어떻게됩니까?
FIS를 java.io.BufferedInputStream으로 바꾸면 큰 차이가있을 것이라고 생각하십니까?
이미 읽기/쓰기 루프 (BufferedInputStream의 최신 구현 8킬로바이트를 사용)에 유리한 크기의 byte[] buffer를 사용하지 않는 경우, 그것은 것 확실히 메이크업의 차이. 직접 사용해보십시오. OutputStream을 BufferedOutputStream으로 만드는 것을 잊지 마십시오.
그러나 이미 byte[]을 사용하여 버퍼링 한 경우 및/또는 거의 차이가 없으면 하드 디스크 및 I/O 컨트롤러 속도가 병목 현상으로 나타납니다.
나는 그것이 어떤 차이를 만들지 의심 스럽다.
근본적인 문제는 수백 개의 작은 파일입니다. 이 디스크를 읽으면 디스크가 쓰러지고 영원히 걸릴 것입니다. 아무리 잘하면 하드 디스크의 기계적 움직임을 기다리는 시간은 99,9 %입니다.
는이 문제를 해결하는 두 가지 방법이 있습니다 : SSD의에 데이터 저장
를 참조하십시오. 매우 비효율적 인 방식으로 FileInputStream을 읽는 경우 (예 : read()를 byte 단위로 호출), BufferedInputStream을 사용하면 작업이 크게 향상 될 수 있습니다. 그러나 FileInputStream과 함께 합리적인 크기의 버퍼를 이미 사용하고 있다면 BufferedInputStream으로 전환하는 것은 중요하지 않습니다.
매우 작은 파일을 많이 말하고 있기 때문에 파일 작업의 실제 바이트가 아닌 디렉토리 작업 (열기, 닫기)으로 인해 많은 지연이 발생할 가능성이 큽니다.
직접 차이를 측정 해 보시지 않겠습니까? 이것은 JVM 등에서 자신의 환경에서 어떻게 작동 하는지를 알 수있는 유일한 방법입니다. –
저는 실제로 이것을 제 환경에서 측정했습니다. FIS를 BIS에 포장 할 때 큰 개선점은 없습니다. –