阶段6：Netty与JVM性能调优（上半31-38周）.md · 小小之植物/Java项目

# 第31周 高性能网络通信基石-Netty入门与提高

1. 什么应用场景下选择RPC、HTTP、MQ与Netty？

RPC:系统间即时访问、同步服务调用

HTTP :外部接口API提供、非高并发场景、非大数据报文传输

MQ :微服务之间解耦，流量削峰

Netty:底层基础通信、数据传输、数据同步

# 第32周 高性能网络通信基石-Netty最佳实战

# 第33周 基于Netty打造RPC通信框架-1

# 第34周 基于Netty打造RPC通信框架-2

# 第35周 应用监控与调优-工具篇

1. 性能调优相关

1.1. 借助监控预防问题、发现问题

1.2. 借助工具定位问题

1.3. 定期复盘，防止同类问题再现

1.4. 定好规范，一定程度上规避问题

# 第36周 应用监控与调优-技巧与实战篇

〇、池化技术种类

1. 对象池: 通过复用对象，减少对象创建、垃圾回收的开销

2. 线程池: 通过复用线程来提升性能

3. 连接池: 如数据库连接池/Redis连接池/HTTP连接池，通过复用TCP连接来减少创建和释放连接的时间来提升性能

## 一、对象池

1. 适用场景

维护一些很大、创建很慢的对象，提升性能

2. 对象池框架 Commons-Pool2

2.1. ObjectPool

其中最常用的实现类：GenericObjectPool，一个可配置的通用对象池实现。

核心API：

borrowObject() 从对象池中借对象

returnObject() 将对象归还到对象池

invalidateObject() 失效一个对象

addObject() 增加一个空闲对象，该方法适用于使用空闲对象预加载对象池

clear() 清空空闲的所有对象，并释放相关资源

close() 关闭对象池，并释放相关资源

getNumldle() 获得空闲的对象数量

getNumActive() 获得被借出对象数量

2.2. KeyedObjectPool

最常用的实现类：GenericKeyedObjectPool

2.3. Factory

创建&管理PooledObject，一般要自己扩展（实现工厂接口）

2.4. PooledObject<原对象>

包装原有的对象，从而让对象池管理，一般用DefaultPooledObject

## 二、线程池

特殊的对象池

0. 使用场景

重用已存在的线程，控制并发，定时/定期执行，单线程执行...

1. ThreadPoolExecutor

1.1. 核心参数

corePoolSize: 核心线程数

maximumPoolSize: 最大线程数（核心+非核心线程数）理解：核心线程-正式工，非核心线程-临时工

keepAliveTime: 允许的空闲时间（默认情况下只会终止非核心线程）

TimeUnit: keepAlive Time的时间单位

workQueue: 存储等待执行的任务，传入BlockingQueue接口的实现类，BlockingQueue作用：实现队列应具备的功能，多线程环境下自动管理线程的等待与唤醒；实现类：LinkedBlockingQueue可以是有界或无界队列，SychronousQueue没有存储能力

defaultThreadFactory (默认) : 创建的线程拥有相同优先级、非守护线程、有线程名称

privilegedThreadFactory: 在defaultThreadFactory的基础上，可以让运行在这个线程中的任务拥有和这个线程相同的访问控制和ClassLoader

rejectHandler：拒绝任务的策略

- AbortPolicy (默认) : 抛异常

- CallerRusPolicy :用调用者所在的线程执行任务

- DiscardOldestPolicy :丢弃队列中最靠前的任务

- DiscardPolicy :丢弃当前任务

1.2. 核心API

execute(): 提交任务,交给线程池执行

submit(): 提交任务,能够返回执行结果

shutdown(): 关闭线程池,等待任务都执行完

getTaskCount(): 返回线程池已执行和未执行的任务总数

getCompletedTaskCount(): 已完成的任务数量

getPoolSize(): 线程池当前的线程数量

etActiveCount(): 线程池中正在执行任务的线程数量

1.3. 线程池状态

RUNNING、SHUTDOWN、STOP、TIDYING、TERMINATED

2. ScheduledThreadPoolExecutor

扩展自ThreadPoolExecutor，支持了延时执行、周期性执行任务

2.1. 核心API

schedule(Runnable, long, TimeUnit)

schedule(Callable, long, TimeUnit)

scheduleAtFixedRate

scheduleWithFixedDelay

2.2. 对比Timer

Timer是单线程，阻塞会影响下一个任务的执行；使用Timer时抛异常，会导致尚未执行的其他任务无法执行

实际项目中应该尽可能使用ScheduledThreadPoolExecutor

3. ForkJoinPool（不常用）

把一个大任务拆分成若干个小任务，最终再把每个小任务的结果汇总的框架；比较适合分而治之、递归计算的CPU密集场景；

