Должен ли я посмотреть на байт-код, который создается компилятором Java?

Question

No

• JIT-компилятор может «преобразовать» байт-код в нечто совершенно иное.
• Это приведет к преждевременной оптимизации.

Yes

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

Я прошу, не зная (очевидно), так что не стесняйтесь перенаправить на гиперссылки JIT.

Answer 1

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

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

Например, если выполняется конкатенация строк, javac оптимизирует конкатенацию для использования StringBuilder и выполнения append методов для конкатенации String s.

Однако, если конкатенация строк выполняется в цикле, на каждой итерации может быть создан новый StringBuilder, что может привести к снижению производительности по сравнению с созданием вручную StringBuilder вне цикла и выполнением только append s внутри петли.

По вопросу о JIT. Компиляция точно в срок будет зависеть от реализации JVM, поэтому не очень легко узнать, что на самом деле происходит с байт-кодом, когда он конвертируется в собственный код, и, более того, мы не можем сказать, какие части JITted (по крайней мере, не без некоторых специфичных для JVM инструментов, чтобы увидеть, какой тип JIT-компиляции выполняется - я не знаю никаких особенностей в этой области, так что я просто размышляю.)

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

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

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

Answer 2

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

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

Answer 3

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

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

Думайте в терминах абстракций. Вам не нужно знать о действиях кварков или атомов при попытке вычислить орбиты планет. Чтобы быть хорошим программистом на Java, вы, вероятно, должны изучить ... гм ... Java. Да, Java, вот и все: -)

Answer 4

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

Не беспокойтесь о производительности до тех пор, пока не обнаружите проблемы после нагрузочного тестирования приложения (или пока весь персонал службы поддержки не линчует вас за этим экраном, который загружается «навсегда»). Затем разбейте узкие места и оставьте остальную часть кода в покое.

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