다른 언어로 읽기: English Português 中文

줄 중단점 설정, 값 로그 또는 표현식 평가 방법을 알려주는 디버거 튜토리얼이 많이 있습니다. 이 지식만으로도 애플리케이션을 디버깅할 수 있는 많은 도구가 제공되지만 실제 시나리오는 좀 더 복잡할 수 있으며 더 고급 접근 방식이 필요할 수 있습니다.

이 글에서는 프로젝트에 대한 사전 지식 없이도 UI 충돌을 일으키는 코드를 찾아 즉시 깨진 코드를 수정하는 방법을 알아봅니다.

문제

예제를 따르려면 다음 저장소를 복제하여 시작하세요: https://github.com/flounder4130/debugger-example

어떤 작업을 수행할 때 충돌이 발생하는 복잡한 애플리케이션이 있다고 가정해 보겠습니다. 오류를 재현하는 방법을 알고 있지만 코드의 어느 부분이 이 기능을 담당하는지 모른다는 것이 어렵습니다.

예제 애플리케이션에서는 버튼 N을 클릭하면 충돌이 발생합니다. 그러나 이 작업을 담당하는 코드를 찾는 것은 그리 쉽지 않습니다.

디버거를 사용하여 이를 찾는 방법을 살펴보겠습니다.

메소드 중단점

줄 중단점에 비해 메소드 중단점의 장점은 클래스의 전체 계층 구조에서 사용할 수 있다는 것입니다. 이것이 우리의 경우에 어떻게 유용합니까?

예제 프로젝트를 보면 모든 액션 클래스가 하나의 메소드(perform())를 사용하여 액션 인터페이스에서 파생되는 것을 볼 수 있습니다.

이 인터페이스 메서드에 메서드 중단점을 설정하면 파생 메서드 중 하나가 호출될 때마다 애플리케이션이 일시 중단됩니다. 메서드 중단점을 설정하려면 메서드를 선언하는 줄을 클릭하세요.

디버깅 세션을 시작하고 버튼 N을 클릭하세요. ActionImpl14에서 애플리케이션이 일시중단되었습니다. 이제 이 버튼에 해당하는 코드가 어디에 있는지 알 수 있습니다.

이 문서에서는 버그를 찾는 데 중점을 두었지만 이 기술을 사용하면 대규모 코드 베이스에서 무언가가 어떻게 작동하는지 이해하려고 할 때 많은 시간을 절약할 수 있습니다.

신청 일시중지

메서드 중단점을 사용한 접근 방식은 잘 작동하지만 상위 인터페이스에 대해 알고 있다는 가정에 의존합니다. 이 가정이 틀렸거나 다른 이유로 이 접근 방식을 사용할 수 없으면 어떻게 되나요?

음, 중단점 없이도 할 수 있습니다. 버튼 N을 클릭하고 애플리케이션이 정지된 동안 IntelliJ IDEA로 이동합니다. 메인 메뉴에서 실행 | 디버깅 작업 | 프로그램 일시 중지.

애플리케이션이 일시 중지되므로 스레드 및 변수 탭에서 스레드의 현재 상태를 검사할 수 있습니다. 이는 해당 순간에 애플리케이션이 무엇을 하고 있는지에 대한 아이디어를 제공합니다. hang 상태이므로 차단을 유발하는 메소드를 식별하고 호출 사이트까지 역추적할 수 있습니다.

이 접근 방식은 보다 전통적인 스레드 덤프에 비해 몇 가지 장점이 있습니다. 이에 대해서는 곧 다루겠습니다. 예를 들어 변수에 대한 정보를 편리한 형태로 제공하고 프로그램의 추가 실행을 제어할 수 있습니다.

팁: 프로그램 일시 중지에 대한 추가 팁과 요령은 중단점 없이 디버깅 및 Debugger.godMode()

스레드 덤프

마지막으로 엄밀히 말하면 디버거 기능이 아닌 스레드 덤프를 사용할 수 있습니다. 디버거 사용 여부와 관계없이 사용 가능합니다.

N버튼을 클릭하세요. 애플리케이션이 충돌하는 동안 IntelliJ IDEA로 이동합니다. 메인 메뉴에서 실행 | 디버깅 작업 | 스레드 덤프 가져오기.

왼쪽에서 사용 가능한 스레드를 탐색하면 AWT-EventQueue에서 문제의 원인을 확인할 수 있습니다.

스레드 덤프의 단점은 작성 당시 프로그램 상태의 스냅샷만 제공한다는 것입니다. 스레드 덤프를 사용하여 변수를 탐색하거나 프로그램 실행을 제어할 수 없습니다.

이 예에서는 스레드 덤프에 의존할 필요가 없습니다. 그러나 이 기술은 디버깅 에이전트 없이 시작된 애플리케이션을 디버깅하려고 할 때와 같은 다른 경우에도 유용할 수 있으므로 계속 언급하고 싶었습니다.

문제를 이해하다

디버깅 기술에 관계없이 ActionImpl14에 도달합니다. 이 클래스에서는 누군가 별도의 스레드에서 작업을 수행하려고 했지만 Thread.start()를 호출 코드와 동일한 스레드에서 코드를 실행하는 Thread.run()과 혼동했습니다.

IntelliJ IDEA의 정적 분석기는 디자인 타임에 이에 대해 경고합니다.

무거운 작업을 수행하는(또는 이 경우에는 잠을 많이 자는) 메서드가 UI 스레드에서 호출되고 메서드가 완료될 때까지 이를 차단합니다. 그렇기 때문에 버튼 N을 클릭한 후 한동안 UI에서 아무것도 할 수 없습니다.

핫스왑

이제 오류 원인을 찾았으니 문제를 해결해 보겠습니다.

프로그램을 중지하고 코드를 다시 컴파일한 다음 다시 실행할 수 있습니다. 그러나 작은 변경이 있었다고 해서 전체 애플리케이션을 재배포하는 것이 항상 현명한 것은 아닙니다.

현명하게 해보자. 먼저 제안된 빠른 수정 방법을 사용하여 코드를 수정하세요.

코드가 준비되면 실행 | 디버깅 작업 | 변경된 클래스를 다시 로드. 새 코드가 VM에 도착했음을 확인하는 풍선이 나타납니다.

다시 신청서로 돌아가 확인해 보겠습니다. 버튼 N을 클릭해도 더 이상 애플리케이션이 충돌하지 않습니다.

팁: HotSwap에는 한계가 있다는 점을 명심하세요. 확장된 HotSwap 기능에 관심이 있다면 DCEVM 또는 JRebel과 같은 고급 도구를 살펴보는 것이 좋습니다.

요약

추론과 몇 가지 디버거 기능을 사용하여 프로젝트에서 UI 충돌을 일으키는 코드를 찾을 수 있었습니다. 그런 다음 실제 프로젝트에서는 시간이 오래 걸릴 수 있는 재컴파일 및 재배포에 시간을 낭비하지 않고 코드 수정을 진행했습니다.

설명된 기술이 유용하길 바랍니다. 어떻게 생각하는지 알려주세요!

디버깅 및 프로파일링과 관련된 더 많은 기사에 관심이 있다면 내 다른 기사를 확인하세요.

• Debugger.godMode() – 디버거를 사용하여 JVM 애플리케이션 해킹
• 느린 디버거 문제 해결
• createDirectories()에 어떤 문제가 있나요? - CPU 프로파일링 가이드
• 중단점 없이 디버그

더 많은 소식을 기대해 주세요!