使用工作窃取算法（自己线程任务执行完了，从其他线程队尾窃取任务执行）

4. Executors 创建线程池的工厂、工具类

核心方法：

- newCachedThreadPool() 返回: ThreadPoolExecutor

1.缓存型线程池，会先查看池中是否有以前建立的线程，有就复用，没有就新建

2.适用于生存周期很短的异步任务

- newFixedThreadPool() 返回: ThreadPoolExecutor

1.固定线程池，任意时间最多只有固定数目的活动线程存在

2.适用于线程数比较稳定的并发线程场景

- newsingleThreadExecutor() 返回: ThreadPoolExecutor

1.任意时间池中只有一个线程，保证任务按照指定顺序执行

2.适用于需要严格控制执行顺序的场景

- newScheduledThreadPool() 返回: SteduledThreadPoolExecutor

1.创建一个有调度能力的线程池，返回ScheduledThreadPoolExecutor

2.适用于定时任务、延时任务

- newWakstealingPool() 返回: ForoinPool

1.创建一个ForkJoinPool

2.适用于分而治之、递归计算的CPU密集场景

### 5. 调优技巧

5.1. 任务类型

CPU密集型任务（排序、数值计算）、IO密集型任务（不占用CPU，操作数据库，增删改查）、混合型任务

5.2. 线程数调优

CPU密集型任务（核心数N+1）、IO密集型任务（核心数2N）、混合型任务 N*U*(1+WT/ST)

N: CPU核心数，U: 目标CPU利用率，WT: 线程等待时间，ST: 线程运行时间

5.3. BlockingQueue调优

BlockingQueue容量 = 线程池计划占用内存 / 单个任务占用内存

5.4. 一些典型场景

通过业务评估，结合压测，逐步调整值，得到最优的corePoolSize、maximumPoolSize、BlockingQueue的容量

- 降低线程切换的消耗：小PoolSize（大小等于cpu核数），大BlockingQueue容量

- 降低线程创建的开销：corePoolSize = maximumPoolSize

- 任务经常发生阻塞（BlockingQueue经常满）：增大maximumPoolSize

## 三、连接池

1. 使用场景

数据库连接池、redis连接池、HTTP连接池，复用连接提升性能

2. 连接池调优

工作过程：获取连接-执行业务-归还连接

连接数 = 核心数N*2 + 可用磁盘数

连接池分离：快任务连接池、慢任务连接池

## 四、异步化

1. 适用场景

耗时操作中，将不影响主流程的操作异步执行，降低响应时间

同步：程序按照定义的顺序执行，每一行都必须等待上一行完成后才能执行

异步：程序执行时,无需等待异步调用的语句返回，即可执行后面的操作

2. 本地调用异步化

2.1. 创建线程

2.2. 线程池

2.3. @Async注解（spring注解）

@Async注解标注的方法必须返回void或Future，建议将@Async标注的方法放到独立的类中去（该注解通过动态代理实现异步），建议自定义BlockingQueue的大小（默认Integer.MAX_VALUE）

2.4. 生产者消费者模式（MQ..）

3. 远程调用异步化

3.1. AsyncRestTempalte 异步版RestTempalte

3.2. WebClient（基于Reactor、Webflux）

3.3. 生产者消费者模式（MQ..）

Feign目前不支持异步化

## 五、锁

使用锁的场景：存在共享数据，且多个线程同时操作共享数据

java中的两大类锁：synchronized（Java内置关键字）、java.util.concurrent包中的xxxLock（e.g. ReentrantLock）

### 1. synchronized

确保线程互斥地访问同步代码

修饰实例方法: 给当前实例加锁,进入同步代码前要获得当前实例的锁

修饰静态方法: 给当前类加锁,进入同步代码前要获得指定类对象的锁

修饰代码块: 给指定对象加锁,进入同步代码前要获得指定对象的锁

2. synchronized 原理

2.1. 对象存储：对象头（Mark Word、类型指针、数组长度）、实例数据、对齐填充；Mark Word中有五种锁标志：无锁、偏向锁、轻量级锁、重量级锁、GC标记（该对象要被回收了）

2.2. 锁分级

三种锁状态，会随着锁的竞争越来越激烈，会逐渐升级

- 偏向锁：

总是会偏向已经拿到锁的线程

优点：加锁和解锁不需要额外的消耗，和执行非同步方法比仅存在纳秒级的差距

缺点：如果线程间存在锁竞争，会带来额外的锁撤销的消耗

适用场景：适用于只有一个线程访问同步块场景

- 轻量级锁：

优点：竞争的线程不会阻塞，提高了程序的响应速度

