이번엔 윤종현님이 놀라움을 표현해주신 '데드락 스레드를 찾을 수 있는 함수!'에 대해 자세히 살펴보겠습니다.
돌려보니 정말로 잘 찾아냅니다.
오해로 뒤엉켜 사랑에서 빠져나오지 못하는 가슴 아픈 두 스레드를 검출해줍니다.
메서드 이름이 충분히 직관적이라 별다른 설명은 필요없지만 예제코드 89라인에서
interrupt()로 데드락을 빠져나와보려는 무의미한 시도를 해본 것처럼
결과적으로 검출해서 뭐하지?
하는 생각이 들지 않을 수 없습니다.
이에 method-doc 에는 이렇게 써있습니다.
This method is designed for troubleshooting use, but not for synchronization control. It might be an expensive operation.
그렇습니다. 데드락을 찾아서 뭔가 해결을 해줄 수 있다면야, MXBean 계열에 이녀석이 포함되어있지도 않았을 것입니다.
아무튼 synchronized 키워드의 blocking을 강제로 피하게 할 수 없다는 것은 여전히 슬픈 일입니다.
ReetrantLock.tryLock은 timeout을 받을 수 있고 interruptable 이므로 데드락 검출시 이를 해결해줄 수
있겠다는 생각을 하여 ReetrantLock을 사용하여 Deadlock2 예제를 만들어보았습니다.
와와 데드락 검출 후 해당 thread.interrupt()로 데드락을 붕괘시키는데 성공했습니다! ㅎㅎ
한가지 아쉬운 것은, 스레드가 데드락인지 검출할 수 있다면 pair로 찾거나 서로 엉킨 녀석들을 세트로 묶어 리턴해준다면 더 좋았지 않았을까 하는 생각이 듭니다.
데드락 특성상 한 놈만 포기해주면 나머지가 행복해질 수 있는거니 말입니다.
생각해보니, 데드락된 스레드들의 stack을 덤프해다 담당 프로그래머에게 던져주며 "야
" 하면 되겠군요..![]()
Comments
5 thoughts shared
Continue Reading
Discover more thoughts and insights
J2SE 6 이야기 - Provide true double buffering
제목에서 알 수 있듯이 '그럼 여태까진 구라 더블버퍼링이였단 말이냐? :@'를 나타낸다. mustang(b32 - 윈도우즈, b48 - 솔라리스, 리눅스)에서 적용됐다니 지금 배포되는 RC에선 물론 포함된
출근 셔틀에서 쓴 쓴소리 노트
출근 셔틀에서 즐기는 노트 어제 오전 회의 이야기. 아무리 회사 일을 열심히 안 한다고는 하지만 정규직으로 돈을 받고 있으니 조직을 망가뜨릴 만한 중요한 사건을 눈앞에서 발견하면 쓴소리를 하지 않을 수
Stereotype
사람들이 내게 할당한 수많은 고정관념들이 있다. 그 종류도 다양하고 별의별 말도 안되는 것들이 수두룩한데, 가만히 보고 있으면 내 이야기인데도 전혀 기분나쁘지 않고 재미있고 흥미진진할 때가 참 많다. 그래서 어떠한