看了这篇【JIT编译器】，你也能说你会java性能优化了！

你们好，我是小菜，一个渴望在互联网行业作到蔡不菜的小菜。可柔可刚，点赞则柔，白嫖则刚！
死鬼~看完记得给我来个三连哦！

本文主要介绍 java性能分析 之 JIT编译器
若有须要，能够参考
若有帮助，不忘 点赞 ❥

创做不易，白嫖无义！

参考书籍：《Java性能权威指南》

做为Java开发人员，也许在工做中最常常用到的只是 CRUD，解决性能问题 也许不常常接触到，可是也是须要了解一二的！这篇文章小菜带你一块儿探究 Java性能优化之JIT编译器。

文章大纲

前情概览

即时 JIT（JUst-In-Time）编译器是Java虚拟机的核心，对 JVM性能 影响最大的也就是编译器。

CPU 是计算机的核心，到时只能执行相对少并且特定的指令，例如汇编码和二进制码 ，所以 CPU 所执行的程序都必须翻译成这种指令。

语言结构

• 编译型语言：会编译成二进制形式 交付，先写程序，而后用编译器静态生成二进制文件。
• 解释型语言：只要机器上有合适的解释器，相同的程序代码能够在任何 CPU 上执行，执行程序时，解释器会将相应代码转换为二进制代码。

Java试图走一条中间路线，Java应用会被编译——但不是编译成特定 CPU 所专用的二进制编码，而是被编译成一种理想化的汇编语言。而后该汇编语言（Java字节码）能够用Java运行。所以 Java 是一门 平台独立性的解释型语言。

热点编译

JVM 执行代码时，只会编译常常被调用的。所以被编译的代码须要具有如下特性：

• 代码是常常被调用的代码
• 运行不少次迭代的循环

而这些关键代码段被称为应用的热点，代码执行得越多就被认为是越热的。所以编译器会先解释执行代码，而后找出哪一个方法被调用的足够频繁，才进行编译。这也是为了优化：JVM 执行特定方法或者循环的次数越多，它就会越了解这段代码，这样可使 JVM 在编译代码时进行大量优化。

小结

• Java的设计结合了脚本语言的平台独立性和编译型语言的本地性能
• Java文件被编译成中间语言（Java字节码），而后在运行时被JVM进一步编译成汇编语言
• 字节码编译成汇编语言的过程当中有大量的优化，极大地改善了性能

调优入门

1、两种 “口味”

• Client 编译器
• Server编译器

命令行上选择编译器类型则采用以上两个名字：-client和-server。一般这两个编译器也称为 c1 编译器（client编译器） 和 c2 编译器（server编译器）

分层编译器：分层编译意味着必须使用 server 编译器

关闭分层编译： java -client -XX:+TieredCompilation other_args

二者的主要区别：

在于编译代码的时机不一样。client编译器开启编译比server编译器要早。这意味着；在代码执行的开始阶段，client编译器比server编译器要快，由于他编译代码相比server编译器而言要多。

问题来了：

JVM 能不能在启动的时候用 client 编译器，而后随着代码变热使用 server 编译器？

方案：

分层编译：代码先由 client 编译器编译，随着代码变热， 由 server 编译器从新编译。在 Java 1.8 中，分层编译是默认开启的。

2、优化启动

当快速启动时间是首要目标时了，最常使用 client 编译器。

当总体性能比启动性能更重要时，更适合使用 server 编译器。

小结:

1. 若是应用的启动时间是首要的性能考量，那 client 编译器就是最有用的。
2. 分层编译的启动时间能够很是接近于 client 编译器所得到的启动时间。

3、优化批处理

处理过程

归根结底取决于哪一种编译器使得应用运行的时间最优。

• 分层编译是批处理任务合理的默认选择
• 分层编译是适合全部状况的很好的备选方案
• 分层编译老是比标准的 server 编译器好一些
• 即使应用永远运行，server 编译器也不可能编译它的全部代码
• 对于计算量固定的任务来讲，应该选择实际执行任务最快的编译器

4、优化长时间运行的应用

一般来讲，在应用 “热身” 以后，意味着它已经运行了足够长的时间，重要的代码都已经被编译，这个时候即可以测试它处理的吞吐量。一个应用测试结果：

热身期 (秒)	- client	- server	-XX:+TieredCompilation
0	15.87	23.72	24.23
60	16.00	23.73	24.26
300	16.85	24.42	24.43

相比单独的 server 编译器，分层编译能够编译更多代码，提供更多的性能。

对于长时间运行的应用来讲，应该一直使用 server 编译器，最好配合分层编译。

编译器中级调优

大多数状况下，所谓编译器调优，其实就只是为目标机器上的 Java 选择正确的 JVM和编译器开关（-client -server -XX:+TieredCompilation）而已。分层编译一般是长期运行应用的最佳选择，而对于运行时间短的应用来讲，分层编译与 client 编译器的性能差异也微乎其微。

1、代码缓存