缺点：如果始终得不到锁竞争的线程使用自旋（一定次数的while循环）会消耗CPU

适用场景：追求响应时间，锁占用时间很短

- 重量级锁：

又叫常规锁（早期java锁的实现），基于对象内部的监视器实现，监视器依赖于操作系统的Mutex Lock (互斥锁)

优点：线程竞争不使用自旋，不会消耗CPU

缺点：线程阻塞，响应时间缓慢

适用场景：追求吞吐量，锁占用时间较长

3. synchronized 优化机制

3.1. 锁消除

jdk通过逃逸分析（分析变量是否可以逃出它的作用域），检测到不存在共享数据和竞争的代码，自动消除锁

3.2. 锁粗化

将多个连续的加锁、解锁操作连接在一起，扩展成一个范围更大的锁（避免不必要的在加锁和解锁之间切换）

### 4. ReentrantLock

4.1. 互斥性

4.2. 可重入性：某个线程已经获得某个锁，可以再次获取锁而不会出现死锁，相应也要解锁数次

4.3. 公平性（synchronized只能创建非公平锁）：ReentrantLock可根据传入的参数fair 创建公平/非公平锁

公平锁（排队获得锁）: 如果另一个线程持有锁或者有其他线程在等待队列中等待这个锁，那么新发出的请求的线程将被放入到队列中

非公平锁（插队获得锁）：当锁被某个线程持有时，新发出请求的线程才会被放入队列。如果在发出请求的时候，锁变成可用状态，这个线程会跳过队列中的等待线程获得锁。

非公平锁的性能大于公平锁，原因：公平锁保证一个阻塞的线程最终能够获得锁，因为是有序的，所以总是可以按照请求的顺序获得锁。不公平锁意味着后请求锁的线程可能在其前面排列的休眠线程恢复前拿到锁，这样就有可能提高并发的性能。这是因为通常情况下挂起的线程重新开始与它真正开始运行，二者之间会产生严重的延时。因此非公平锁就可以利用这段时间完成操作。

4.4. 核心API

lock: 表示获得锁

tryLock(): 表示尝试获得加锁，如果失败返回false

tryLock(timeout, TimeUnit): 带超时的tryLock

lockInterruptibly(): 如果当前线程interrupt了就抛异常，如果没有就去获得锁

unlock(): 解锁，unlock()放finally里防止死锁，unlock与lock成对

4.5. Condition 线程间的协作

替代传统线程通信中（只相当于一个condition）的Object.wait()、notify()方法，而condition可以有多个

await: 对应Object.wait()

signal(): 对应Object.notify()

signalAll(): 对应Object.notifyAl()

注意点：操作Condition的代码，必须在lock的保护之下

4.5. ReentrantLock 原理

双向链表实现队列、大量使用CAS、可重入（重复加锁，锁计数器+1，解锁，锁计数器-1）

5. synchronized vs ReentrantLock

5.1. 相同点：互斥性、可重入性

5.2. 不同点

实现机制：synchronized : JVM实现（c语言编写）；ReentrantLock : JDK实现

性能：synchronized：jdk1.6优化后与 ReentrantLock 差不多

使用：synchronized : 方便简洁，由JVM保证加锁解锁；ReentrantLock : 手动加解锁（unlock方法放finally中防死锁）

功能：ReentrantLock 功能更加强大，可指定公平锁、非公平锁，有丰富的API，提供了Condition

5.3. 选择

synchronized 和 ReentrantLock 都能实现时，建议 synchronized

### 6. ReentrantReadWritelock 读写锁

6.1. ReadLock 读锁，也被称为共享锁

线程允许获取读锁的条件：

没有其他线程的写锁

没有写请求；或者有写请求，但调用线程和持有锁的线程是同一个

6.2. WriteLock 写锁，也被称为排他锁

线程允许获得写锁的条件：

没有其他线程的读锁

没有其他线程的写锁

6.3. ReentrantReadWritelock 特性

公平性（可创建公平/非公平锁）、可重入性、锁降级（写锁变读锁，锁不能升级）

6.4. ReentrantReadWritelock vs ReentrantLock

ReentrantLock : 完全互斥

ReentrantReadWriteLock : 读锁共享，写锁互斥（更适合读多写少的场景）

### 7. StampedLock

解决 ReentrantReadWriteLock 的“写线程饥饿”问题，读多写少，很难拿到写锁，改为公平锁又会降低性能

7.1. 获取 / 释放锁

获取锁的方法，都会返回stamp，如果stamp=0表示操作失败，其他值表示成功

释放锁的方法，需要用stamp作为参数，参数的值必须和获得锁时返回的stamp一致

7.2. 三种访问模式:

Writing模式 : 类似于ReentrantReadWriteLock的写锁

