Java 프로그래머가 알아야 할 JVM 명령줄 플래그 5개

본고는 Neward & Associates의 총재인 Ted Neward가 개발자워크스를 위해 단독으로 저술한'당신은 5개를 몰라요...'시리즈 중 하나입니다. JVM은 다수의 개발자들이 당연하게 여기는 자바 기능과 성능 뒤에 있는 무거운 부하 기계입니다.그러나 JVM이 어떻게 작업을 하는지 이해하는 사람은 드물다. 예를 들어 작업 분배와 쓰레기 수집, 라인 돌리기, 파일 열기와 닫기, 중단 및/또는 JIT가 자바 바이트 코드를 컴파일하는 등이다.
JVM에 익숙하지 않으면 애플리케이션 성능에 영향을 미칠 수 있을 뿐만 아니라 JVM에 문제가 발생할 경우 복구를 시도하는 것도 어렵습니다.
본고는 자바 가상 기기의 성능을 진단하고 조정할 수 있는 명령행 로고를 소개할 것입니다.
1.DisableExplicitGC
나는 몇 번이나 사용자가 나에게 응용 프로그램의 성능 문제에 대해 자문을 요청했는지 기억이 나지 않는다. 사실 크로스 코드가 grep를 신속하게 실행하기만 하면 목록 1과 같은 문제인 원시 자바 성능 반모드를 발견할 수 있다.
명세서 1.System.gc();

// We just released a bunch of objects, so tell the stupid  

// garbage collector to collect them already!  

System.gc();

