java 读取图片字节码_为什么尝试通过读取Java字节码来提高效率可能不是最好的主意

java 读取图片字节码

This article uses examples from the Java source code in (BytecodeDemo.java) and its decompiled bytecode in (BytecodeDemo-decompiled.txt).

In my previous article, I wrote that, "Code that works well is good code." When I say, "works well," I mean both "works correctly" and "works efficiently." We've all pored over bits of code, trying to root out inefficiencies. One of the ways we can examine Java code is by decompiling it, using the javap command from the JDK. (If you're not familiar with how to read bytecode, please see an article like this one for a primer: Java Bytecode Fundamentals)

在上一篇文章中 ，我写道：“行之有效的代码就是好代码。” 当我说“运作良好”时，是指“正确运作”和“有效运作”。 我们都仔细研究了代码的一部分，试图消除效率低下的问题。 我们检查Java代码的方法之一是使用JDK中的javap命令对其进行反编译。 （如果您不熟悉如何读取字节码，请参阅以下文章作为入门：

For example, download BytecodeDemo.java, build it, then run this command:

例如，下载BytecodeDemo.java ，进行构建，然后运行以下命令：

javap -c BytecodeDemo.class

You should see a list of the methods in the BytecodeDemo class, along with the bytecode that the Java VM would execute in order to run those methods. The bytecode definitely shows a few things that could be called "inefficiencies," but it might not be the best idea to "fix" them.

您应该在BytecodeDemo类中看到方法的列表，以及Java VM为了运行这些方法而将执行的字节码。 字节码肯定显示了一些可以称为“效率低下”的东西，但是“修复”它们可能不是最好的主意。

First, look at the bytecode for the computeValueAndDoNothing() method. It calls the computeString() method, but does not use the value it returns. That value is still on the JVM stack, though, so the method has to do that pop operation to get rid of it.

首先，查看computeValueAndDoNothing（）的字节码 方法。 它调用computeString（）方法，但不使用它返回的值。 但是，该值仍在JVM堆栈上，因此该方法必须执行pop操作才能将其删除。

Seems like the computeValueAndDoNothing() method would be more efficient if it didn't have to pop that value, right? The only way to pull that off would be if the computeString() didn't return a value in the first place. We can't do that, though; that method is used in other places—places that do use that value. Let's ignore that inefficiency and move on.

好像computeValueAndDoNothing（） 如果不需要弹出该值，该方法将更有效，对吧？ 实现这一目标的唯一方法是，首先不要在computeString（）中

Look at the bytecode for the computeValueAndUseItlater() method. It stores the value returned by computeString(), then immediately loads it again, so it can be passed to useString(). Wouldn't we be better off if we used the value immediately? That's what the computeValueAndUseItImmediately() method does and its bytecode is two operations shorter.

查看computeValueAndUseItlater（ ）方法。 它存储了computeString（）返回的值，然后立即再次加载它，因此可以将其传递给useString（） 。 如果立即使用该值，我们会更好吗？ 这就是computeValueAndUseItImmedi ately（）方法可以，它的字节码要短两个操作。

That's more efficient, right?

这样更有效，对不对？

Well, maybe it is and maybe it isn't. If our JVM were running purely in interpreted mode (that is, if we used the -Xint command-line argument when starting Java), it would run those exact sequences of operations every time it executed those methods. That's not how the modern Java world works, though; just-in-time (JIT) compilation can kick in at any time and turn a bit of bytecode into machine code. It's entirely possible that the JIT compiler will look at the computeValueAndUseItLater() method and figure out that it doesn't actually need to worry about the value local variable at all, since it's immediately being passed to the useString() method anyway.

好吧，也许是，也许不是。 如果我们的JVM完全在解释模式下运行（也就是说，如果在启动Java时使用-Xint命令行参数），那么它将在每次执行这些方法时运行这些确切的操作序列。 但是，这并不是现代Java世界的工作方式。 即时（JIT）编译可以随时启动，并将一些字节码转换为机器代码。 JIT编译器完全有可能查看computeValueAndUseItLater（ ）方法，并找出它实际上根本不需要担心局部变量的值 ，因为无论如何它都会立即传递给useString（）方法。

That means there's a chance that the JIT compiler will turn the computeValueAndUseItLater() and the computeValueAndUseItImmediately() methods into the same machine code. It might turn out we looked at the bytecode for computeValueAndUseItLater(), saw the "inefficiency," and restructured it to look like computeValueAndUseItImmediately() method. For no good reason!

这意味着JIT编译器有可能会打开computeValueAndUseItLater（ ）和computeValueAndUseItImmedi ately（）方法放入computeValueAndUseItLater（ ） ，看到了“效率低下”的情况，并对其进行了重组，使其看起来像computeValueAndUseItImmedi ately（）方法。

Will the JIT compiler actually make an optimization like this? Probably very few people actually know the real answer to that question. I don't and I'm sure the average Java developer doesn't, either. It's not really our job to worry about stuff like that.

JIT编译器会实际进行这样的优化吗？ 实际上，几乎没有人知道该问题的真正答案。 我不会，而且我确定普通的Java开发人员也不会。 担心像这样的事情并不是我们真正的工作。

Java developers absolutely do have to think about efficiency; using the wrong algorithm or data structure for a situation is never a good idea. There's a point, though, where the search for optimization dives too deeply into territory that might just be reorganized by the JIT compiler anyway. So what's a better idea than examining bytecode?

Java开发人员绝对

1. Identify whether your application has a performance issue.
   确定您的应用程序是否存在性能问题。
2. Profile your application to find the part of your code that performs poorly.
   对应用程序进行概要分析，以查找代码中性能不佳的部分。
3. Optimize that section of your code and repeat.
   优化代码的这一部分并重复。

Sounds simple enough, right?

听起来很简单，对吧？

翻译自: https://www.experts-exchange.com/articles/16919/Why-trying-to-improve-efficiency-by-reading-Java-bytecode-might-not-be-the-best-idea.html

java 读取图片字节码