Reading (悲观读模式) : 类似于ReentrantReadWritelock的读锁

在执行悲观读的过程中，不允许有写操作

Optimistic reading（乐观读模式，提升性能） : 类比数据库中的悲观锁和乐观锁

在执行乐观读的过程中，允许有写操作

7.3. 特性

提供了读锁和写锁相互转换的功能、不可重入

7.4. 实例

先获得一个乐观锁（得到一个stamp），再用stamp去验证：获得乐观锁之后，有没有发生过写操作（发生过则stamp会改变），若其他线程执行过写操作，则用悲观锁重读数据，读完数据后，释放悲观锁

### 8. 锁调优

8.1. 减少锁的持有时间（代码执行时间）

8.2. 减少锁的粒度（拆分共享数据）

8.3. 锁粗化（避免不必要的在加锁和解锁之间切换）

8.4. 锁分离

读写分离：使用读写锁、stampedLock

操作分离：不同的操作使用不同的锁

8.5. 无锁（CAS）

非阻塞，避免锁的竞争和线程切换带来的系统开销，但代码较复杂

# 第37周 JVM 性能调优-理论+工具篇

## 一、JVM 内存结构

- 线程共享：

1. 堆（Heap）

此内存区域的唯一目的就是存放对象实例，几乎所有的的对象实例都在这里分配内存（对象的属性，非static的加载在堆空间），在java虚拟机中的描述是：所有的对象实例及数组都要在堆上分配

TLAB Thread Local Allocation Buffer，线程私有分配缓存区

为了加速对象分配，线程专用的内存分配区域，JVM会为每个线程分配一块TLAB区域占用Eden区的空间

TLAB局限性：TLAB空间较小，所以大对象无法在TLAB分配，只能直接分配到线程共享的堆里面

2. 方法区（Method Area）

储存已被虚拟机加载的类信息，常量池（字符串常量池、运行时常量池：字面量、符号引用），静态变量/域（static），即时编译器编译后的代码等数据

- 线程隔离（每个线程有独立的程序计数器和虚拟机栈）：

3. 栈（stack）

通常所说的栈是指虚拟机栈，虚拟机栈由栈帧组成，主要包括：局部变量表（方法中的变量）、方法返回地址，局部变量表存放了编译器可知长度的各种基本数据类型（boolean，byte，char，short，long，float，double），对象引用（reference类型，它不等同与对象本身，而是对象在堆内的首存地址）。方法执行完后，自动释放

本地方法栈：Native方法（c编写）

4. 程序计数器

## 二、对象创建过程、类加载过程、类加载器

1. 对象创建过程

类加载检查

分配内存：尝试栈上分配（通过逃逸分析，确认对象不会被外部访问），尝试TLAB分配，尝试Eden分配，老年代/直接内存分配

初始化零值

设置对象头

执行 init 方法（构造函数？）

2. 类加载过程

使用JVM中的类的加载器和解释器对生成的字节码文件进行解释运行，即将字节码文件对应的类加载到内存中。

.java → .class →

加载：生成class对象（class文件加载到内存） →

连接:（验证：class文件格式、元数据、字节码，准备：为 类变量 分配内存并设置类变量初始值，解析：将常量池内的符号引用替换为直接引用） →

初始化：执行初始化方法（顺序执行所有类变量的显式初始化、静态代码块中语句） →

使用 →

卸载：类的回收（三条件）

3. 类加载器

3.1. BootstrapClassLoader(启动类加载器) ：最顶层的加载类，由 C++实现，负责加载 %JAVA_HOME%/lib目录下的 jar 包和类或者被 -Xbootclasspath参数指定的路径中的所有类。

3.2. ExtensionClassLoader(扩展类加载器) ：主要负责加载 %JRE_HOME%/lib/ext 目录下的 jar 包和类，或被 java.ext.dirs 系统变量所指定的路径下的 jar 包。

3.3. AppClassLoader(应用程序类加载器) ：面向我们用户的加载器，负责加载当前应用 classpath 下的所有 jar 包和类。

3.4. 双亲委派模型

每一个类都有一个对应它的类加载器。

保证了 Java 程序的稳定运行，可以避免类的重复加载（系统会首先判断当前类是否被加载过。已经被加载的类会直接返回，否则才会尝试加载。）

所有的类都由类加载器加载，加载的作用就是将 .class文件加载到内存。

## 三、编译器优化机制（设置 JVM 参数）

1. 代码执行方式

1.1. 解释执行: 由解释器一行一行翻译执行

优势在于没有编译的等待时间

性能相对差一些

1.2. 编译执行: 把字节码编译成机器码，直接执行机器码

运行效率会高很多，一般认为比解释执行快一个数量级

