자바가 걸려있는 것처럼 보입니다

Question

나는 커스텀 애플리케이션에서 자바 서비스 래퍼를 사용하여 꽤 오랫동안 잘 작동했습니다. 지난 며칠 동안 애플리케이션을 새 버전으로 업데이트 한 후 JVM이 정지하기 시작했고 래퍼가 로그에 다음을 인쇄합니다. JVM이 멈춘 것 같습니다 : JVM에서 신호 대기 중 시간이 초과되었습니다.

그런 다음 자동으로 JVM을 종료하고 응용 프로그램을 다시 시작합니다. 이것은 약 10 시간의 실행 후에 발생하기 때문에 디버깅이 더 어려워집니다.

물론 나는 우리가 변경 한 것을 살펴볼 것입니다. 그러나이 유형의 문제를 일으키는 것으로 의심되는 큰 변화는 없었습니다.

어디에서 무슨 일이 일어나는지 알아볼 수 있습니까? 응용 프로그램의 디버그 메시지는 흥미로운 것을 나타내지 않습니다. JVM이 그냥 충돌하면 일반적으로 덤프가 생성되어 디버깅에 도움이되지만 걸려 있기 때문에 덤프가 생성되지 않습니다. 서비스를 다시 시작하지 않으면 JVM에서 유용한 정보를 얻으려면 다시 시작할 수 있습니다.

JVM이 일반적인 프로그래밍 오류에서 벗어나지 않아야합니다. 이전에 JVM이 멈추는 원인은 무엇입니까?

Answer 1

클래스 패스 (JBPM)에 라이브러리의 몇 가지 다른 버전이 있습니다. 래퍼를 사용하면 와일드 카드를 사용하여 항아리를 포함 할 수 있습니다. 실수로 당신이해야 할 것보다 더 많이 포함 할 수도 있기 때문에 이것을주의하십시오.

여기서는 debugging hangs in Java에 대한 정보를 제공하는 IBM 기사입니다.

1. 무한 루프,
2. 교착 상태 : 그것은 기본적으로 중단 될 수 있습니다 두 가지가 있다고 말한다.

그 이후로 저는 다른 교수형 문제를 디버깅해야했습니다. 리눅스에서는 콘솔에 쓰레드 덤프를하기 위해 QUIT 신호를 JVM에 보낼 수 있습니다. 이것은 정말로 문제가 어디에 있는지 파악하는 데 도움이됩니다. 그렇게하려면이 명령을 사용하여 프로그램의 전체 메모리를 덤프 내가있는 jmap는 JDK에 포함 된 사용하십시오 요즘 -QUIT

편집 2017년 6월 13일

을 죽일. 그런 다음 Eclipse Memory Analyzer를 사용하여 프로그램이 충돌했을 때의 정확한 상태를 확인합니다. 활성 스레드 목록을보고 각 스택 프레임의 변수를 검사 할 수 있습니다.

/usr/java/latest/bin/jmap -dump:file=/tmp/app-crash.hprof <PID> 

여기서 PID는 Java 프로세스의 프로세스 ID입니다.

Answer 2

어떤 환경입니까? OS, JVM 버전, 하드웨어 아키텍처?

버그처럼 들리지만 시간이 오래 걸리므로 일종의 자원 고갈 버그처럼 들립니다.

Answer 3

wrapper.ping.timeout property에서 읽으십시오. 래퍼 소프트웨어는 JVM과 항상 통신하여 살아 있는지 확인합니다. 어떤 이유로 든 통신이 실패하면 랩퍼는 프로세스가 중단 된 것으로 간주하여 다시 시작하려고 시도합니다.

애플리케이션의 아키텍처에 따라 래퍼가 "핑 (ping)"을 시도 할 때 JVM이 다른 작업을 처리하는 중일 수 있습니다.

Answer 4

Visual VM을 사용하여 진행 상황을 확인하십시오. Visual VM에 전체 시간 동안 응용 프로그램을 모니터링하게하고 작업이 멈 추면 어쩌면 무엇이 잘못되었는지를 판단 할 수 있습니다.

VM이 중단되면 스레드의 상태를 얻을 수 있습니다. Visual VM이 일반적인 ctrl-break (또는 키 조합이 무엇인지)보다 설정을 좀 더 쉽게 만들어 줄 것이라고 생각합니다.

(의견에 따라 편집)

이 시도. 마지막으로 스레드가 번에 걸려 있고 사용중인 메모리가 인 경우 매우 낮기 때문에 은 모두 문제를 일으키지 않습니다. 불행히도 그것이 지연 후 및 래퍼는 그것을 종료 할 수 없습니다 스레드 덤프를 얻을.

디버거를 래퍼없이 실행할 수있는 방법이 있습니까? 또한 NetBeans 프로파일 러를 사용하는 경우 중지 될 때 처리 할 수있는 기회를 줄 수 있습니다 (오늘 나중에 확인하고 다른 방식으로 동작하는지 알아 볼 수 있는지 확인합니다).