Читать на других языках: English Português 中文

Существует множество руководств по отладчику, которые научат вас устанавливать точки останова на строке, регистрировать значения или оценивать выражения. Хотя одни только эти знания дают вам множество инструментов для отладки вашего приложения, реальные сценарии могут быть немного сложнее и требовать более продвинутого подхода.

В этой статье мы узнаем, как найти код, вызывающий сбой пользовательского интерфейса, без особых предварительных знаний о проекте, и исправить сломанный код на лету.

Проблема

Если вы хотите последовать примеру, начните с клонирования этого репозитория: https://github.com/flounder4130/debugger-example

Предположим, у вас есть сложное приложение, которое аварийно завершает работу при выполнении какого-либо действия. Вы знаете, как воспроизвести ошибку, но сложность в том, что вы не знаете, какая часть кода отвечает за этот функционал.

В нашем примере приложения сбой происходит при нажатии кнопки Кнопка N. Однако найти код, отвечающий за это действие, не так-то просто:

Давайте посмотрим, как можно использовать отладчик, чтобы найти его.

Точки останова метода

Преимущество точек останова метода перед точками останова строки заключается в том, что их можно использовать во всех иерархиях классов. Чем это полезно в нашем случае?

Если вы посмотрите на пример проекта, то увидите, что все классы действий получены из интерфейса Action с помощью одного метода: Perform().

Установка точки останова для этого метода интерфейса приведет к приостановке работы приложения каждый раз при вызове одного из производных методов. Чтобы установить точку останова метода, щелкните строку, объявляющую метод.

Запустите сеанс отладки и нажмите Кнопку N. Приложение приостановлено на ActionImpl14. Теперь мы знаем, где находится код, соответствующий этой кнопке.

Хотя в этой статье мы сосредоточены на поиске ошибки, этот метод также может сэкономить вам много времени, если вы хотите понять, как что-то работает в большой базе кода.

Приостановить приложение

Подход с точками останова метода работает нормально, но он основан на предположении, что мы что-то знаем о родительском интерфейсе. Что, если это предположение неверно или мы не можем использовать этот подход по какой-то другой причине?

Ну, мы можем сделать это даже без точек останова. Нажмите кнопку N и, пока приложение зависает, перейдите в IntelliJ IDEA. В главном меню выберите Выполнить | Действия отладки | Приостановить программу.

Приложение будет приостановлено, что позволит нам проверить текущее состояние потоков на вкладке Потоки и переменные. Это дает нам представление о том, что делает приложение в этот момент. Поскольку он зависает, мы можем определить метод, вызвавший блокировку, и отследить его до места вызова.

Этот подход имеет некоторые преимущества перед более традиционным дампом потока, о котором мы вскоре расскажем. Например, он предоставляет вам информацию о переменных в удобной форме и позволяет контролировать дальнейшее выполнение программы.

Совет: дополнительные советы и рекомендации по использованию Приостановить программу см. в разделе «Отладка без точек останова» и Debugger.godMode()

Дампы потоков

Наконец, мы можем использовать дамп потока, который не является строго функцией отладчика. Он доступен независимо от того, используете ли вы отладчик.

Нажмите кнопку N. Пока приложение зависает, зайдите в IntelliJ IDEA. В главном меню выберите Выполнить | Действия отладки | Получить дамп темы.

Изучите доступные потоки слева, и в AWT-EventQueue вы увидите причину проблемы.

Недостаток дампов потоков заключается в том, что они предоставляют только снимок состояния программы на момент их создания. Вы не можете использовать дампы потоков для исследования переменных или управления выполнением программы.

В нашем примере нам не нужно прибегать к дампу потока. Однако я все же хотел упомянуть об этом методе, поскольку он может быть полезен и в других случаях, например, когда вы пытаетесь отладить приложение, запущенное без агента отладки.

Понять проблему

Независимо от метода отладки, мы приходим к ActionImpl14. В этом классе кто-то намеревался выполнить работу в отдельном потоке, но перепутал Thread.start() с Thread.run(), который запускает код в том же потоке, что и вызывающий код.

Статический анализатор IntelliJ IDEA даже предупреждает нас об этом во время разработки:

Метод, который выполняет тяжелую работу (или в данном случае много спит), вызывается в потоке пользовательского интерфейса и блокирует его до завершения метода. Именно поэтому мы некоторое время не можем ничего делать в пользовательском интерфейсе после нажатия кнопки N.

Горячая замена

Теперь, когда мы выяснили причину ошибки, давайте ее исправим.

Мы могли бы остановить программу, перекомпилировать код, а затем запустить его снова. Однако не всегда разумно повторно развертывать все приложение только потому, что было внесено небольшое изменение.

Давайте сделаем это разумно. Сначала исправьте код, используя предложенное быстрое исправление:

После того, как код будет готов, нажмите Выполнить | Действия отладки | Перезагрузить измененные классы. Появится всплывающее окно, подтверждающее, что новый код поступил в виртуальную машину.

Вернемся к приложению и проверим. Нажатие Кнопки N больше не приводит к сбою приложения.

Совет: Имейте в виду, что HotSwap имеет свои ограничения. Если вас интересуют расширенные возможности HotSwap, возможно, стоит взглянуть на продвинутые инструменты, такие как DCEVM или JRebel

Краткое содержание

Используя наши рассуждения и пару функций отладчика, мы смогли найти код, который вызывал сбой пользовательского интерфейса в нашем проекте. Затем мы приступили к исправлению кода, не тратя время на перекомпиляцию и распространение, что в реальных проектах может занять много времени.

Надеюсь, описанные приемы окажутся вам полезными. Дайте мне знать, что вы думаете!

Если вас интересуют дополнительные статьи, связанные с отладкой и профилированием, ознакомьтесь с другими моими статьями:

• Debugger.godMode() — взлом JVM-приложения с помощью отладчика
• Устранение неполадок медленного отладчика
• Что не так с createDirectories()? - Руководство по профилированию ЦП
• Отладка без точек останова

Следите за новостями!