带来了额外的开销

2. 分层编译

2.1. 即时编译器-C1

是一个简单快速的编译器，主要关注局部性的优化，适用于执行时间较短或对启动性能有要求的程序。例如，GUI 应用对界面启动速度就有一定要求。也被称为是 Client Compiler

2.2. 即时编译器-C2

是为长期运行的服务器端应用程序做性能调优的编译器，适用于执行时间较长或对峰值性能有要求的程序，也被称为是 Server Compiler

2.3. 五种编译级别

- 0 : 解释执行

- 1 : 简单C1编译: 会用C1编译器进行一些简单的优化，不开启 Profiling（JVM的性能监控）

- 2 : 受限的C1编译: 仅执行带方法调用次数以及循环回边执行次数 Profiling 的C1编译

- 3 : 完全C1编译: 会执行带有所有 Profiling 的C1代码

- 4 : C2编译: 使用C2编译器进行优化，该级别会启用一些编译耗时较长的优化，一些情况下会根据性能监控信息进行一些非常激进的性能优化

3. 热点代码

一开始一般由解释器解释执行，当虚拟机发现某个方法或代码块的运行特别频繁的时候，就会认为这些代码是“热点代码”。为了提高热点代码的执行效率，会用即时编译器(也就是JIT)把这些热点代码编译成与本地平台相关的机器码，并进行各层次的优化

3.1. 如何找到热点代码？

基于采样的热点探测

基于计数器的热点探测（Hotspot内置的两类计数器：方法调用计数器、回边计数器（循环体））

3.2. 热度衰减、半衰周期

如果不做任何设置，方法调用计数器统计的并不是方法被调用的绝对次数，而是一个相对的执行频率，即一段时间之内方法被调用的次数。当超过一定的时间限度，如果方法的调用次数仍然不足以让它提交给即时编译器编译，那这个方法的调用计数器就会被减少一半，这个过程称为方法调用计数器的热度衰减，而这段时间就称为此方法统计的半衰周期。

4. 方法内联

把目标方法的代码复制到发起调用的方法之中，避免发生真实的方法调用

4.1. 方法内联的条件

方法体足够小

被调用方法运行时的实现被可以唯一确定：

static方法、private方法及final方法 , JIT可以唯一确定具体的实现代码

public的实例方法，指向的实现可能是自身、父类、子类的代码（无法确定具体的实现代码，多态性）

4.2. 方法内联注意点

尽量让方法体小一些

尽量使用final、 private、 static关键字修饰方法，避免因为多态，需要对方法做额外的检查

某些场景下，可通过JVM参数修改阈值，从而让更多方法内联

4.3. 内联可能带来的问题

CodeCache（热点代码的缓存区）的溢出，导致JVM退化成解释执行模式

## 四、逃逸分析

分析变量能否逃出它的作用域

1. 四种逃逸

全局变量赋值逃逸、方法返回值逃逸、实例引用逃逸、线程逃逸（赋值给类变量或可以在其他线程中访问的实例变量）

2. 逃逸状态标记（全局级别逃逸）

一个对象可能从方法或者当前线程中逃逸

对象被作为方法的返回值；对象作为静态字段(static field)或者成员变量(field)；如果重写了某个类的finalize()方法,那么这个类的对象都会被标记，为全局逃逸状态并且一定会放在堆内存中

3. 逃逸状态标记（参数级别逃逸）

对象被作为参数传递给一个方法，但是在这个方法之外无法访问/对其他线程不可见

4. 标量替换

4.1. 标量: 不能被进一步分解的量，基础数据类型，对象引用

4.2. 聚合量: 可以进一步分解的量

通过逃逸分析确定该对象不会被外部访问，并且对象可以被进一步分解时, JVM不会创建该对象，而是创建它的成员变量来代替

5. 栈上分配

通过逃逸分析，能够确认对象不会被外部访问，就在栈上分配对象，对象在栈帧出栈时销毁（不像堆中对象要进行垃圾回收）

6. 其他应用：锁消除

## 五、垃圾回收

1. 什么场景下该使用什么垃圾回收策略?

1.1. 在对内存要求苛刻的场景: 想办法提高对象的回收效率，多回收掉一些对象,腾出更多内存

1.2. 在CPU使用率高的情况下: 降低高并发时垃圾回收的频率，让CPU更多地去执行你的业务而不是垃圾回收

2. 垃圾回收会发生在哪些区域？

线程共享部分：堆、方法区

3. 判断对象是否可以回收（已经死亡）的方法

3.1. 引用计数法（无法判断循环引用）

3.2. 可达性分析

对象：以根对象( GC Roots )作为起点向下搜索，走过的路径被称为引用链( Reference Chain )，如果某个对象到根对象没有引用链相连时，就认为这个对象是不可达的，可以回收

