如何优化你的网站性能（一）——GC调优、即时编译JIT

朴灿烈づ我的快乐病毒、 2023-01-16 06:36 231阅读 0赞

优化一个java程序的执行有很多种途径，下面分别从代码、并发、缓存、异步、网络、jvm调优等方面一一描述。

# GC调优 #

先说一下经验，就是要不断的去调，选择一个合适的堆大小，再去应用

**调优的目的**  
GC次数够少  
GC时间够小

**调优原则和步骤**  
1、大多数的java应用程序不需要GC调优  
2、大多数需要GC调优的不是参数问题，是代码问题  
3、GC调优是最后的手段，逼不得已才用

**调优调的是什么？**  
第一：选择合适的GC回收器  
第二：选择合适的堆大小  
第三：选择年轻代在堆中的大小

1、监控GC的状态  
2、分析GC结果，判断是否要优化  
如果minor GC时间<50ms ,且10s一次，说明年轻代是比较合适的

1、打印GC日志 ，启动时jvm添加参数  
\-XX:+PrintGCDetails 打印GC日志、  
\-Xlogger:path 指定日志输出目录  
2、通过查看GC日志

[GC (Allocation Failure) [PSYoungGen: 71530K->5114K(71680K)] 71996K->8976K(159232K), 0.0080597 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
    [GC (Metadata GC Threshold) [PSYoungGen: 61449K->7974K(140288K)] 65310K->11844K(227840K), 0.0056697 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
    [Full GC (Metadata GC Threshold) [PSYoungGen: 7974K->0K(140288K)] [ParOldGen: 3869K->8197K(52736K)] 11844K->8197K(193024K), [Metaspace: 20585K->20584K(1067008K)], 0.0234677 secs] [Times: user=0.14 sys=0.00, real=0.02 secs]

\[PSYoungGen和\[ParOldGen是指GC发生的区域，分别代表使用Parallel Scavenge垃圾收集器的新生代和使用Parallel old垃圾收集器的老生代，为什么是这两个垃圾收集器组合呢？因为我的jvm开启的模式是Server，而Server模式的默认垃圾收集器组合便是这个，在命令行输入java -version就可以看到自己的jvm默认开启模式。还有一种是client模式，默认组合是Serial收集器和Serial Old收集器组合。具体GC信息可以看笔者的另一篇博客。  
https://blog.csdn.net/qq\_41700030/article/details/109367613

在方括号中PSYoungGen:后面的71530K->5114K(71680K)代表的是GC前该内存区域已使用的容量->GC后该内存区域已使用的容量(该内存区域总容量)  
在方括号之外的71996K->8976K(159232K)代表的是GC前Java堆已使用容量->GC后Java堆已使用容量(Java堆总容量)

再往后的0.0080597 secs代表该内存区域GC所占用的时间，单位是秒。

再后面的\[Times: user=0.00 sys=0.00, real=0.01 secs\] ，user代表进程在用户态消耗的CPU时间，sys代表代表进程在内核态消耗的CPU时间、real代表程序从开始到结束所用的时钟时间。这个时间包括其他进程使用的时间片和进程阻塞的时间（比如等待 I/O 完成）  
可以使用一些离线的工具来对GC日志进行分析，比如sun的gchisto

Full GC (Metadata GC Threshold)：full GC发生的原因是元空间满了。可以看到这里\[Metaspace: 20585K->20584K(1067008K)\]尝试回收了元空间大小，此时缺省的大小为21M，所以这里可以把元数据空间大小调大。 -XX:MetaspaceSize=64M

一直开启  
\-XX:+HeapDumpOnOutOfMemoryError  
该配置会把内存快照保存在用户目录或者tomcat目录下，也可以通过 -XX:HeapDumpPath=/tmp/heapdump.hprof 来显示指定路径  
选择开启  
\-xx:printHeapAtGc GC时打印堆信息  
\-xx:TraceClassloading 打印类加载信息 分析类得加载顺序

调优参数：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzAwMDMw_size_16_color_FFFFFF_t_70]  
选择GC回收器：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzAwMDMw_size_16_color_FFFFFF_t_70 1]  
常用配置  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzAwMDMw_size_16_color_FFFFFF_t_70 2]

# JIT #

**能够大幅提升程序运行性能的利器。**

## 编译和解释 ##

可以看下官方解释  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzAwMDMw_size_16_color_FFFFFF_t_70 3]  
Java有个口号是“Write Once,Run Anywhere”，一次编译，处处运行。就体现在这里