JVM 编译代码时，会在代码缓存中保留编译以后的汇编语言指令集。代码缓存的大小固定，因此一旦填满，JVM 就不能编译更多代码了。代码缓存太小会致使只有部分热点编译，而应用的大部分代码都只是解释运行 —> 运行慢

代码缓存填满时，JVM会发出如下警告：

JAVA HotSpot(TM) 64-Bit Server VM warning:CodeCache is full
        Compiler has been disabled
JAVA HotSpot(TM) 64-Bit Server VM warning:Try increasing the
        code cache size using -XX:ReservedCodeCacheSize=
复制代码

JVM 类型	代码缓存的默认大小
32 位 client，Java 8	32 MB
32 位 server，分层编译，Java 8	240 MB
64 位 server，分层编译，Java 8	240 MB
32 位 client，Java 7	32 MB
32 位 server，Java 7	32 MB
64 位 server，Java 7	48 MB
64 位 server，分层编译，Java 7	96 MB

设置代码缓存最大值

-XX:ReservedCodeCacheSize=N

设置代码缓存初始大小

-XX:InitialCodeCacheSize=N

小结

1. 代码缓存是一种有最大值的资源，它会影响 JVM 可运行的编译代码总量。

2. 分层编译很容易达到代码缓存默认配置的上限（特别是在 Java 7）。使用分层编译时，应该监控代码缓存，必要时应该增长它的大小。

2、编译阈值

编译阈值和 代码执行的频度 有关，一旦代码执行达到必定次数，而且达到了编译阈值，编译器就能够得到足够多的信息来进行代码的编译。

编译是基于两种 JVM 计数器

• 方法调用计数器
• 方法中的循环回边计数器（回边能够看作是循环完成执行的次数，所谓循环完成执行，包括达到循环自身的末尾，也包括执行了像 continue 这样的分支语句）

---

1. 标准编译

JVM 执行了某个 Java 方法时，会检查该方法的两种计数器总数，而后断定该方法是否适合编译，若是适合，该方法就会进入编译队列。

更改编译阈值

由-XX:CompileThreshold=N标志触发，使用 client 编译器时，N 的默认值是 1500,使用 server 编译器时，N 的默认值是 10 000，更改 CompileThreshold 将会使编译器提升（或延迟）编译。

问题：

若是循环很长或者永远不会退出，怎么计数？

这种状况下，JVM 不等方法调用完成就会编译循环，因此循环每完成一轮，回边计数器就会增长并被检测。

2. 栈上编译 (OSR)

因为仅仅编译循环还不够，JVM 必须在循环进行的时候还能编译循环，在循环代码编译结束后，JVM 就会替换还在栈上的代码，循环的下一次迭代就会执行快得多的编译代码。

---

实际上会出现有些重要的方法永远不会被编译。由于并非还没达到编译阈值，而是永远都达不到编译阈值！

这是由于虽然计数器随着方法和循环的执行而增长，可是它们也会随时间而减小。这种方法也称为 温热方法

小结：

1. 当方法和循环执行次数达到某个阈值的时候，就会发生编译
2. 改变阈值会致使代码提前或推后编译
3. 因为计数器会随着时间而减小，以致于 "温热方法" 可能永远都打不到编译的阈值（特别是对 server 编译器来讲）

3、编译过程

若是咱们想要看到编译器是如何工做的，可使用 -XX:+PrintCompilation 命令来开启，默认是 false

若是程序启动时没有开启这个标志，能够用 jstat 了解编译器内部的部分工做状况。例如：jstat -compiler 25 或 jstat -printcompilation 25 1000

• -compiler：提供了关于多少方法被编译的概要信息
• -printcompilation：获取最近被编译的方法
• 25：是被检测进程的 ID
• 1000：每 1 秒（1000毫秒）输出一次

小结：

1. 观察代码如何被编译的最好方法是开启 PrintCompilation
2. PrintCompilation 开启后所输出的信息可用来确认编译是否和预期同样

编译器高级调优

1、编译线程

当方法（或循环）适合编译时，就会进入到编译队列。而后队列中的任务则由一个或多个后台线程处理，这意味着编译过程是异步的。这样的好处即是：即使代码正在编译的时候，程序也能持续执行。

若是是用标准编译所编译的方法，那下次调用该方法时就会执行编译后的方法；若是是用OSR编译的循环，那下次循环迭代时就会执行编译后的代码。

编译队列并不严格遵照先进先出的原则：调用计数次数多的方法有更高的优先级。因此即使在程序开始执行并有大量代码须要编译时，这样的优先顺序仍然有助于确保最重要的代码优先编译。

使用client编译器时，JVM会开启一个编译线程；使用server编译器时，则会开启两个线程。而分层编译器则是一个略复杂的等式而定，以下：

CPU数量	C1的线程数	C2的线程数
1	1	1
2	1	1
4	1	1
8	1	2
16	2	6
32	3	7
64	4	8
128	4	10

小结：