常量：e.g. 如果当前没有任何 String 对象引用该字符串常量的话，就说明该常量是废弃常量

类：需要同时满足下面 3 个条件才能算是 “无用的类”

- 该类所有的实例都已经被回收，也就是 Java 堆中不存在该类的任何实例对象。

- 加载该类的 ClassLoader 已经被回收。

- 该类对应的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

3.3. GC Roots包括哪些对象?

虚拟机栈(栈帧中的本地变量表)中引用的对象，方法区中类静态属性引用的对象，方法区中常量引用的对象，被同步锁持有的对象，本地方法栈中JNI (即Native方法)引用的对象

3.4. 四种引用

强引用（平时使用的引用，只要强引用在，永远不会回收被引用的对象）、软引用（内存不够再回收，加入引用队列告知被回收）、弱引用（发现就回收）、虚引用

3.5. 一个对象即使不可达，也不一定会被回收（判断一个对象的死亡至少需要两次标记）（对象可以被回收，就代表一定会被回收吗？）

如果对象进行可达性分析之后没发现与GC Roots相连的引用链，那它将会第一次标记并且进行一次筛选。判断的条件是决定这个对象是否有必要执行finalize()方法。如果对象有必要执行finalize()方法，则被放入F-Queue队列中。

GC对F-Queue队列中的对象进行二次标记。如果对象在finalize()方法中重新与引用链上的任何一个对象建立了关联，那么二次标记时则会将它移出“即将回收”集合。如果此时对象还没成功逃脱，那么只能被回收了。

3.6. finalize()的建议

避免使用finalize()方法，操作不当可能会导致问题（使用软引用，弱引用进行替代）

finalize()优先级低，何时会被调用无法确定，因为什么时间发生GC不确定

建议使用try..catch..finally来替代finalize()

4. 垃圾回收算法

基础垃圾回收算法：

4.1. 标记-清除

标记需要回收的对象，清理掉要回收的对象

实现简单，存在内存碎片、分配内存速度会受影响

4.2. 标记-整理

标记需要回收的对象，把所有的存活对象压缩到内存的一端

无碎片，整理存在开销

4.3. 复制

把内存分为两块,每次只使用一块，将正在使用的内存中的存活对象复制到未使用的内存中去，然后清除掉正在使用的内存中的所有对象，交换两个内存的角色，等待下次回收

性能好、无碎片，内存利用率低

综合垃圾回收算法：

4.4. 分代收集算法（主要）

把内存分成多个区域，不同区域使用不同的回收算法回收对象

4.5. 增量算法（主要）

每次只收集一小片区域的内存空间的垃圾

5. 分代收集算法

5.1. 堆的内存结构分为：新生代（伊甸园、存活区）、老年代、元空间

98% 的对象都是会很快消亡的

5.2. 回收类型

新生代回收( Minor GC / Young GC )

老年代回收( Major GC / Old GC )

清理整个堆( Full GC )

Major GC ≈ Full GC

5.3. 分代收集

对象创建会先发生在伊甸园，伊甸园满了之后，会开启垃圾回收，将存活的对象拷贝到存活区（两个区域 Fromsurvivior + Tosurvivor），存活区采用复制算法，每触发一下GC仍存活的对象年龄+1，超过阈值15后进入老年代，老年代采用标记-清除/整理算法

5.4. 例外

新建的对象不一定分配到伊甸园：对象大于PretenureSizeThreshold、新生代空间不够，就会直接分配到老年代

对象不一定要达到年龄才进入老年代：动态年龄：按照年龄从小到大对其所占用的大小进行累积，当累积的某个年龄大小超过了 survivor 区的一半时，取这个年龄和 MaxTenuringThreshold 中更小的一个值，作为新的晋升年龄阈值

5.5. 触发垃圾回收的条件

新生代：伊甸园空间不足

老年代：老年代空间不足（碎片，或内存空间真的不足了）；元空间不足；要晋升到老年代的的对象所占用的空间大于老年代的剩余空间；显式调用System.gc()

5.6. 分代的好处

更有效的清除不再需要的对象、提升了垃圾回收的效率

5.7. 分代收集算法的调优原则

合理设置Survivor区域的大小，避免内存浪费

让GC尽量发生在新生代，尽量减少Full GC的发生

5.8. 空间分配担保

空间分配担保是为了确保在 Minor GC 之前老年代本身还有容纳新生代所有对象的剩余空间。

6. 垃圾收集术语

6.1. Stop The World 简写为STW ，也叫全局停顿

Java代码停止运行，native代码继续运行，但不能与JVM进行交互

