JVM 시작 속도가 느린 이유는 무엇입니까?

JVM 시작 속도가 느린 이유는 무엇입니까?

---

CPython과 같은 다른 런타임에 비해 JVM (특히 Sun의 구현) 실행 속도를 정확히 만드는 것은 무엇입니까? 내 인상은 주로 라이브러리가 필요하든 그렇지 않든로드되는 많은 라이브러리와 관련이 있지만 수정하는 데 10 년이 걸리지 않아야하는 것처럼 보입니다.

생각해 보면 JVM 시작 시간이 Windows의 CLR과 어떻게 비교됩니까? Mono의 CLR은 어떻습니까?

업데이트 : 특히 유닉스에서 흔히 볼 수 있듯이 함께 연결된 작은 유틸리티의 사용 사례에 관심이 있습니다. 이제 Java가이 스타일에 적합합니까? Java가 발생하는 시작 오버 헤드가 무엇이든, 모든 Java 프로세스에 대해 추가됩니까, 아니면 오버 헤드가 실제로 첫 번째 프로세스에 대해서만 나타 납니까?

---

다음은 Wikipedia가이 문제에 대해 말한 내용입니다 (일부 참고 자료 포함).

대부분의 시간은 디스크에서 데이터 (클래스)를로드하는 데 걸리는 것으로 보입니다 (즉, 시작 시간은 I / O 제한 임).

---

몇 가지 해결책을 참고하십시오.

JVM을 더 빠르게 시작할 수있는 두 가지 메커니즘이 있습니다. 첫 번째는 Java 6 Update 21 이후로 지원되는 클래스 데이터 공유 메커니즘입니다 (핫스팟 클라이언트 VM에서만, 내가 아는 한 직렬 가비지 수집기에서만).

활성화하려면 -Xshare (일부 구현에서는 -Xshareclasses ) JVM 옵션 을 설정해야합니다 .

방문 할 수있는 기능에 대해 자세히 알아 보려면 : 수업 데이터 공유

두 번째 메커니즘은 Java Quick Starter입니다. OS 시작 중에 클래스를 미리로드 할 수 있습니다 . 자세한 내용은 Java Quick Starter 를 참조하십시오.

---

1.6 (Java 6) 클라이언트 JVM으로 간단한 Java 앱을 실행하는 것은 내 컴퓨터에서 즉각적인 것처럼 보입니다. Sun은 더 빠른 시작을 위해 클라이언트 JVM을 조정하려고 시도했습니다 (클라이언트 JVM이 기본값 임). 따라서 많은 추가 jar 파일이 필요하지 않으면 시작 속도가 빨라야합니다.

---

Sun의 x86_64 용 HotSpot (64 비트 컴파일 됨)을 사용하는 경우 현재 구현은 서버 모드에서만 작동합니다. 즉, 전체 최적화로로드되는 모든 클래스를 사전 컴파일하는 반면 32 비트 버전은 일반적으로 최적화를 연기하는 클라이언트 모드도 지원합니다. CPU를 가장 많이 사용하는 부품 만 최적화하지만 시작 시간이 더 빠릅니다.

예를 들어 :

• http://en.wikipedia.org/wiki/64-bit#32_vs_64_bit
• http://java.sun.com/docs/hotspot/HotSpotFAQ.html#64bit_compilers

즉, 적어도 내 컴퓨터 (64 비트 커널이있는 Linux x86_64)에서 32 비트 HotSpot 버전은 클라이언트 및 서버 모드 (-client 및 -server 플래그를 통해)를 모두 지원하지만 기본값은 서버 모드이며 64 비트 버전은 서버 모드.

---

시작하는 동안 무엇을하는지에 따라 다릅니다. Hello World 애플리케이션을 실행하면 내 컴퓨터에서 0.15 초가 걸립니다.

그러나 Java는 클라이언트 또는 서버 / 서비스로 실행하는 데 더 적합합니다. 즉, 시작 시간이 연결 시간 (약 0.025ms) 또는 왕복 시간 응답 시간 (<< 0.001ms)만큼 중요하지 않습니다.

---

여러 가지 이유가 있습니다.

• jar로드 할 많은 s
• 확인 (코드가 악한 일을하지 않는지 확인)
• JIT (Just In Time 컴파일) 오버 헤드

CLR에 대해 잘 모르겠지만 다음 번에 기본 버전의 어셈블리를 캐시하기 때문에 종종 더 빠르다고 생각합니다 (JIT가 필요하지 않음). CPython은 인터프리터이기 때문에 더 빨리 시작되고 IIRC는 JIT를 수행하지 않습니다.

---

이미 언급 한 것 외에도 (압축 된 JAR에서 클래스로드, 특히) HotSpot이 일반적으로 사용되는 바이트 코드를 컴파일하기 전에 해석 모드에서 실행 그리고 HotSpot 컴파일 오버 헤드, JDK 클래스 자체에 의해 수행되는 일회성 초기화도 상당히 많습니다. 시작 속도가 문제가되지 않는 장기 실행 시스템을 위해 많은 최적화가 수행됩니다.

그리고 유닉스 스타일 파이프 라이닝에 관해서는 확실히 JVM을 여러 번 시작하고 다시 시작하고 싶지 않습니다. 그것은 효율적이지 않을 것입니다. 오히려 JVM 내에서 도구 체인이 발생해야합니다. 이는 JVM 내에서 이러한 도구를 시작하는 경우를 제외하고는 Java가 아닌 Unix 도구와 쉽게 혼합 될 수 없습니다.

---

Java 또는 CLR과 같은 리치 유형 시스템을 사용하는 모든 VM은 C 또는 C ++에있는 것과 같은 덜 풍부한 시스템과 비교할 때 즉각적이지 않습니다. 이는 주로 VM에서 많은 일이 일어나고 많은 클래스가 초기화되고 실행중인 시스템에 필요하기 때문입니다. 초기화 된 시스템의 스냅 샷이 도움이되지만 해당 이미지를 메모리 등에 다시로드하는 데는 여전히 비용이 듭니다.

메인이있는 간단한 hello world 스타일의 단일 라이너 클래스는 여전히 많은로드 및 초기화가 필요합니다. 클래스를 확인하려면 많은 종속성 검사 및 유효성 검사가 필요하며 실행되는 데 드는 많은 시간과 많은 CPU 명령이 필요합니다. 반면에 C 프로그램은 이러한 작업을 수행하지 않고 몇 가지 명령을 수행 한 다음 프린터 기능을 호출합니다.

참조 URL : https://stackoverflow.com/questions/844143/why-is-the-jvm-slow-to-start