java解释器一行一行的运行java字节码还是太慢了，而机器码运行起来最快。JIT编译器把被多次调用的方法和被多次执行的循环体相关的字节码编译成本地机器码并运行，就可以大大提高运行效率。

**JIT：** JIT编译器是JRE的一部分。原本的Java程序都是要经过解释执行的，其执行速度肯定比可执行的二进制字节码程序慢。为了提高执行速度，引入了JIT。在运行时，JIT会把翻译过来的机器码保存起来，以备下次使用。而如果JIT对每条字节码都进行编译，则会负担过重，所以，JIT只会对经常执行的字节码进行编译

## 分层编译 ##

**产生的原因**：由于即时编译器编译本地代码需要占用程序运行时间，要编译出优化程度更高的代码，所花费的时间可能更长；而且要想编译出优化程度更高的代码，解释器可能还要替编译器收集性能监控信息，这对解释执行的速度也有影响。为了在程序启动响应速度与运行效率之间达到最佳平衡，HotSpot 虚拟机启用分层编译的策略

分层编译根据编译器编译、优化的规模与耗时，划分出不同的编译层次：

第 0 层：程序解释执行，解释器不开启性能监控功能，可触发第 1 层编译。

第 1 层：也称为 C1 编译，将字节码编译为本地代码，进行简单，可靠的优化，如有必要将加入性能监控的逻辑。

第 2 层（或 2 层以上）：也称为 C2 编译，也是将字节码编译为本地代码，但是会启用一些编译耗时较长的优化，甚至会根据性能监控信息进行一些不可靠的激进优化。

实施分层编译后，Client Compiler 和 Server Compiler 将会同时工作，许多代码都可能会被多次编译看，用 Client Compiler 获取更高的编译速度，用 Server Compiler 获取更好的编译质量，在解释执行的时候也无须再承担收集性能监控信息的任务。

一些配置参数  
\-xx：TieredComplilation 是否开启分层编译（先开启client编译再用server）（jdk 1.7后才有，默认关闭 1.8默认打开）  
\-xint 禁用Jit  
\-Xmixed 有选择的编译

**编译阈值**：如果某个代码执行次数到达这个值，可以进行JIT编译  
方法调用计术器：  
循环回边计术器：

一段时间没调用，计数器会衰减折半（可调整）  
\-useCounterDecay 启用衰减计数

**编译线程**  
字节码编译成热点代码的时候由单独的线程去做的

**方法内联**  
默认开启，如果关闭，会使性能减少50%  
一个方法是否是内联，取决于是否够热，  
方法编译字节码小于325个字节才会内联 可调整  
方法编译字节码小于35个字节一定会内联 可调整  
（所以这是为什么方法要尽量的小）  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzAwMDMw_size_16_color_FFFFFF_t_70 4]

**逃逸分析**  
默认开启，执行代码出错就会关闭逃逸分析。代码越简单，逃逸分析成功率越高

JVM判断新创建的对象是否逃逸的依据有：一、对象被赋值给堆中对象的字段和类的静态变量。二、对象被传进了不确定的代码中去运行。如果满足了以上情况的任意一种，那这个对象JVM就会判定为逃逸

逃逸分析就是确定一个变量要放堆上还是栈上，规则如下：

是否有在其他地方（非局部）被引用。只要有可能被引用了，那么它一定分配到堆上。否则分配到栈上  
即使没有被外部引用，但对象过大，无法存放在栈区上。依然有可能分配到堆上  
对此你可以理解为，逃逸分析是编译器用于决定变量分配到堆上还是栈上的一种行为  
[关于逃逸分析更详细的文章 点这里][Link 1]

JVM client模式和Server模式启动，分别针对桌面应用和服务器应用做了相应的优化，client版本加载速度较快，server版本加载速度较慢但运行起来较快。。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzAwMDMw_size_16_color_FFFFFF_t_70]: /images/20221022/0c7e6771f0e649809ea166a5ffcd6de7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzAwMDMw_size_16_color_FFFFFF_t_70 1]: /images/20221022/f59a2ca90a3e46ac9705a11bab497de6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzAwMDMw_size_16_color_FFFFFF_t_70 2]: /images/20221022/e5dd9bdc1f59499b8bb750d763d6454c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzAwMDMw_size_16_color_FFFFFF_t_70 3]: /images/20221022/98c484777c2548b1a10453a7a37769aa.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzAwMDMw_size_16_color_FFFFFF_t_70 4]: /images/20221022/24c9ec3cd9cb4f5fa062f7b753bd4ca3.png
[Link 1]: https://www.hollischuang.com/archives/2398