Невозможно увидеть мои собственные методы приложения в Java VisualVM

Я пытаюсь профилировать мое приложение java, просто чтобы узнать методы, в которых проводится большинство времени. Учитывая плохие реакции здесь на TPTP, я думал, что я дам Java VisualVM.

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

Я не вижу ничего, что связано с МОИМ СОБСТВЕННЫМ кодом - все, что я получаю, это целая куча вызовов таких вещей, как java. * methods.

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

Каждый раз, когда я запускаю, я получаю различное количество инструментов, которые варьируются от 10 до 1000. Я попытался заснуть в начале моего приложения, чтобы убедиться, что я запускаю VisualVM, прежде чем мое приложение начнет делать что-нибудь интересное, чтобы убедиться, что оно профилируется при запуске интересного материала.

Есть ли что-то, что мне нужно сделать, чтобы мои классы стали инструментами? Есть ли вопросы времени?.. like, нужно ждать загрузки классов и т.д.? Я также пытался запустить кишки кода дважды, чтобы убедиться, что весь код выполняет упражнение...

Я просто запускаю приложение, с основным, из Eclipse. Я попытался использовать интеграцию Eclipse, чтобы VisualVM запускался, когда я запускаю приложение - результаты одинаковы. Я также попытался экспортировать приложение в качестве запускаемого приложения и запустить его отдельно от командной строки, а не через Eclipse - тот же результат.

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

Буду благодарен за любые советы о том, что я могу делать неправильно!:)

Спасибо!

Ответ 1

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

Java VisualVM дает причудливые результаты для профилирования CPU. Кто-нибудь еще сталкивается с этим?

Я могу рассказать вам несколько странных вещей, которые я узнал о VisualVM, и о том, как это похоже на его профилирование.

VisualVM, по-видимому, подсчитывает общее время, проведенное внутри метода (время настенных часов). У меня есть поток в моем приложении, который запускает ряд других потоков, а затем сразу блокирует ожидание сообщения в очереди. VisualVM не регистрирует этот метод в профилировщике, пока один из других потоков не отправит сообщение, которое ожидал первый поток (когда приложение завершается). Внезапно вызов метода блокировки доминирует над профилирующим выходом и записывается как занимающий более 80% времени приложения.

Другие профилировщики, такие как JProfiler и тот, который используется Azul, не считаются заблокированной нитью, поскольку занимают время для профилировщика. Это означает, что методы блокировки, которые, вероятно, не интересны (зависящие от ситуации) для профилирования производительности, скрывают ваш взгляд на этот код, который потребляет ваше процессорное время.

Когда я запускаю профилирование, я получаю

sun.rmi.transport.tcp.TCPTransport $ConnectionHandler.run()

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

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

Не очень полезный ответ. Решение, как я вижу сейчас, это заплатить за JProfiler - VisualVM просто не кажется заслуживающим доверия для этой задачи.

Ответ 2

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

У облегченной версии есть много ограничений, таких как выборка 10min max и 30 новых транзакций.

Было бы неплохо иметь бесплатные инструменты, которые делают то же самое

Ответ 3

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

Например, вы говорите, что ищете "методы, в которых проводится большинство времени". Если под этим вы подразумеваете "собственное время" (счетчик программ фактически в методе), вероятно, очень мало, если только у вас нет интенсивных циклов. Методы обычно проводят время, вызывая другие методы, иногда делая I/O.

Еще одна нечеткая идея заключается в том, что время измерительного метода или подсчет количества вызовов может рассказать вам о том, где узкие места. Узкие места - это определенные строки кода, а не методы, поэтому даже если вы знаете, где искать, вы все еще играете в детектив.

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

Когда вы в конце концов что-то исправите, это сократит время выполнения на несколько процентов, например (выберите число) 30%, правильно? (В противном случае вы ничего не исправили.) Хорошо, во время этого 30% это что-то делало, чего не нужно было делать, потому что позже вы избавились от него. Таким образом, вам не нужно измерять. Вам нужно выяснить, что он делает в это время, поэтому вы знаете, что нужно избавиться.

Очень простой способ - "приостановить" его 10 (или некоторое количество) раз в случайном порядке. Поймите, что он делает и почему, посмотрев на стек вызовов и, возможно, на некоторые данные. Примерно в 3 из этих случаев вы увидите, что он делает что-то, от чего вы можете избавиться.

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

Тогда не останавливайтесь. Вы сделали приложение быстрее. Сделайте это снова и сделайте это быстрее. Рано или поздно вы дойдете до такой степени, что вы не сможете сделать это быстрее, но, возможно, более чем на один шаг.