생성 시간
Java 프로그램이 실행 중일 때 JavaCore 및 HeapDump 파일이 생성되는 경우가 종종 있습니다. 이는 일반적으로 Java 프로그램에 치명적인 문제가 발생할 때 발생합니다.
때로는 치명적인 문제가 발생한 후에도 Java 애플리케이션이 종료되지 않고 계속 실행될 수 있습니다.
그러나 때로는 치명적인 문제가 발생하여 Java 프로세스가 종료되는 경우도 있습니다.
치명적인 오류가 발생하기 전에 Java 애플리케이션의 실행 상태를 유지하기 위해 JVM은 종료되기 전에 JavaCore 및 HeapDump 파일이라는 두 개의 파일을 생성합니다.
차이점은 무엇입니까?
JavaCore는 CPU에 관한 것이고 HeapDump 파일은 메모리에 관한 것입니다.
JavaCore 파일은 주로 특정 시점의 Java 애플리케이션의 각 스레드의 실행 위치, 즉 JVM이 어떤 클래스, 어떤 메소드, 어떤 라인을 실행하는지 저장합니다. 텍스트 파일로 오픈 후 각 스레드의 실행 스택을 확인하고 스택 트레이스로 표시할 수 있습니다. JavaCore 파일을 분석하면 애플리케이션이 특정 지점에서 "멈췄는지", 즉 오랫동안 응답을 받지 못하는 데이터베이스 쿼리와 같이 특정 지점에서 실행하는 데 너무 오랜 시간이 걸리는지 확인할 수 있습니다. 시간이 지나면 결국 시스템 충돌이 발생합니다.
HeapDump 파일은 특정 시간에 JVM 힙에 있는 개체의 사용량을 저장하는 바이너리 파일입니다. 이러한 종류의 파일을 분석하려면 IBM Heap Analyser와 같은 도구가 필요합니다. 이 유형의 파일의 가장 중요한 기능은 시스템에 메모리 오버플로가 있는지 분석하는 것입니다.
생성 방법
이 두 파일은 수동으로 생성할 수 있습니다. 시스템이 느려지거나 응답하지 않는 상황이 발생하면 JavaCore 및 HeapDump 파일을 수동으로 생성할 수 있습니다.
Unix/Linux에서 이 두 파일을 생성하는 방법은 다음과 같습니다.
# ps -ef 자바 |
사용자 4616 4582 0 17:30 pts/0 00:00:00 grep 자바
루트 5580 1 0 Oct27 ? 00:02:27 /usr/bin/java -server -XX:PermSize=64M -XX:MaxPermSize=128m -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava. util.logging.config.file=/usr/local/tomcat8090/conf/logging.properties -Djava.endorsed.dirs=/usr/local/tomcat8090/endorsed -classpath :/usr/local/tomcat8090/bin/bootstrap.jar -Dcatalina.base=/usr/local/tomcat8090 -Dcatalina.home=/usr/local/tomcat8090 -Djava.io.tmpdir=/usr/local/tomcat8090/temp org.apache.catalina.startup.Bootstrap 시작
# 죽이기 -3 5580
분석 방법
자바코어 파일
두 세트의 파일은 두 시점의 스레드 실행 위치를 확인할 수 있기 때문에 JavaCore를 분석할 때 특히 효과적입니다. 는 프로그램이 매우 빠르게 실행되기 때문에 여기에 문제가 있을 수 있다는 의미입니다. 특정 지점이 두 번 발생하면 이 두 파일을 분석하면 원인을 찾아 해결할 수 있습니다. 문제.
JavaCore 파일의 헤더에는 "Current Thread Details" 표시가 있는데, 이는 JavaCore가 생성될 때 실행 중인 시스템의 스레드 ID를 기록하며, 이 정보를 통해 해당 스레드의 세부 정보를 찾을 수 있습니다. 스레드가 실행 중이고 JavaCore를 발생시키는 클래스입니다.
NULL ------------------------------------------------- - ----------
0SECTION TITLE 하위 구성 요소 덤프 루틴
NULL ================================
1TISIGINFOOUTOFMEMORY 수신됨
1TIDATETIME 날짜: 2011/12/07 15:59:42
1TIFILENAME Javacore 파일 이름:/usr/WebSphere/AppServer/profiles/WCSProdNode2/javacore19202086.1323298782.txt
NULL ------------------------------------------------- - ----------
0SECTION XHPI 하위 구성요소 덤프 루틴
NULL ==============================
1XHTIME 2011년 12월 7일 수요일 15:59:42
1XHSIGRECV <알 수 없음>의 0x0에서 예기치 않은 신호 -1이 수신되었습니다.
1XHFULLLVERSION J2RE 1.4.2 IBM AIX 빌드 ca142ifx-20090918(SR13 FP2)
NULL
1XHCURRENTTHD 현재 스레드 세부 정보
NULL --------------
2XHCURRSYSTHD "웹컨테이너: 5" sys_thread_t:0x45FB5328
3XHNATIVESTACK 네이티브 스택
널------------
3XHSTACKLINEERR을 사용할 수 없음 - 스택 주소가 유효하지 않음
:::
:::
0SECTION XM 하위 구성 요소 덤프 루틴
NULL ============================
NULL
1XMCURTHDINFO 현재 스레드 세부 정보
NULL --------------
3XMTHREADINFO "WebContainer: 5" (TID:0x70A8E260, sys_thread_t:0x45FB5328, 상태:R, 기본 ID:0x5CC0) prio=5
org.apache.taglibs.standard.tag.common.core.ImportSupport$ImportResponseWrapper.getString의 4XESTACKTRACE(알 수 없는 소스)
org.apache.taglibs.standard.tag.common.core.ImportSupport.acquireString(알 수 없는 소스)의 4XESTACKTRACE
org.apache.taglibs.standard.tag.common.core.ImportSupport.doEndTag의 4XESTACKTRACE(알 수 없는 소스)
com.ibm._jsp._part._jspx_meth_c_import_3(_part.java(컴파일 코드))의 4XESTACKTRACE
com.ibm._jsp._part._jspx_meth_c_otherwise_3(_part.java(컴파일 코드))의 4XESTACKTRACE
com.ibm._jsp._part._jspx_meth_c_choose_4(_part.java(컴파일 코드))의 4XESTACKTRACE
com.ibm._jsp._part._jspService(_part.java:3237)의 4XESTACKTRACE
힙 덤프 파일
HeapDump 파일은 지정된 시간의 Java 스택의 스냅샷으로 일종의 이미지 파일입니다. 힙 분석기 도구는 HeapDump 파일을 분석하여 메모리 누수를 유발하거나 메모리 누수를 일으킬 수 있는 객체를 찾기 위해 너무 많은 스택 공간을 차지하는 객체를 찾습니다.