Java가 매달린 것처럼 보입니다

Question

나는 사용자 정의 애플리케이션에서 Java 서비스 래퍼를 꽤 오랫동안 사용해 왔으며 잘 작동했습니다. 지난 며칠 동안 애플리케이션을 새 버전으로 업데이트 한 이후 JVM이 매달려 시작한 다음 래퍼는 로그에서 이것을 인쇄합니다.

그런 다음 자동으로 JVM을 종료하고 앱을 다시 시작합니다. 이것은 약 10 시간의 달리기 후에 발생하므로 디버그하기가 더 어려워집니다.

물론 나는 우리가 한 변화를 살펴볼 것이지만, 이런 유형의 문제를 일으키는 것으로 의심되는 큰 변화는 없었습니다.

무슨 일이 일어나고 있는지 알아 내려고 어디에서 찾을 수 있습니까? 응용 프로그램의 디버그 메시지는 흥미로운 것을 나타내지 않습니다. JVM이 충돌하면 일반적으로 덤프가 생겨 덤프가 생겨 디버깅하는 데 도움이 될 수 있지만 매달려 있으므로 덤프가 생기지 않습니다. 서비스를 자동으로 다시 시작하지 않으면 재시작하기 전에 JVM에서 유용한 정보를 얻기 위해 할 수있는 일이 있습니까?

JVM이 일반적인 프로그래밍 오류에서 매달려서는 안된 것 같습니다. JVM이 매달릴 수 있기 전에 무엇을 달성 했습니까?

Answer 1

ClassPath (JBPM)에 몇 가지 다른 버전의 라이브러리가있었습니다. 래퍼를 사용하면 와일드 카드를 사용하여 항아리를 포함 할 수 있습니다. 실수로 당신이해야 할 것보다 더 많은 것을 포함시킬 수 있으므로 조심하십시오.

다음은 정보를 제공하는 IBM 기사입니다 디버깅은 Java에 매달려 있습니다. 기본적으로 매달릴 수있는 두 가지가 있다고 말합니다.

1. 무한 루프,
2. 교착 상태.

그 이후로 나는 다른 교수형 문제를 디버그해야했습니다. Linux에서는 JVM을 종료 신호를 보낼 수 있도록 스레드 덤프를 콘솔로 보낼 수 있습니다. 이것은 실제로 문제가 어디에 있는지 알아내는 데 도움이됩니다. 이 명령을 사용하여 다음을 수행하십시오

6/13/2017 편집

요즘 나는 JDK에 포함 된 JMAP를 사용하여 프로그램의 전체 메모리를 덤프합니다. 그런 다음 Eclipse 메모리 분석기를 사용하여 프로그램이 충돌했을 때 정확한 상태를 확인합니다. 활성화 된 스레드 목록을보고 각 스택 프레임의 변수를 검사 할 수 있습니다.

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

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

Answer 2

에서 읽으십시오 래퍼 .ping.timeout 속성. 래퍼 소프트웨어는 JVM과 너무 자주 통신하여 살아 있는지 확인합니다. 어떤 이유로 든 해당 커뮤니케이션이 실패하면 래퍼는 프로세스가 매달려있는 것으로 간주하고 다시 시작하려고 시도합니다.

애플리케이션의 구조 방식에 따라 래퍼가 "핑"하려고 할 때 JVM이 다른 처리를 바울 수 있습니다.

Answer 3

당신이 사용할 수 있는지 확인하십시오 시각적 VM 무슨 일이 일어나고 있는지 확인합니다. Visual VM이 앱을 항상 모니터링하고 작동이 중지되면 무엇이 잘못되었는지 결정할 수 있습니다.

VM이 매달려 있으면 스레드의 상태를 얻을 수 있습니다 ... 시각적 VM은 일반적인 CTRL 브레이크 (또는 키 콤보가 무엇인지)보다 설정을 감안할 때 조금 더 쉽게 만들 것이라고 생각합니다.

(댓글에 따라 편집)

이것을 시도했습니다. 지난번에 스레드의 수와 사용중인 메모리의 양이 상당히 낮아서 문제를 일으키지 않았습니다. 불행히도 매달리고 래퍼가 끝나면 스레드 덤프를 얻을 수 없습니다.

래퍼없이 실행할 수있는 방법이 있습니까? 또한 NetBeans Profiler를 사용하는 경우 중지 될 때 처리 할 수있는 기회를 줄 수 있습니다 (오늘 나중에 확인하고 다르게 행동 할 수 있는지 확인할 수 있는지 확인하겠습니다).

Answer 4

당신은 어떤 환경에 있습니까? OS, JVM 버전, 하드웨어 아키텍처?

그것은 버그처럼 들리며, 몇 시간이 걸리기 때문에 어떤 종류의 자원 전분 버그처럼 들립니다.