做网站要什么功能,现在做什么行业前景好,建设部注册中心网站,wordpress缓存数据库HotSpot#xff0c;家喻户晓的JVM#xff0c;我们的Java和Scala程序就运行在它上面。年复一年#xff0c;一次又一次的迭代#xff0c;经过无数工程师的不断优化#xff0c;现在它的代码执行的速度和效率已经逼近本地编译的代码了。
它的核心是一个JIT#xff08;Just-I…HotSpot家喻户晓的JVM我们的Java和Scala程序就运行在它上面。年复一年一次又一次的迭代经过无数工程师的不断优化现在它的代码执行的速度和效率已经逼近本地编译的代码了。
它的核心是一个JITJust-In-Time编译器。JIT只有一个目的就是为了提升你代码的执行速度这也是HotSpot能如此流行和成功的重要因素。
JIT编译器都做了什么?
你的代码在执行的时候JVM会收集它运行的相关数据。一旦收集到了足够的数据证明某个方法是热点默认是1万次调用JIT就会介入进来将“运行缓慢的”平台独立的的字节码转化成本地编译的优化瘦身后的版本。
有些优化是显而易见的比如简单方法内联删除无用代码将库函数调用替换成本地方法等。不过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(i0)第一次的时候是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)被去掉了尽管也带来了一些代码重复两处append,不过性能上得到了提升。
边界条件优化
检查空指针是很常见的一个操作。有时候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方法这个判断永远不会失败。
在多次执行这段代码并且一直没有进入到if语句之后JIT编译器会认为这个检查很多可能是多余的。然后它会重新编译这个方法把这个检查去掉最后代码看起来就像是这样的 public static String l33tify(String phrase) {
return phrase.replace(e, 3);
}这能显著的提升性能而且在很多时候这么优化是没有问题的。
那万一这个乐观的假设实际上是错了呢
JVM现在执行的已经是本地代码了空引用可不会引起NullPointerException而是真正的严重的内存访问冲突JVM是个低级生物它会去处理这个段错误然后恢复执行没有优化过的代码——这个编译器可再也不敢认为它是多余的了它会重新编译代码这下空指针的检查又回来了。
虚方法内联
JVM的JIT编译器和其它静态编译器的最大不同就是,JIT编译器有运行时的动态数据它可以基于这些数据进行决策。
方法内联是编译器一个常见的优化编译器将方法调用替换成实际调用的代码以避免一次调用的开销。不过当碰到虚方法调用动态分发的话情况就需要点小技巧了。
先看下这段代码 public class Main {
public static void perform(Song s) {
s.sing();
}
}public interface Song { void sing(); }public class GangnamStyle implements Song {
Override
public void sing() {
System.out.println(Oppan gangnam style!);
}
}public class Baby implements Song {
Override
public void sing() {
System.out.println(And I was like baby, baby, baby, oh);
}
}perform方法可能会被调用了无数次每次都会调用sing方法。方法调用的开销当然是很大的尤其像这种因为它需要根据运行时s的类型来动态选择具体执行的代码。在这里方法内联看真来像是遥不可及的梦想对吧
当然不是了。在多次执行perform方法后编译器会根据它收集的数据发现95%的调用对象都是GangnamStyle实例。这样的话JIT编译器会很乐观将虚方法的调用优化掉。也就是说编译器会直接生成本地代码 对应的Java实现大概是这样的 public static void perform(Song s) {
if (s fastnativeinstanceof GangnamStyle) {
System.out.println(Oppan gangnam style!);
} else {
s.sing();
}
}由于这个优化取决于运行时信息它可以优化掉大部分的sing方法调用尽管这个方法是多态的。
JIT编译器还有很多很有意思的技巧这只是介绍了其中的几点让你能感觉到我们代码在执行的时候JVM在底层都做了些什么优化。
我能帮助JIT做些什么优化吗
JIT编译器是针对一般人的编译器它是用来优化正常写出的代码的它会去分析日常标准写法中的一些模式。不要刻意写代码去帮助JIT编译器进行优化就是对它最好的帮助 ——就正常写你自己的代码就好了。
译注JIT还有许多很多意思的优化这里只是列举出了几点。当然了你也不用太在意它就像文中最后说的正常写好自己的代码就好了。 HotSpot家喻户晓的JVM我们的Java和Scala程序就运行在它上面。年复一年一次又一次的迭代经过无数工程师的不断优化现在它的代码执行的速度和效率已经逼近本地编译的代码了。
它的核心是一个JITJust-In-Time编译器。JIT只有一个目的就是为了提升你代码的执行速度这也是HotSpot能如此流行和成功的重要因素。
JIT编译器都做了什么?
你的代码在执行的时候JVM会收集它运行的相关数据。一旦收集到了足够的数据证明某个方法是热点默认是1万次调用JIT就会介入进来将“运行缓慢的”平台独立的的字节码转化成本地编译的优化瘦身后的版本。
有些优化是显而易见的比如简单方法内联删除无用代码将库函数调用替换成本地方法等。不过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(i0)第一次的时候是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)被去掉了尽管也带来了一些代码重复两处append,不过性能上得到了提升。
边界条件优化
检查空指针是很常见的一个操作。有时候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方法这个判断永远不会失败。
在多次执行这段代码并且一直没有进入到if语句之后JIT编译器会认为这个检查很多可能是多余的。然后它会重新编译这个方法把这个检查去掉最后代码看起来就像是这样的 public static String l33tify(String phrase) {
return phrase.replace(e, 3);
}这能显著的提升性能而且在很多时候这么优化是没有问题的。
那万一这个乐观的假设实际上是错了呢
JVM现在执行的已经是本地代码了空引用可不会引起NullPointerException而是真正的严重的内存访问冲突JVM是个低级生物它会去处理这个段错误然后恢复执行没有优化过的代码——这个编译器可再也不敢认为它是多余的了它会重新编译代码这下空指针的检查又回来了。
虚方法内联
JVM的JIT编译器和其它静态编译器的最大不同就是,JIT编译器有运行时的动态数据它可以基于这些数据进行决策。
方法内联是编译器一个常见的优化编译器将方法调用替换成实际调用的代码以避免一次调用的开销。不过当碰到虚方法调用动态分发的话情况就需要点小技巧了。
先看下这段代码 public class Main {
public static void perform(Song s) {
s.sing();
}
}public interface Song { void sing(); }public class GangnamStyle implements Song {
Override
public void sing() {
System.out.println(Oppan gangnam style!);
}
}public class Baby implements Song {
Override
public void sing() {
System.out.println(And I was like baby, baby, baby, oh);
}
}perform方法可能会被调用了无数次每次都会调用sing方法。方法调用的开销当然是很大的尤其像这种因为它需要根据运行时s的类型来动态选择具体执行的代码。在这里方法内联看真来像是遥不可及的梦想对吧
当然不是了。在多次执行perform方法后编译器会根据它收集的数据发现95%的调用对象都是GangnamStyle实例。这样的话JIT编译器会很乐观将虚方法的调用优化掉。也就是说编译器会直接生成本地代码 对应的Java实现大概是这样的 public static void perform(Song s) {
if (s fastnativeinstanceof GangnamStyle) {
System.out.println(Oppan gangnam style!);
} else {
s.sing();
}
}由于这个优化取决于运行时信息它可以优化掉大部分的sing方法调用尽管这个方法是多态的。
JIT编译器还有很多很有意思的技巧这只是介绍了其中的几点让你能感觉到我们代码在执行的时候JVM在底层都做了些什么优化。
我能帮助JIT做些什么优化吗
JIT编译器是针对一般人的编译器它是用来优化正常写出的代码的它会去分析日常标准写法中的一些模式。不要刻意写代码去帮助JIT编译器进行优化就是对它最好的帮助 ——就正常写你自己的代码就好了。
译注JIT还有许多很多意思的优化这里只是列举出了几点。当然了你也不用太在意它就像文中最后说的正常写好自己的代码就好了。 原创文章转载请注明出处JVM的几点性能优化
英文原文链接
