第十章 内存问题诊断：从OOM到性能瓶颈
1. JVM优化之JIT优化
1.1 堆，是分配对象的唯一选择吗
在《深入理解Java虚拟机中》关于Java堆内存有这样一段描述：
随着JIT编译期的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化，所有的对象都分配到堆上也渐渐变得不那么"绝对"了。
在Java虚拟机中，对象是在Java堆中分配内存的，这是一个普遍的常识。但是，有一种特殊情况，那就是如果经过逃逸分析(Escape Analysis)后发现，一个对象并没有逃逸出方法的话，那么就可能被优化成栈上分配。这样就无需在堆上分配内存，也无须进行垃圾回收了。这也是最常见的堆外存储技术。
flowchart TD
A[对象创建] --> B{逃逸分析}
B -->|未逃逸| C[栈上分配]
B -->|发生逃逸| D[堆上分配]
C --> E[方法结束自动回收]
D --> F[等待GC回收]
classDef optimization fill:#90EE90,stroke:#006400,stroke-width:2px
classDef normal fill:#FFB6C1,stroke:#DC143C,stroke-width:2px
class C,E optimization
class D,F normal
1.2 编译的开销
1.2.1 时间开销
编译的时间开销：
解释器的执行，抽象的看是这样的: 输入的代码 -> [ 解释器 解释执行 ] -> 执行结果
JIT编译然后再执行的话，抽象的看则是: 输入的代码 -> [ 编译器 编译 ] -> 编译后的代码 -> [ 执行 ] -> 执行结果
sequenceDiagram
participant Code as 源代码
participant Interpreter as 解释器
participant JIT as JIT编译器
participant Execution as 执行引擎
Note over Code,Execution: 解释执行模式
Code->>Interpreter: 字节码
Interpreter->>Execution: 直接解释执行
Note over Code,Execution: JIT编译模式
Code->>JIT: 热点代码
JIT->>JIT: 编译优化
JIT->>Execution: 机器码执行
Note right of JIT: 编译开销 vs 执行收益
注意： 说JIT比解释快，其实说的是"执行编译后的代码"比"解释器解释执行"要快，并不是说"编译"这个动作比"解释"这个动作快。JIT编译再怎么快，至少也比解释执行一次略慢一些，而要得到最后的执行结果还得再经过一个"执行编译后的代码"的过程。所以，对"只执行一次"的代码而言，解释执行其实总是比JIT编译执行要快。
只有对频繁执行的代码（热点代码），JIT编译才能保证有正面的收益。
1.2.2 空间开销
对一般的Java方法而言，编译后代码的大小相对于字节码的大小，膨胀比达到10+是很正常的。同上面说的时间开销一样，这里的空间开销也是，只有对执行频繁的代码才值得编译，如果把所有代码都编译则会显著增加代码所占空间，导致代码爆炸。
1.3 即时编译对代码的优化
1.3.1 逃逸分析
- 如何将堆上的对象分配到栈，需要使用逃逸分析手段。
- 逃逸分析(Escape Analysis)是目前Java虚拟机中比较前沿的优化技术。这是一种可以有效减少Java 程序中同步负载和内存堆分配压力的跨函数全局数据流分析算法。
- 通过逃逸分析，Java Hotspot编译器能够分析出一个新的对象的引用的使用范围，从而决定是否要将这个对象分配到堆上。
flowchart TB
subgraph "逃逸分析场景"
A[对象创建] --> B{作用域分析}
B -->|方法内部使用| C[未逃逸]
B -->|外部方法引用| D[方法返回值逃逸]
B -->|赋值给类变量| E[全局变量逃逸]
B -->|多线程访问| F[线程逃逸]
C --> G[栈上分配候选]
D --> H[堆上分配]
E --> H
F --> H
end
classDef noEscape fill:#90EE90,stroke:#006400,stroke-width:2px
classDef escape fill:#FFB6C1,stroke:#DC143C,stroke-width:2px
class C,G noEscape
class D,E,F,H escape
逃逸分析的基本行为就是分析对象动态作用域：
- 当一个对象在方法中被定义后，对象只在方法内部使用，则认为没有发生逃逸。
- 当一个对象在方法中被定义后，它被外部方法所引用，则认为发生逃逸。例如作为调用参数传递到其他地方中。
public void my_method() {
V v = new V();
//use v
//......
v = null;
}
没有发生逃逸的对象，则可以分配到栈上，随着方法执行的结束，栈空间就被移除。
参数设置
- 在JDK 6u23版本之后，HotSpot中默认就已经开启了逃逸分析。
- 如果使用的是较早的版本，开发人员则可以通过：
- 通过选项"-XX:+DoEscapeAnalysis"显式开启逃逸分析
- 通过选项"-XX：+PrintEscapeAnalysis"查看逃逸分析的筛选结果。
1.3.2 代码优化一：栈上分配
使用逃逸分析，编译器可以对代码做如下优化：
栈上分配。将堆分配转化为栈分配。如果经过逃逸分析后发现，一个对象并没有逃逸出方法的话，那么就可能被优化成栈上分配。这样就无需在堆上分配内存，也无须进行垃圾回收了。可以减少垃圾回收时间和次数。
JIT编译器在编译期间根据逃逸分析的结果，发现如果一个对象并没有逃逸出方法的话，就可能被优化成栈上分配。分配完成后，继续在调用栈内执行，最后线程结束，栈空间被回收，局部变量对象也被回收。这样就无须进行垃圾回收了。
1.3.3 代码优化二：同步省略(消除)
同步省略。如果一个对象被发现只能从一个线程被访问到，那么对于这个对象的操作可以不考虑同步。
线程同步的代价是相当高的，同步的后果是降低并发性和性能。
在动态编译同步块的时候，JIT编译器可以借助逃逸分析来判断同步块所使用的锁对象是否只能够被一个线程访问而没有被发布到其他线程。如果没有，那么JIT编译器在编译这个同步块的时候就会取消对这部分代码的同步。这样就能大大提高并发性和性能。这个取消同步的过程就叫同步省略，也叫锁消除。
flowchart LR
A[同步代码块] --> B{逃逸分析}
B -->|锁对象未逃逸| C[锁消除优化]
B -->|锁对象逃逸| D[保留同步]
C --> E["synchronized(obj) {<br/> // code<br/>}"]
E --> F["// code<br/>(无同步开销)"]
D --> G[保持原有同步机制]
classDef optimization fill:#90EE90,stroke:#006400,stroke-width:2px
classDef normal fill:#FFB6C1,stroke:#DC143C,stroke-width:2px
class C,E,F optimization
class D,G normal
代码举例
如以下代码：
public void f() {
Object hollis = new Object();
synchronized(hollis) {
System.out.println(hollis);
}
}
代码中对hollis这个对象进行加锁，但是hollis对象的生命周期只在f()方法中，并不会被其他线程所访问到，所以在JIT编译阶段就会被优化掉。优化成：
public void f() {
Object hollis = new Object();
System.out.println(hollis);
}
1.3.4 代码优化三：标量替换
**标量（Scalar）**是指一个无法再分解成更小的数据的数据。Java中的原始数据类型就是标量。
相对的，那些还可以分解的数据叫做聚合量（Aggregate），Java中的对象就是聚合量，因为他可以分解成其他聚合量和标量。
在JIT阶段，如果经过逃逸分析，发现一个对象不会被外界访问的话，那么经过JIT优化，就会把这个对象拆解成若干个其中包含的若干个成员变量来代替。这个过程就是标量替换。
flowchart TB
subgraph "标量替换示例"
A["Point point = new Point(1,2)"] --> B{逃逸分析}
B -->|未逃逸| C[标量替换]
C --> D["int x = 1"]
C --> E["int y = 2"]
F["point.x + point.y"] --> G["x + y"]
end
subgraph "优化效果"
H[减少堆内存占用]
I[避免对象创建开销]
J[提高缓存命中率]
end
C --> H
C --> I
C --> J
classDef optimization fill:#90EE90,stroke:#006400,stroke-width:2px
classDef benefit fill:#FFFFE0,stroke:#DAA520,stroke-width:2px
class C,D,E,G optimization
class H,I,J benefit
代码列举
public static void main(String[] args) {
alloc();
}
private static void alloc() {
Point point = new Point（1,2）;
System.out.println("point.x="+point.x+"; point.y="+point.y);
}
class Point{
private int x;
private int y;
}
以上代码，经过标量替换后，就会变成：
private static void alloc() {
int x = 1;
int y = 2;
System.out.println("point.x="+x+"; point.y="+y);
}
可以看到，Point这个聚合量经过逃逸分析后，发现他并没有逃逸，就被替换成两个标量了。那么标量替换有什么好处呢？就是可以大大减少堆内存的占用。因为一旦不需要创建对象了，那么就不再需要分配堆内存了。
标量替换为栈上分配提供了很好的基础。
参数设置
标量替换参数设置：
参数-XX:+EliminateAllocations：开启了标量替换(默认打开)，允许将对象打散分配在栈上。
1.4 逃逸分析小结
逃逸分析小结：逃逸分析并不成熟
- 关于逃逸分析的论文在1999年就已经发表了，但直到JDK 1.6才有实现，而且这项技术到如今也并不是十分成熟的。
- 其根本原因就是无法保证非逃逸分析的性能消耗一定能高于他的消耗。虽然经过逃逸分析可以做标量替换、栈上分配、和锁消除。但是逃逸分析自身也是需要进行一系列复杂的分析的，这其实也是一个相对耗时的过程。
- 一个极端的例子，就是经过逃逸分析之后，发现没有一个对象是不逃逸的。那这个逃逸分析的过程就白白浪费掉了。
- 虽然这项技术并不十分成熟，但是它也是即时编译器优化技术中一个十分重要的手段。
flowchart LR
subgraph "逃逸分析权衡"
A[逃逸分析开销] --> B{收益评估}
C[优化收益] --> B
B -->|收益 > 开销| D[启用优化]
B -->|收益 ≤ 开销| E[保持原状]
D --> F[栈上分配]
D --> G[锁消除]
D --> H[标量替换]
end
classDef cost fill:#FFB6C1,stroke:#DC143C,stroke-width:2px
classDef benefit fill:#90EE90,stroke:#006400,stroke-width:2px
classDef optimization fill:#FFFFE0,stroke:#DAA520,stroke-width:2px
class A,E cost
class C,D benefit
class F,G,H optimization
2. 性能优化之合理配置堆内存
2.1 推荐配置
在案例1中我们讲到了增加内存可以提高系统的性能而且效果显著，那么随之带来的一个问题就是，我们增加多少内存比较合适？如果内存过大，那么如果产生FullGC的时候，GC时间会相对比较长，如果内存较小，那么就会频繁的触发GC，在这种情况下，我们该如何合理的适配堆内存大小呢？
分析： 依据的原则是根据Java Performance里面的推荐公式来进行设置。
classDiagram
class 内存区域 {
<<enumeration>>
Java堆
永久代
年轻代
老年代
}
class 配置参数 {
-Xms
-Xmx
-XX:PermSize
-XX:MaxPermSize
-Xmn
}
class 占用因子 {
Java堆: 3-4倍FGC后老年代占用
永久代: 1.2-1.5倍FGC后永久代占用
年轻代: 1-1.5倍FGC后老年代占用
老年代: 2-3倍FGC后老年代占用
}
内存区域 --> 配置参数 : 对应
内存区域 --> 占用因子 : 建议比例
Java整个堆大小设置，Xmx 和 Xms设置为老年代存活对象的3-4倍，即FullGC之后的老年代内存占用的3-4倍。
方法区（永久代 PermSize和MaxPermSize 或 元空间 MetaspaceSize 和MaxMetaspaceSize）设置为老年代存活对象的1.2-1.5倍。
年轻代Xmn的设置为老年代存活对象的1-1.5倍。
老年代的内存大小设置为老年代存活对象的2-3倍。
但是，上面的说法也不是绝对的，也就是说这给的是一个参考值，根据多种调优之后得出的一个结论，大家可以根据这个值来设置一下我们的初始化内存，在保证程序正常运行的情况下，我们还要去查看GC的回收率，GC停顿耗时，内存里的实际数据来判断，Full GC是基本上不能有的，如果有就要做内存Dump分析，然后再去做一个合理的内存分配。
我们还要注意到一点就是，上面说的老年代存活对象怎么去判定。
2.2 如何计算老年代存活对象
2.2.1 方式1：查看日志
推荐/比较稳妥！
JVM参数中添加GC日志，GC日志中会记录每次FullGC之后各代的内存大小，观察老年代GC之后的空间大小。可观察一段时间内（比如2天）的FullGC之后的内存情况，根据多次的FullGC之后的老年代的空间大小数据来预估FullGC之后老年代的存活对象大小**（可根据多次FullGC之后的内存大小取平均值）**。
sequenceDiagram
participant App as 应用程序
participant GC as 垃圾收集器
participant Log as GC日志
participant Admin as 管理员
App->>GC: 触发FullGC
GC->>GC: 清理老年代
GC->>Log: 记录GC后内存大小
Note over Log: 观察2天内多次FullGC
Admin->>Log: 分析日志
Log-->>Admin: 老年代存活对象大小
Admin->>Admin: 计算平均值
Admin->>Admin: 制定内存配置策略
2.2.2 方式2：强制触发FullGC
会影响线上服务，慎用！
方式1的方式比较可行，但需要更改JVM参数，并分析日志。同时，在使用CMS回收器的时候，有可能不能触发FullGC，所以日志中并没有记录FullGC的日志。在分析的时候就比较难处理。所以，有时候需要强制触发一次FullGC，来观察FullGC之后的老年代存活对象大小。
注：强制触发FullGC，会造成线上服务停顿（STW），要谨慎！建议的操作方式为，在强制FullGC前先把服务节点摘除，FullGC之后再将服务挂回可用节点，对外提供服务，在不同时间段触发FullGC，根据多次FullGC之后的老年代内存情况来预估FullGC之后的老年代存活对象大小
如何强制触发Full GC?
1、jmap -dump:live,format=b,file=heap.bin 将当前的存活对象dump到文件，此时会触发FullGC
2、jmap -histo:live 打印每个class的实例数目,内存占用,类全名信息.live子参数加上后,只统计活的对象数量. 此时会触发FullGC
3、在性能测试环境，可以通过Java监控工具来触发FullGC，比如使用VisualVM和JConsole，VisualVM集成了JConsole，VisualVM或者JConsole上面有一个触发GC的按钮。
flowchart TD
A[强制触发FullGC] --> B{环境选择}
B -->|生产环境| C[摘除服务节点]
B -->|测试环境| D[直接执行]
C --> E[执行FullGC命令]
D --> E
E --> F["jmap -dump:live"]
E --> G["jmap -histo:live"]
E --> H["VisualVM/JConsole"]
F --> I[观察老年代大小]
G --> I
H --> I
I --> J[计算存活对象大小]
J --> K[制定内存配置]
C --> L[恢复服务节点]
classDef danger fill:#FFB6C1,stroke:#DC143C,stroke-width:2px
classDef safe fill:#90EE90,stroke:#006400,stroke-width:2px
classDef tool fill:#FFFFE0,stroke:#DAA520,stroke-width:2px
class A,C,E danger
class D,L safe
class F,G,H tool
2.3 结论
在内存相对紧张的情况下，可以按照上述的方式来进行内存的调优， 找到一个在GC频率和GC耗时上都可接受的一个内存设置，可以用较小的内存满足当前的服务需要。
但当内存相对宽裕的时候，可以相对给服务多增加一点内存，可以减少GC的频率，GC的耗时相应会增加一些。 一般要求低延时的可以考虑多设置一点内存， 对延时要求不高的，可以按照上述方式设置较小内存。
如果在垃圾回收日志中观察到OutOfMemoryError,尝试把Java堆的大小扩大到物理内存的80%~90%。尤其需要注意的是堆空间导致的OutOfMemoryError以及一定要增加空间。
- 比如说，增加-Xms和-Xmx的值来解决old代的OutOfMemoryError
- 增加-XX:PermSize和-XX:MaxPermSize来解决permanent代引起的OutOfMemoryError（jdk7之前）；增加-XX:MetaspaceSize和-XX:MaxMetaspaceSize来解决Metaspace引起的OutOfMemoryError（jdk8之后）
记住一点Java堆能够使用的容量受限于硬件以及是否使用64位的JVM。在扩大了Java堆的大小之后，再检查垃圾回收日志，直到没有OutOfMemoryError为止。如果应用运行在稳定状态下没有OutOfMemoryError就可以进入下一步了，计算活动对象的大小。
flowchart LR
subgraph "内存配置策略"
A[内存资源评估] --> B{资源状况}
B -->|内存紧张| C[精确配置]
B -->|内存宽裕| D[适当冗余]
C --> E["最小可用内存<br/>高GC频率"]
D --> F["较大内存<br/>低GC频率"]
E --> G[适合高吞吐量场景]
F --> H[适合低延迟场景]
end
classDef tight fill:#FFB6C1,stroke:#DC143C,stroke-width:2px
classDef loose fill:#90EE90,stroke:#006400,stroke-width:2px
classDef scenario fill:#FFFFE0,stroke:#DAA520,stroke-width:2px
class C,E tight
class D,F loose
class G,H scenario
3. 特殊问题：新生代与老年代的比例
3.1 参数设置
JVM 参数设置为：
# 打印日志详情 打印日志打印日期 初始化内存300M 最大内存300M 日志路径
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xms300M -Xmx300M -Xloggc:log/gc.log
新生代 ( Young ) 与老年代 ( Old ) 的比例为 1:2，所以，内存分配应该是新生代100M，老年代 200M
我们可以先用命令查看一下堆内存分配是怎么样的：
# 查看进程ID
jps -l
# 查看对应的进程ID的堆内存分配
jmap -heap 应的进程ID
结果大家可以看到：我们的SurvivorRatio= 8 但是内存分配却不是8:1:1，这是为什么呢？
3.2 参数AdaptiveSizePolicy
这是因为JDK 1.8 默认使用 UseParallelGC 垃圾回收器，该垃圾回收器默认启动了 AdaptiveSizePolicy，会根据GC的情况自动计算计算 Eden、From 和 To 区的大小；所以这是由于JDK1.8的自适应大小策略导致的，除此之外，我们下面观察GC日志发现有很多类似这样的FULLGC（Ergonomics），也是一样的原因。
flowchart TB
subgraph "AdaptiveSizePolicy机制"
A[JDK 1.8 UseParallelGC] --> B[AdaptiveSizePolicy启用]
B --> C[监控GC性能]
C --> D{性能评估}
D -->|需要调整| E[自动调整内存区域大小]
D -->|性能良好| F[保持当前配置]
E --> G[调整Eden区]
E --> H[调整Survivor区]
E --> I[调整老年代]
G --> C
H --> C
I --> C
F --> C
end
classDef auto fill:#87CEEB,stroke:#4682B4,stroke-width:2px
classDef adjust fill:#FFFFE0,stroke:#DAA520,stroke-width:2px
class B,E auto
class G,H,I adjust
# 开启：
-XX:+UseAdaptiveSizePolicy
# 关闭
-XX:-UseAdaptiveSizePolicy
注意事项： 1、在 JDK 1.8 中，如果使用 CMS，无论 UseAdaptiveSizePolicy 如何设置，都会将 UseAdaptiveSizePolicy 设置为 false；不过不同版本的JDK存在差异；
2、UseAdaptiveSizePolicy不要和SurvivorRatio参数显示设置搭配使用，一起使用会导致参数失效；
3、由于UseAdaptiveSizePolicy会动态调整 Eden、Survivor 的大小，有些情况存在Survivor 被自动调为很小，比如十几MB甚至几MB的可能，这个时候YGC回收掉 Eden区后，还存活的对象进入Survivor 装不下，就会直接晋升到老年代，导致老年代占用空间逐渐增加，从而触发FULL GC，如果一次FULL GC的耗时很长（比如到达几百毫秒），那么在要求高响应的系统就是不可取的。
附：对于面向外部的大流量、低延迟系统，不建议启用此参数，建议关闭该参数。
如果不想动态调整内存大小，以下是解决方案：
1、保持使用 UseParallelGC，显式设置 -XX:SurvivorRatio=8。
2、使用 CMS 垃圾回收器。CMS 默认关闭 AdaptiveSizePolicy。配置参数 -XX:+UseConcMarkSweepGC
补充
关于堆内存的自适应调节有如下三个参数：调整堆是按照每次20%增长，按照每次5%收缩
young区增长量（默认20%）：-XX:YoungGenerationSizeIncrement= old区增长量（默认20%）：-XX:TenuredGenerationSizeIncrement= 收缩量（默认5%）：-XX:AdaptiveSizeDecrementScaleFactor=
flowchart LR
subgraph "自适应调节参数"
A[堆内存自适应] --> B[Young区增长]
A --> C[Old区增长]
A --> D[内存收缩]
B --> E["-XX:YoungGenerationSizeIncrement<br/>默认20%"]
C --> F["-XX:TenuredGenerationSizeIncrement<br/>默认20%"]
D --> G["-XX:AdaptiveSizeDecrementScaleFactor<br/>默认5%"]
end
classDef param fill:#E6E6FA,stroke:#4B0082,stroke-width:2px
class E,F,G param
4. 性能监控工具与实战案例
4.1 jps指令使用
jps（Java Virtual Machine Process Status Tool）是JDK提供的一个显示当前所有Java进程pid的命令。
sequenceDiagram
participant 用户
participant 终端
participant JVM
用户 ->> 终端: 输入 jps
终端 ->> JVM: 请求进程列表
JVM -->> 终端: 返回进程信息
终端 -->> 用户: 显示结果
Note right of 终端: 1456 JstackDeadLockDemo<br/>1774 Jps
4.2 jstack死锁分析
jstack是Java虚拟机自带的一种堆栈跟踪工具，主要用于生成Java虚拟机当前时刻的线程快照。
flowchart TD
subgraph 死锁检测
A[Found one Java-level deadlock] --> B[Thread-1]
A --> C[Thread-0]
end
B --> D["等待锁 0x00000000505cfd0"]
B --> E["持有锁 0x00000000505cfe0"]
C --> F["等待锁 0x00000000505cfe0"]
C --> G["持有锁 0x00000000505cfd0"]
D --> H[被Thread-0持有]
F --> I[被Thread-1持有]
J[callock_Obj2_First] --> B
K[callock_Obj1_First] --> C
classDef deadlock fill:#FFB6C1,stroke:#DC143C,stroke-width:2px
classDef thread fill:#87CEEB,stroke:#4682B4,stroke-width:2px
classDef lock fill:#FFFFE0,stroke:#DAA520,stroke-width:2px
class A deadlock
class B,C thread
class D,E,F,G,H,I lock
4.3 jstat GC状态分析
jstat（Java Virtual Machine Statistics Monitoring Tool）是用于监控虚拟机各种运行状态信息的命令行工具。
gantt
title GC状态对比
dateFormat X
axisFormat %s
section 优化前(5421)
YGC : 0, 1259
FGC : 1259, 6
GCT : 0, 5.556
section 压测后(5421)
YGC : 0, 1600
FGC : 1600, 18
GCT : 0, 7.919
section Tomcat优化后(5902)
YGC : 0, 1134
FGC : 1134, 5
GCT : 0, 5.234
section 优化后压测(5902)
YGC : 0, 1347
FGC : 1347, 16
GCT : 0, 7.149
4.4 Jmeter压测报告分析
通过Jmeter进行压力测试，可以获得系统在高负载下的性能表现。
pie
title 聚合报告分析
"平均值(6ms)" : 6
"90%Line(11ms)" : 11
"95%Line(16ms)" : 16
"99%Line(28ms)" : 28
"最大值(240ms)" : 240
4.5 百万订单系统分析
在大规模分布式系统中，需要合理评估系统容量和内存需求。
flowchart TB
subgraph 订单系统集群
A[订单系统1] -->|100单/秒| D[总订单]
B[订单系统2] -->|100单/秒| D
C[订单系统3] -->|100单/秒| D
end
D --> E[每秒300单]
E --> F[每单1KB对象]
F --> G[每秒300KB订单数据]
G --> H[放大20倍考虑关联服务]
H --> I[每秒6MB对象产生]
classDef system fill:#87CEEB,stroke:#4682B4,stroke-width:2px
classDef calculation fill:#FFFFE0,stroke:#DAA520,stroke-width:2px
classDef result fill:#90EE90,stroke:#006400,stroke-width:2px
class A,B,C system
class E,F,G,H calculation
class I result
4.6 堆内存分配策略
基于系统负载特征，制定合理的堆内存分配策略。
flowchart LR
A[每秒2MB对象] --> B[堆空间4000MB]
B --> C[年轻代1333MB]
C --> D["1333MB / 2MB/s = 666秒"]
D --> E[约10分钟触发MinorGC]
F[对象生命周期] -->|大部分短期| C
F -->|长期存活| G[老年代]
classDef calculation fill:#FFFFE0,stroke:#DAA520,stroke-width:2px
classDef memory fill:#87CEEB,stroke:#4682B4,stroke-width:2px
classDef lifecycle fill:#90EE90,stroke:#006400,stroke-width:2px
class A,D,E calculation
class B,C,G memory
class F lifecycle
5. 总结
本章从JIT优化和堆内存配置两个维度深入分析了JVM性能调优的核心技术：
5.1 JIT优化要点
- 逃逸分析是JIT优化的基础，通过分析对象作用域实现栈上分配
- 标量替换可以将对象拆解为基本类型，减少堆内存占用
- 锁消除通过逃逸分析优化同步代码，提升并发性能
- 逃逸分析虽然强大但有开销，需要权衡收益与成本
5.2 堆内存配置要点
- 内存大小应基于FullGC后老年代存活对象的倍数来设置
- 监控方法包括GC日志分析和强制触发FullGC两种方式
- AdaptiveSizePolicy在高并发低延迟场景下建议关闭
- 配置策略需要根据业务特点在GC频率和延迟间找到平衡
5.3 性能监控实践
- 使用jps、jstack、jstat等工具进行系统监控
- 通过压力测试验证优化效果
- 建立容量规划模型，预估系统资源需求
- 制定合理的内存分配策略，优化GC性能
通过系统性的JVM调优，可以显著提升应用性能，减少GC停顿时间，提高系统吞吐量和响应速度。
