做服装最好的网站建设,云南省住房和建设执业资格注册中心网站,北京网站建设还公司,的网站开发工具有哪些HotSpot是我们众所周知和喜爱的JVM#xff0c;是Java和Scala汁流淌的大脑。 多年来#xff0c;许多工程师对其进行了改进和调整#xff0c;并且在每次迭代中#xff0c;其代码执行的速度和效率都接近本机编译代码。 JIT#xff08;“即时”#xff09;编译器是其核心。… HotSpot是我们众所周知和喜爱的JVM是Java和Scala汁流淌的大脑。 多年来许多工程师对其进行了改进和调整并且在每次迭代中其代码执行的速度和效率都接近本机编译代码。 JIT“即时”编译器是其核心。 该组件的唯一目的是使您的代码快速运行这是HotSpot如此受欢迎和成功的原因之一。 JIT编译器实际上是做什么的 在执行代码时JVM会收集有关其行为的信息。 一旦收集了有关热方法的足够统计信息默认阈值为10K调用编译器就会启动并将该方法的与平台无关的“慢”字节码转换为自身的优化精简平均编译版本。 一些优化是显而易见的简单的方法内联清除无效代码用本机数学运算替换库调用等。请注意JIT编译器不会就此停止。 这是它执行的一些更有趣的优化 分而治之 您使用以下模式多少次 StringBuilder sb new StringBuilder(Ingredients: );for (int i 0; i ingredients.length; i) {if (i 0) {sb.append(, );}sb.append(ingredients[i]);
}return sb.toString(); 也许这个 boolean nemoFound false;for (int i 0; i fish.length; i) {String curFish fish[i];if (!nemoFound) {if (curFish.equals(Nemo)) {System.out.println(Nemo! There you are!);nemoFound true;continue;}}if (nemoFound) {System.out.println(We already found Nemo!);} else {System.out.println(We still havent found Nemo : ();}
} 这两个循环的共同点是在这两种情况下循环都会做一件事一段时间然后从某个角度开始做另一件事。 编译器可以发现这些模式并将循环分成多个案例或“剥离”几次迭代。 让我们以第一个循环为例。 if (i 0)行在一次迭代中从false开始并且从那一点开始始终计算为true 。 为何每次都要检查状况 编译器将编译该代码就像这样编写 StringBuilder sb new StringBuilder(Ingredients: );if (ingredients.length 0) {sb.append(ingredients[0]);for (int i 1; i ingredients.length; i) {sb.append(, );sb.append(ingredients[i]);}
}return sb.toString(); 这样即使某些代码可能在进程中重复冗余的if (i 0)也将被删除因为速度就是它的全部。 生活在边缘 空检查是一丁点的。 有时null对于我们的引用是有效值例如指示缺少值或错误但有时为了安全起见我们添加了null检查。 其中一些检查可能永远不会失败就此而言null表示失败。 一个经典的示例将包含一个断言如下所示 public static String l33tify(String phrase) {if (phrase null) {throw new IllegalArgumentException(phrase must not be null);}return phrase.replace(e, 3);
} 如果您的代码运行良好并且从未将null作为l33tify的参数l33tify 则断言将永远不会失败。 在多次执行此代码而没有进入if语句的主体之后JIT编译器可能会乐观地认为此检查很有可能是不必要的。 然后它将继续编译该方法将检查全部丢弃就好像是这样写的 public static String l33tify(String phrase) {return phrase.replace(e, 3);
} 这可以显着提高性能这在大多数情况下可能是纯粹的胜利。 但是如果那个幸福道路的假设最终被证明是错误的呢 由于JVM现在正在执行本机已编译的代码因此null引用不会导致模糊的NullPointerException 而是导致实际的苛刻的内存访问冲突。 JVM是它的低级生物它将拦截产生的分段错误进行恢复并进行反优化处理-编译器不能再假设null检查是多余的它重新编译该方法这次使用null检查。 虚拟精神错乱 JVM的JIT编译器与其他静态编译器如C 编译器之间的主要区别之一是JIT编译器具有动态运行时数据决策时可以依靠该数据来运行。 方法内联是一种常见的优化方法在该方法中编译器采用一个完整的方法并将其代码插入另一个程序中以避免调用方法。 在处理虚拟方法调用或动态调度 时这会有些棘手。 以以下代码为例 public class Main {public static void perform(Song s) {s.sing();}
}public interface Song { void sing(); }public class GangnamStyle implements Song {Overridepublic void sing() {System.out.println(Oppan gangnam style!);}
}public class Baby implements Song {Overridepublic void sing() {System.out.println(And I was like baby, baby, baby, oh);}
}// More implementations here 该方法perform可能被执行数百万次每一次方法的调用sing发生。 调用是昂贵的尤其是诸如此类的调用因为调用需要根据s的运行时类型每次动态选择要执行的实际代码。 在这一点上内联似乎是一个遥不可及的梦想不是吗 不必要 执行后 perform几千次编译器可能会决定根据其收集的统计数据该调用的95的目标的一个实例GangnamStyle 。 在这些情况下HotSpot JIT可以执行乐观优化以消除虚拟的sing调用。 换句话说编译器将为这些代码生成本机代码 public static void perform(Song s) {if (s fastnativeinstanceof GangnamStyle) {System.out.println(Oppan gangnam style!);} else {s.sing();}
} 由于此优化依赖于运行时信息因此即使它是多态的它也可以消除大多数sing调用。 JIT编译器还有很多技巧但是这些只是一些技巧可让您了解当我们的代码由JVM执行和优化时的幕后故事。 我是否能帮助 JIT编译器是面向简单人员的编译器 它旨在优化简单的编写并搜索出现在日常标准代码中的模式。 帮助您的编译器的最好方法是不要太努力地帮助它-只需编写代码即可。 参考来自Takipi博客的JCG合作伙伴 Niv Steingarten的JVM性能魔术技巧 。 翻译自: https://www.javacodegeeks.com/2013/06/jvm-performance-magic-tricks.html
