궁극적으로 실행중인 플랫폼에 관계없이 항상 최대의 힙을 가지고 있습니다. Windows 32 비트에서 이것은 주변에 있습니다 2GB(특히 힙이 아니라 프로세스 당 총 메모리 양). Java가 기본값을 더 작게 선택하는 것만으로 발생합니다 (아마도 프로그래머 가이 문제를 겪지 않고 실행중인 메모리를 정확하게 검사하지 않고도 메모리 할당량이 많은 프로그램을 만들 수 없음).

따라서 필요한 메모리 양을 결정하거나 사용중인 메모리 양을 줄이기 위해 취할 수있는 몇 가지 방법이 있습니다. Java 또는 C #과 같은 가비지 수집 언어의 일반적인 실수 중 하나는 더 이상 사용 하지 않는 객체에 대한 참조를 유지 하거나 대신 재사용 할 수있을 때 많은 객체를 할당 하는 것입니다. 객체가 객체를 참조하는 한 가비지 수집기는 객체를 삭제하지 않으므로 힙 공간을 계속 사용합니다.

이 경우 Java 메모리 프로파일 러를 사용하여 프로그램에서 많은 수의 오브젝트를 할당하는 메소드를 판별 한 후 더 이상 참조되지 않는지 또는 우선 할당하지 않는 방법을 판별 할 수 있습니다. 과거에 사용한 한 가지 옵션은 “JMP” http://www.khelekore.org/jmp/ 입니다.

이유 때문에 이러한 오브젝트를 할당하고 참조를 유지해야하는 경우 (이 작업을 수행하는 경우에 따라 다름) 프로그램을 시작할 때 최대 힙 크기를 늘려야합니다. 그러나 메모리 프로파일 링을 수행하고 객체 할당 방법을 이해하면 필요한 메모리 양에 대해 더 잘 알고 있어야합니다.

일반적으로 프로그램이 유한 한 양의 메모리에서 (아마도 입력 크기에 따라) 실행될 것이라고 보장 할 수없는 경우 항상이 문제가 발생합니다. 이 모든 것을 다 사용한 후에 만 ​​객체를 디스크 등으로 캐싱해야합니다.이 시점에서 무언가를 위해 “Xgb의 메모리가 필요합니다”라고 말할만한 충분한 이유가 있어야하며 개선하여 해결할 수 없습니다. 알고리즘 또는 메모리 할당 패턴. 일반적으로 이는 데이터베이스 또는 과학적 분석 프로그램과 같은 대규모 데이터 세트에서 작동하는 알고리즘의 경우에만 해당되며 캐싱 및 메모리 매핑 IO와 같은 기술이 유용합니다.

답변

 Run As - Run Configuration - Arguments - Vm Arguments, 

-Xmx2048m