Thread dump는 언제 해야 하는 가?
1. Java 어플리케이션이 Hang 상태가 될 때
Hang 상태는 Java 어플리케이션의 Thread들이 멈춰있는 상황입니다.
Shared Resource의 접근할 경우 다른 Thread가 사용할 수 없도록 Lock을 획득하며, 또한 이러한 Lock을 다른 Thread들이 이미 획득하고 있을 경우, Lock을 획득하기 위해 대기하게 됩니다.
Java에서의 Lock은 내부 Monitor를 통해 관리되기 때문에 Monitor 획득이 Lock 획득을 의미합니다.
이렇게 Lock을 획득하기 위해 대기하는 Thread들이 많아지고, 대기 시간이 길어지면 Hang 인것처럼 보여지게 됩니다.
Java 프로그램에서 Lock을 획득하기 위해서는 Synchronized구문을 이용하여 method 또는 block을 단위로 lock을 획득 할 수 있습니다.
2. Java 어플리케이션의 처리가 늦을 경우
Java 어플리케이션의 처리가 늦을 경우 어느 stack에서 지연되는지 확인하기 위해 활용할 수 있습니다.
Thread들이 sleep 단계에서 모두 대기하는 상태가 있을 수 있으며, 이러한 경우의 대표적인 경우가 SQL문 수행의 지연으로 DB에서의 데이터를 Socket read하기 위해 대기하는 상태라 할 수 있습니다.
3. Java 어플리케이션의 CPU 사용율이 높을 경우
Java 어플리케이션의 특정 Thread의 CPU 사용율이 높을 경우
어떻게 해야 하는 가?
일반적으로 3~5초 간격으로 3회 이상을 dump해서 분석 할 것을 권하고 있습니다.
Deadlock 의 대표적인 사례
- Database 에서 지연되어 리스너 객체, 세션 저장객체가 연속적으로 lock이 걸리고 이 lock를 해제 못하는 상태에 빠질 수 있습니다.
- log4j도 과도한 로깅으로 인한 지연될 수 있습니다.
비효율적인 CPU 사용 코드의 예
Hashtable aaa = ..... ;
Object value = null;
if(aaa.containsKey("zzz")) --> 비효율적인 구문
value = aaa.get("zzz"); --> 비효율적인 구문
else
return null;
위의 로직은 Hashtable의 내용을 두번씩 검색하게 되어 불필요한 CPU 자원을 사용하는 경우입니다.
아래와 같이 변경하여 수행한 결과 CPU 자원이1/3 줄어든 것을 확인 할 수 있었습니다.
Hashtable aaa = .....;
Object value = null;
return aaa.get("zzz");
비효율적인 System Call 사용의 예
WAS의 Hot-Deploy 기능을 사용함으로써 매 호출때 마다 ClassLoader가 변경 여부를 확인하기 위해 System call인 stat() 함수를 매번 수행하게 됩니다. 해당 모듈이 변경된 것이 확인 되면 모듈을 신규 반영 하는 작업을 수행하게 되며 즉시 반영이 이루어 집니다.
문제는 매 호출마다 변경 여부 확인을 위해 stat() 함수의 호출이 일어나는 것인데요. 이로 인해 SYSTEM CPU의 과부하가 발생할 수 있습니다. 일반적으로는 SYSTEM CPU가 약간 증가하고 성능이 약간 저하되는 수준이지만 특정 코드에 의해 과부하가 발생할 수 있습니다.
request header 로부터 접속 정보 확인
Singleton Pattern 과 DeadLock