原因: 多半由于垃圾回收导致；也可能由Dump线程、死锁检查、Dump堆等导致

危害: 服务停止、没有响应；主从切换、危害生产环境

6.2. 并行收集 vs 并发收集

并行收集: 指多个垃圾收集线程并行工作，但是收集的过程中用户线程(你的业务线程)还是处于等待状态的

并发收集: 指用户线程与垃圾收集线程同时工作

6.3. 吞吐量

CPU用于运行用户代码的时间与CPU总消耗时间的比值

公式: 运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)

7. 垃圾收集器（新生代收集器）

利用垃圾收集算法，实现垃圾回收的实践落地

![输入图片说明](%E9%98%B6%E6%AE%B5%E5%85%AD/1.png)

7.1. Serial收集器（串行）

复制算法、单线程、简单、高效、收集过程全程Stop The World

适用场景：客户端程序，应用以-client模式运行时，默认使用的就是Serial；单核机器

7.2. ParNew收集器（Serial多线程版，并行）

复制算法、多线程，可使用ParallelGCThreads设置垃圾收集的线程数

适用场景：主要和CMS收集器配合使用

7.3. Parallel Scavenge收集器（吞吐量优先收集器，并行）

复制算法、并行的多线程收集器

可控制的吞吐量

MaxGCPauseMillis: 控制最大的垃圾收集停顿时间(尽力)

GCTimeRatio :设置吞吐量的大小,取值0-100 ，系统花费不超过1/(1+n)的时间用于垃圾收集

自适应GC策略: 可用-XX:+UseAdptiveSizePolicy打开。打开自适应策略后，无需手动设置新生代的大小( -Xmn)、Eden与Survivor区的比例( -XX:SurvivorRatio )等参数，虚拟机会自动根据系统的运行状况收集性能监控信息，动态地调整这些参数，从而达到最优的停顿时间以及最高的吞吐量

适用场景：注重吞吐量的场景

8. 垃圾收集器（老年代收集器）

8.1. Serial Old 收集器（Serial老年代版本，串行）

标记-整理算法

适用场景：可以和Serial/ParNew/Parallel Scavenge这三个新生代的垃圾收集器配合使用；CMS收集器出现故障的时候,会用Servial Old作为后备

8.2. Parallel Old 收集器（Parallel Scavenge老年代版本，并行）

标记-整理算法

适用场景：注重吞吐量的场景

8.3. CMS收集器 Concurrent Mark Sweep（并发收集器）

标记-清除算法

执行过程：1.初始标记，2.并发标记，3.并发预清理（不一定执行），4.并发可中止的预清理阶段（不一定执行），5.重新标记，6.并发清除，7.并发重置

优点：Stop The World的时间比较短，大多过程并发执行

缺点：

CPU资源比较敏感（并发阶段可能导致应用吞吐量的降低）

无法处理浮动垃圾（无法清理当前产生的垃圾）

不能等到老年代几乎满了才开始收集（预留的内存不够-> Concurrent Mode Failure -> Serial Old作为后备。可使用CMSInitiatingOccupancyFraction设置老年代占比达到多少就触发垃圾收集，默认68%）

内存碎片，标记-清除导致碎片的产生（UseCMSCompactAtFullCollection :在完成Full GC后是否要进行内存碎片整理，默认开启；CMSFullGCsBeforeCompaction: 进行几次Full GC后就进行一次内存碎片整理，默认0）

适用场景：希望系统停顿时间短，响应速度快的场景，比如各种服务器应用程序

9. G1收集器 Garbage First（可用在新生代和老年代）

面向服务器端应用的垃圾收集器

9.1. 内存布局

分region，E：Eden，S：Survivor，O：Old，H：Humongous（也看做老年代，存放大对象）

9.2. 设计思想

内存分块( Region )，跟踪每个Region里面的垃圾堆积的价值大小，构建一个优先列表，根据允许的收集时间，优先回收价值高的region

可以作用在整个堆，无内存碎片（复制算法），可控的停顿 MaxGCPauseMillis 根据期望停顿时间制定回收计划

9.3. 垃圾收集机制

Young GC：回收对象从整个伊甸园变成 E region

Mixed GC：老年代大小占整个堆的百分比达到一定阈值(可用-XX:InitiatingHeapOccupancyPercent指定，默认45%)，就触发；Mixed GC会回收所有Young Region，同时回收部分 Old Region

Full GC：复制对象内存不够，或者无法分配足够内存(比如巨型对象没有足够的连续分区分配)时，会触发Full GC；Full GC模式下，使用Serial Old模式；G1优化原则: 尽量减少Full GC的发生

9.4. 优化（减少Full GC）

增加预留内存(增大-XX:G1ReservePercent ，默认为堆的10% )