현식 쓰레기 수집은 당신과 미친 투우견을 한 전화박스에 잠그는 것과 같은 아주 나쁜 생각이다.호출된 구문은 구현에 의존하지만, JVM이 세대별 쓰레기 수거기 (대부분) 시스템을 실행하고 있는 경우.gc();VM에 무리한 "모두 청소"를 강요할 필요는 없지만모든 청소는 일반적인 GC 조작보다 몇 개의 수량급이 비싸다. 이것은 간단한 수학 문제일 뿐이다.
제 말을 마음에 두지 않으셔도 됩니다. 썬의 엔지니어는 이 특수한 인공 오류에 JVM 로고를 제공합니다.XX: + DisableExplicitGC 플래그가 자동으로 시스템을gc() 호출은 빈 동작으로 변환되어 코드를 실행할 수 있는 기회를 제공합니다. 시스템을 직접 보십시오.gc()는 전체 JVM 수행에 유해합니다.
2.HeapDumpOnOutOfMemoryError
JVM은 사용할 수 없으며 OutOfMemory Error를 계속 내보냅니다. 디버거를 만들어서 캡처하거나 볼 수 없습니다.이런 우발적이거나 확실하지 않은 문제는 통상적으로 개발자를 미치게 한다.
바이어 자부심
Sun/Oracle의 VM을 제외한 모든 명령줄 플래그를 지원하는 VM은 아닙니다.표지가 지원되는지 확인하는 가장 좋은 방법은 그것이 정상적으로 작동하는지 확인하는 것이다.만약 이 표지들이 기술적으로 지원되지 않는다면, 그것을 사용하려면 당신이 모든 책임을 져야 합니다.만약 이 로고 중 하나가 당신의 코드, 당신의 데이터, 당신의 서버 또는 당신의 모든 것을 흔적도 없이 사라지게 한다면 저, Sun/Oracle, IBM은 모두 책임을 지지 않을 것입니다.만약을 대비하여 먼저 가상(비상생산) 환경에서 실험하는 것을 권장합니다.
이 시점에서 당신이 원하는 것은 JVM이 사라질 때 무더기를 포획하는 스냅샷입니다. 바로 - XX: + HeapDumpOnOut OfMemory Error 명령으로 이 작업을 완성할 수 있습니다.
이 명령을 실행하면 JVM이 스냅샷 덤프를 촬영하고 이를 처리하기 위해 파일에 저장할 것을 알립니다. 보통 jhat 유틸리티를 사용합니다.적절한 -XX:HeapDumpPath 플래그를 사용하여 파일을 저장할 실제 경로를 지정할 수 있습니다.파일이 저장된 위치에 관계없이 파일 시스템 및/또는 Java 프로세스에 쓰기 권한이 있어야 합니다.
3.bootclasspath
클래스를 정기적으로 클래스 경로에 넣는 것은 매우 도움이 된다. 이런 경로는 재고 JRE에 첨부된 클래스 경로나 어떤 방식으로 확장된 JRE 클래스 경로와 약간 다르다.새 Java Crypto API 공급자가 그 예입니다.JRE를 확장하려면 사용자 정의 구현은 부트 프로그램인 ClassLoader를 사용해야 합니다. 이 부트 프로그램은 rt.jar의java를 불러올 수 있습니다.lang.Object 및 모든 관련 파일
rt.jar를 불법으로 열고 사용자 정의 구현이나 새 패키지를 옮길 수 있지만, 기술적으로 JDK를 다운로드할 때 동의한 협의를 위반했습니다.
반면 JVM 자체 -Xbootclasspath 옵션과 피부 -Xbootclasspath/p 및 -Xbootclasspath/a를 사용합니다.
- Xbootclasspath를 사용하면 전체 부트 클래스 경로 (일반적으로 rt.jar에 대한 참조를 포함) 와 다른 JDK와 함께 제공되는 (rt.jar의 일부가 아닌) JAR 파일을 설정할 수 있습니다. -Xbootclasspath/p는 기존 bootclasspath에 값을 미리 설정하고 -Xbootclasspath/a를 추가합니다.
예를 들어 라이브러리의java를 수정했습니다.lang.Integer, 하위 경로mods 아래에 수정을 놓으면 -Xbootclasspath/amods 매개 변수는 새 Integer를 기본 매개 변수 앞에 놓습니다.
4.verbose
가상 또는 모든 종류의 자바 응용 프로그램에 대해 -verbose는 매우 유용한 일급 진단 사용 프로그램이다.이 표지는 gc,class,jni 세 개의 하위 표지가 있다.
개발자는 JVM 스팸 수집기가 고장나거나 성능이 저하되었는지 찾으려고 하는데, 보통 gc를 실행하는 것이 우선이다.불행하게도 gc 출력을 설명하는 것은 매우 번거롭다. 책 한 권을 쓰기에 충분하다.더 심각한 것은 명령줄에 인쇄된 출력이 다른 Java 버전에 있거나 다른 JVM에 있지 않으면 바뀌어 정확한 해석이 더욱 어려워진다는 것이다.
일반적으로 스팸 컬렉터가 세대별 컬렉터인 경우 (대부분의 엔터프라이즈급 VMs는 해당)어떤 가상 로고가 나타나 GC 통로를 모두 청소하는 것을 가리킨다.Sun JVM에서 로고는 GC 수송의 시작은 "[FullGC...]형식이 나타나다.
ClassLoader와/또는 일치하지 않는 클래스 충돌을 진단하려면class가 큰 도움이 될 수 있습니다.이것은 클래스가 언제 불러오는지 보고할 뿐만 아니라, 클래스가 어디에서 불러오는지, JAR로 가는 경로 (JAR에서 온 경우) 를 포함한다.
jni는 JNI나 로컬 라이브러리를 사용할 때를 제외하고는 거의 사용하지 않습니다.열 때, 로컬 라이브러리가 언제 불러오는지, 방법이 언제 되돌아오는지 등 각종 JNI 이벤트를 보고합니다.다시 한 번 강조하지만 다른 JVM 버전에서는 출력이 변경됩니다.
5.Command-line-X
JVM에서 제공하는 내가 좋아하는 명령행 옵션을 열거했지만, 명령행 매개 변수 -X를 실행하고 JVM에서 제공하는 모든 비표준(하지만 대부분 안전한) 매개 변수를 열거하는 것을 스스로 발견해야 할 필요가 있습니다. 예를 들면:
-Xint, 해석 모드에서 JVM을 실행합니다(JIT 컴파일러가 실제로 코드에 작용하는지 테스트하거나 JIT 컴파일러에 버그가 있는지 확인하는 데 유용합니다).
-Xloggc:, -verbose: gc와 같은 일을 하지만 명령줄 창으로 출력하지 않고 파일을 기록합니다.
JVM 명령줄 옵션은 항상 변경되므로 정기적으로 보는 것이 좋습니다.심지어 심야에 모니터를 쳐다보고 오후 5시에 집에 가서 아내 아이와 저녁을 먹거나(Mass Effect 2에서 적을 처치하고 취향에 따라) 모두 다르다.
끝말
생산 환경에서 명령줄 표지는 영구적으로 사용하기 위해 설계된 것이 아니다. 사실상 JVM 쓰레기 수집기를 조정하는 데 사용되는 표지를 제외하고는 생산용으로 사용되는 비표준 명령줄 표지가 하나도 없다.그러나 다른 방면에서 완전히 불투명한 가상 기기의 내부 작업을 탐색하는 도구로서 매우 유용하다.