JMH тестирует с помощью javaagent

Сопровождающий JMH здесь. С точки зрения сопровождающего это похоже на ошибку JMH в том, что он не предоставляет SUID для своих собственных внутренних классов, поэтому он может быть устойчив к безвредному инструментированию. Теперь это исправлено с помощью 3d44d68e45be:

changeset:   960:3d44d68e45be
tag:         tip
user:        shade
date:        Sat Aug 16 15:00:18 2014 +0400
summary:     Apply SUIDs for all Serializable classes: this protects from the benign instrumentation.

Попробуйте использовать передовой JMH и посмотрите, решит ли он проблему для ты. Обратите внимание, что предоставление SUID не защищает нас от вопиющих изменений в форме сериализации, которые может сделать агент Java (например, вставка непереходного поля), поэтому, если BTrace (не) ведет себя подобным образом, у нас проблемы.

Если приведенное выше изменение JMH не работает, отправьте минимальный воспроизводимый сценарий на адрес jmh-dev. список рассылки, мы хотели бы посмотреть, что можно сделать, чтобы смягчить проблему.

В противном случае ищите исключение org.openjdk.jmh.* классов из инструментовки.

Недавно я столкнулся с той же проблемой. Я предполагаю, что это связано с разветвление JMH. Как видно из выходных данных теста, JMH создает ответвление 1 of 1, где JMH запускает свежий экземпляр JVM для каждой тестовой строки. К этим JVM больше не подключен ваш агент.

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

Вместо этого попробуйте аннотировать тесты с помощью @Fork(0), что полностью отключит разветвление. Однако вы должны быть осторожны, если это слишком сильно искажает ваши результаты. Это тот случай, когда ваш код можно сильно оптимизировать с помощью профилирования. Это особенно верно, если вы разделяете код между своими тестами, где профиль из первых тестов будет влиять на ваши другие тесты, обычно в худшую сторону.

Другое решение — также применить агент к разветвленной JVM. Для этого аннотация @Fork предлагает несколько параметров. Для вашего примера вы можете определить:

@Fork(jvmArgs = "-javaagent:/home/ssube/btrace/build/btrace-agent.jar=scriptdir=/home/ssube/btrace/scripts/,port=0")

Однако обратите внимание, что это делает вашу сборку зависимой от вашей файловой системы.