更早地回收垃圾(减少-XX:InitiatingHeapOccupancyPercent ，老年代达到该值就触发Mixed GC ，默认45% )

增加并发阶段使用的线程数(增大-XX:ConcGCThreads )

9.5. 适用场景

占用内存较大的应用(6G以上)，替换CMS垃圾收集器

机器内存6G以上选择G1，6G以下选择CMS

G1 >= jdk8

CMS <= jdk8

10. 如何选择收集器

10.1. 主要矛盾点

服务器应用：ParNew + CMS，G1

数据分析（高吞吐）：Parallel Scavenge + Parallel Old

客户端、单核嵌入式机器：Serial + Serial Old

10.2. 基础设施

操作系统 jdk

## 六、JVM 监控、故障排查、可视化工具、日志

# 第38周 JVM性能调优-实战篇

## 一、JVM 参数选项

1. 标准选项

java -help

2. 附加选项（非标准选项）

java -X

3. 高级选项

java -XX

4. 不应使用的选项

废弃、淘汰、删除的选项

## 二、JVM 性能调优

1. CPU占用过高

1.1. 无限while循环：尽量避免无限循环，或者让循环执行得慢一点

1.2. 频繁GC：降低GC频率

1.3. 频繁创建新对象：合理使用单例

1.4. 序列化和反序列化：选择合理的API实现功能

1.5. 正则表达式：减少字符匹配期间执行的回溯

1.6. 频繁的线程上下文切换：降低线程切换的频率

2. 堆内存溢出

2.1. 内存泄露：找到是什么原因导致对象没有被回收掉

2.2. 非内存泄露：为应用分配更多的堆内存，对象存储结构不合理，对象生命周期过长

3. 栈内存溢出

通常指虚拟机栈

使用Xss设置线程的栈的大小

3.1. 如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛StackOverflowError

3.2. 如果虚拟机的栈内存允许动态扩展，当无法申请到足够内存时，将拋出OutOfMemoryError（此时Dump堆，确保可以排查现场问题）

3.3. 如何运行更多线程？（每个线程有独立的程序计数器和虚拟机栈）

- 减小Xss配置

- 减少其他内存分配，以增大栈能分配的内存，栈能分配的内存=机器总内存-操作系统内存-堆内存-方法区内存-程序计数器内存-直接内存

- 尽量杀死其他程序

- 操作系统对线程数目有限制

4. 方法区溢出

<jdk8 方法区存储在持久代；>=jdk8 方法区存储在堆和元空间中

堆：静态变量、字符串常量池

元空间：类信息、运行时常量池

4.1. 常量池里对象太大

4.2. 加载的类的"种类”太多：动态代理的操作库生成了大量的动态类、JSP项目（第一次被访问时才会被编译成java类）、脚本语言动态类加载

4.3. 解决办法：为常量池保留足够的空间（堆）；防止类加载过多导致的溢出（元空间），留空元空间相关配置（JVM会动态分配），或设置合理大小的元空间

5. 直接内存溢出

直接内存是一块由操作系统直接管理的内存，也叫堆外内存

可以使用Unsafe或ByteBuffer分配直接内存

可用-XX:MaxDirectMemorySize控制，默认是0 ，表示不限制

5.1. 直接内存使用场景

直接内存中的对象读写比堆快很多

频繁的IO操作，比如并发网络通信

有很大的数据需要存储，生命周期很长

5.2. Unsafe

溢出时报: java.lang.OutOfMemoryError

-XX: MaxDirectMemorySize不起作用

5.3. ByteBuffer

溢出时报: java.lang.OutOfMemoryError: Direct buffer memory

-XX:MaxDirectMemorySize起作用

ByteBuffer底层也是用Unsafe去分配内存的

5.4. 堆Dump文件看不出问题或者比较小，可考虑直接内存溢出问题，配置内存时，应给直接内存预留足够的空间

6. 代码缓存区满 code cache

热点代码被编译后存放的区域

代码缓存区即将耗尽时，会尝试回收一些早期编译、很久未被调用的方法

6.1. 设置合理的代码缓存区大小

6.2. 如果项目平时性能OK，但突然出现性能下降，业务没有问题，可排查是否由代码缓存区满所导致

7. 代码运行越来越慢

7.1. Stop The World 过长

7.2. 线程争抢过于激烈

7.3. 项目依赖的资源导致变慢

- 数据库、网络...

- Code Cache 满了

7.4. 服务器问题

- 操作系统问题

- 其他进程争抢资源

小小之植物/Java项目

简介

发行版

贡献者

近期动态

小小之植物/Java项目 .gitee-modal { width: 500px !important; }

简介

发行版

贡献者

近期动态

搜索帮助

小小之植物/Java项目