1. 放置在编译队列中的方法的编译会被异步执行。
2. 队列并非严格按照前后顺序的；队列中的热点方法会在其余方法以前编译，这是编译输出日志中的 ID 为乱序的另外一个缘由。

2、内联 可好？

有了解过final的小伙伴应该都知道被final修饰的方法，编译时JVM会尝试找与其内联的方法。这是由于编译器所作的最重要的优化是方法内联。内联默认是开启的。能够经过-XX:-Inline关闭。

若是你从源代码编译 JVM，那能够用 -XX:+PrintInling生成带调试信息的版本。方法是否 内联 取决于它有多热以及它的大小。JVM 依据内部计算来断定方法是否热点（譬如：调用很频繁）；是不是热点并不直接与任何调优参数相关。

小结：

1. 内联是编译器所能作的最有利的优化，特别是对属性封装良好的面向对象的代码来讲。
2. 几乎用不着调节内联参数，且提倡这样作的建议每每忽略了常规内联和频繁调用内联之间的关系。当考察内联效应时，确保考虑这两种状况。

3、逃逸分析

咱们能够经过-XX:+DoEscapeAnalysis来开启逃逸分析，默认是true。逃逸分析能够决定哪些优化是可能的，并决定编译后的代码中哪些是必要的改变。

逃逸分析默认开启，极少数状况下，它会出错。在此类状况下关闭它会变得更快或更稳定。若是你发现了这种状况，最好的应对行为就是简化相关代码：代码越简单越好。

小结：

1. 逃逸分析是编译器能作得最复杂的优化，此类优化经常会致使微基准测试失败。
2. 逃逸分析经常会给不正确的同步代码引入 bug。

何为逆优化

逆优化意味着编译器不得不 “撤销” 以前的某些编译；结果是应用的性能下降——至少是直到编译器从新编译相应代码为止。有两种逆优化的情形：

• 代码被丢弃（made not entrant）
• 产生僵尸代码（made zombie）

1、代码被丢弃了？

有两种缘由致使代码被丢弃

• 与类与接口的工做方式有关
• 与分层编译的细节有关

当server编译器编译好代码以后，JVM 必须替换 client 编译器所编译的代码。它会将老弟阿玛标记为废弃。也用一样的方法替换新编译（和更有效）的代码。

2、“僵尸” 代码出现

何为僵尸代码：当编译后的代码，由于后续没有用到而被GC回收，所有回收以后，编译器就会注意到，这些代码如今适合标记为僵尸代码了。

从性能角度上看，这是好事。上面咱们提到过代码缓存，编译后的代码会保存在大小固定的代码缓存中。若是发现僵尸代码，这意味着这些有问题的代码能够从代码缓存中移除，腾出空间给其余将被编译的代码（或者限制 JVM 以后须要分配的内存量）。

可能产生不足的是，若是代码被僵尸化之后再次加载而且频繁使用，JVM 就须要从新编译和从新优化代码，那么这将会影响到性能。

---

小结：

1. 逆优化使得编译器能够回到以前版本的编译代码
2. 先前的优化再也不有效时（例如，所涉及到的对象类型发生了更改），才会发生代码逆优化。
3. 代码逆优化时，会对性能产生一些小而短暂的影响，不过新编译的代码会尽快地再次热身。
4. 分层编译时，若是代码以前由 client 编译器编译而如今 server 编译器优化，就会发生逆优化。

分层编译级别

程序使用分层编译时，编译日志会输出所编译的分层级别。

其中 client 编译器有 3 种级别，server 编译器有 2 种编译级别，所以，编译级别有如下几种：

• 0：解释代码
• 1：简单 C1 编译代码
• 2：受限的 C1 编译代码
• 3：彻底 C1 编译代码
• 4：C2 编译代码

多数方法第一次编译的级别是3 ，即彻底 C1 编译（不过全部方法都从级别0开始）。若是方法运行得足够频繁，它就会编译成级别4（级别3的代码就会被丢弃）。

若是 server 编译器队列满了，就会从 server 队列中取出方法， 以级别2进行编译，在这个级别中，C1编译器使用方法调用计数器和回边计数器。这会让方法编译得更快，而方法也将在 C1 编译器收集分析信息以后被编译为级别3，最终当 server 编译器队列不太忙的时候被编译为级别4。

小结：

1. 分层编译能够在两种编译器和 5 种级别之间进行。
2. 不建议人为更改级别。

小菜与你小结

1. 不用担忧小方法，特别是getter和setter，由于它们很容易内联。
2. 须要编译的代码在编译队列中，队列中的代码越多，程序达到最佳性能的时间越久。
3. 虽然代码缓存的大小能够（也应该）调整，但它仍然是有限的资源。
4. 代码越简单，优化越多，分析反馈和逃逸分析可使代码更快，但复杂的循环结构和大方法限制了它的有效性。

看完不赞，都是坏蛋

本文较长，能看到这里的都是最棒的！成长之路学无止境~
今天的你多努力一点，明天的你就能少说一句求人的话！
好久好久以前，有个传说，听说：
看完不赞，都是坏蛋