대용량 파일을 순차적으로 처리하고 있습니다. 64 비트 시스템에서 사용할 수있는 16GB RAM을 메모리에 많이 보관하고 싶습니다.큰 파일을 버퍼링합니다. BufferedInputStream은 2GB로 제한됩니다. 배열은 2^31 바이트로 제한됩니다.
빠르고 간단한 방법은 입력 스트림을 버퍼링 된 입력 스트림으로 간단하게 래핑하는 것입니다. 불행히도 이것은 2GB 버퍼를 제공합니다. 그 중에서 더 많은 것을 기억하고 싶습니다. 어떤 대안이 있습니까?
OS가 파일 버퍼링을 처리하도록하는 방법은 어떻습니까? 전체 파일을 JVM 메모리에 복사하지 않으면 성능에 미치는 영향을 확인 했습니까?
EDIT : 그러면 RandomAccessFile 또는 FileChannel을 사용하여 파일의 필요한 부분을 JVM 메모리로 효율적으로 읽을 수 있습니다.
당신은 java.nio의 MappedByteBuffer를 고려 했습니까? 그것은 내 머리 위로하지만 어쩌면 당신이 찾고있는 것입니다.
나도 그렇게 생각했다.하지만 ByteBuffer의 버퍼는 여전히 정상적인 버퍼 인 것처럼 보이므로 원시 버퍼와 같은 제약이있다. –
두 종류의 버퍼가 있습니다. 하나는 바이트 배열을 사용하고 다른 하나는 직접 (직접) Java 힙에서 고정 된 위치를 사용합니다. 불행히도 neight는 2GB를 초과 할 수 있습니다. 이것은 현재 "더 많은 NIO 기능"(JDK7)에서 수정되지 않았습니다. 그것을 위해 투표하십시오. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6347833 –
비표준 제한을 지원하는 64 비트 JVM이 있다고 생각합니다.
청크를 버퍼링 할 수 있습니다.
나는 한 번에 2GB 이상의 버퍼링이 어쨌든 엄청난 승리가 될 것이라고 의심한다. 진행중인 처리량에 따라 처리하는 속도만큼 빠르게 읽을 수 있습니다. 속도를 높이려면 두 개의 스레드가있는 생산자 - 소비자 모델 (하나의 스레드가 파일을 읽고 다른 스레드로 데이터를 전달하여 처리하도록 함)을 사용해보십시오.
운영 체제가 할 수있는 한 많은 파일을 캐시하므로 캐시 관리자보다 현명하지 못하면 아마도 많은 것을 얻지 못할 것입니다.
성능 측면에서 볼 때 JVM 밖에 바이트를 보관하면 훨씬 더 효율적으로 사용할 수 있습니다 (OS와 JVM 사이의 거대한 데이터 전송은 상대적으로 느립니다). 직접 메모리 블록에 의해 백업 된 MappedByteBuffer를 사용하여이 목표를 달성 할 수 있습니다. A에 대한 article
참조 http://stackoverflow.com/questions/140056/java-advice-on-handling-large-data-volumes-part-deux : 여기
는 적절한 방법-하는 문서의 입력이다 잠재적으로 관련된 질문입니다. – Alexander