다른 언어로 읽기: English Español 中文
줄 중단점 설정, 값 로그 또는 표현식 평가 방법을 알려주는 디버거 튜토리얼이 많이 있습니다. 이러한 지식만으로도 애플리케이션 디버깅을 위한 많은 도구를 제공할 수 있지만 실제 시나리오는 좀 더 복잡할 수 있으며 더 고급 접근 방식이 필요할 수 있습니다.
이번 글에서는 별다른 디자인 지식 없이도 UI 정지를 일으키는 코드를 찾아내고, 잘못된 코드를 실시간으로 수정하는 방법을 알아보겠습니다.
따라가고 싶다면 다음 저장소를 복제하여 시작하세요: https://github.com/flounder4130/debugger-example
어떤 작업을 수행할 때 충돌이 발생하는 복잡한 애플리케이션이 있다고 가정해 보겠습니다. 버그를 재현하는 방법을 알고 있지만, 이 기능을 담당하는 코드 부분을 모른다는 것이 어려운 점입니다.
예제 앱에서는 버튼 N을 클릭하면 절전 모드가 발생합니다. 그러나 이 작업을 담당하는 코드를 찾는 것은 그리 쉽지 않습니다.
디버거를 사용하여 어떻게 찾을 수 있는지 살펴보겠습니다.
줄 중단점에 비해 메소드 중단점의 장점은 전체 클래스 계층에서 사용할 수 있다는 것입니다. 이것이 우리의 경우에 어떻게 유용합니까?
예제 프로젝트를 보면 모든 액션 클래스가 하나의 메소드(perform())를 사용하여 액션 인터페이스에서 파생되는 것을 볼 수 있습니다.
이 인터페이스 메서드에 메서드 중단점을 설정하면 파생 메서드 중 하나가 호출될 때마다 애플리케이션이 일시 중지됩니다. 메소드 중단점을 설정하려면 메소드를 선언하는 줄을 클릭하세요.
디버거 세션을 시작하고 N 버튼을 클릭하세요. ActionImpl14에서 애플리케이션이 일시중단되었습니다. 이제 이 버튼에 해당하는 코드가 어디에 있는지 알 수 있습니다.
이 문서에서는 버그를 찾는 데 중점을 두었지만 이 기술은 대규모 코드베이스에서 어떤 것이 어떻게 작동하는지 이해하려는 경우 많은 시간을 절약할 수도 있습니다.
메서드 잠금 지점을 사용한 접근 방식은 잘 작동하지만 상위 인터페이스에 대해 알고 있다는 가정을 기반으로 합니다. 이 가정이 틀렸거나 다른 이유로 이 접근 방식을 사용할 수 없으면 어떻게 되나요?
중단점이 없어도 이 작업을 수행할 수 있습니다. N버튼을 클릭하고 애플리케이션이 잠겨 있는 동안 IntelliJ IDEA로 이동합니다. 메인 메뉴에서 실행 | 디버깅 작업 | 일시정지 프로그램.
애플리케이션이 일시 중지되므로 스레드 및 변수 탭에서 스레드의 현재 상태를 검사할 수 있습니다. 이를 통해 애플리케이션이 현재 수행 중인 작업을 이해할 수 있습니다. 잠겨 있기 때문에 잠금 방식을 파악하고 호출 위치를 역추적할 수 있습니다.
이 접근 방식은 보다 전통적인 스레드 덤프에 비해 몇 가지 장점이 있습니다. 이에 대해서는 곧 다루겠습니다. 예를 들어 변수에 대한 정보를 편리한 방법으로 제공하고 추가 프로그램 실행을 제어할 수 있습니다.
참고: 프로그램 일시 중지에 대한 추가 팁과 요령은 중단점 없는 디버그 및 Debugger.godMode()를 참조하세요.
마지막으로 엄밀히 말하면 디버거 기능이 아닌 스레드 덤프를 사용할 수 있습니다. 디버거 사용 여부와 관계없이 사용 가능합니다.
N버튼을 클릭하세요. 애플리케이션이 잠겨 있는 동안 IntelliJ IDEA로 이동합니다. 메인 메뉴에서 실행 | 디버깅 작업 | 스레드 덤프 가져오기.
왼쪽에서 사용 가능한 스레드를 살펴보고 AWT-EventQueue에서 문제의 원인을 확인할 수 있습니다.
스레드 덤프의 단점은 작성 당시 프로그램 상태의 스냅샷만 제공한다는 것입니다. 스레드 덤프를 사용하여 변수를 탐색하거나 프로그램 실행을 제어할 수는 없습니다.
이 예에서는 스레드 덤프에 의존할 필요가 없습니다. 하지만 이 기술은 디버그 에이전트 없이 시작된 애플리케이션을 디버그하려고 할 때와 같은 다른 경우에도 유용할 수 있으므로 계속 언급하고 싶었습니다.
디버깅 기술에 관계없이 ActionImpl14에 도달합니다. 이 수업에서는 누군가 별도의 스레드에서 작업을 수행하려고 했지만 Thread.start()를 호출 코드와 동일한 스레드에서 코드를 실행하는 Thread.run()과 혼동했습니다.
IntelliJ IDEA의 정적 분석기는 디자인 타임에 이에 대해 경고합니다.
과중한 작업(또는 이 경우 과도한 절전)을 수행하는 메서드는 UI 스레드에서 호출되며 메서드가 완료될 때까지 이를 차단합니다. 그렇기 때문에 N버튼을 클릭한 후 한동안 UI에서는 아무것도 할 수 없습니다.
이제 버그 원인을 찾았으니 문제를 해결해 보겠습니다.
프로그램을 중지하고 코드를 다시 컴파일한 다음 다시 실행할 수 있습니다. 하지만 단지 작은 변화를 위해 전체 애플리케이션을 다시 접는 것이 항상 편리한 것은 아닙니다.
현명하게 대처해 보세요. 먼저 제안된 빠른 수정을 사용하여 코드를 수정하세요.
코드가 준비되면 실행 | 디버깅 작업 | 변경된 클래스를 다시 로드하세요. 새 코드가 VM에 도달했음을 확인하는 메시지가 나타납니다.
앱으로 돌아가 확인해 보겠습니다. N 버튼을 클릭해도 더 이상 앱이 충돌하지 않습니다.
팁: HotSwap에는 한계가 있다는 점을 기억하세요. HotSwap의 확장된 기능에 관심이 있다면 DCEVM 또는 JRebel과 같은 고급 도구를 살펴보는 것이 좋습니다.
추론과 일부 디버거 기능을 사용하여 프로젝트에서 UI를 정지시키는 코드를 찾을 수 있었습니다. 그런 다음 실제 프로젝트에서 시간이 많이 걸릴 수 있는 재컴파일 및 재배포에 시간을 낭비하지 않고 코드 수정을 진행합니다.
설명된 기술이 유용하길 바랍니다. 당신의 생각을 알려주세요!
디버깅 및 프로파일링과 관련된 더 많은 기사에 관심이 있다면 내 다른 기사를 확인하세요.
위 내용은 비활성 애플리케이션 디버깅의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
