Java 性能优化

哪些资源，容易成为瓶颈？

计算机各个组件之间的速度往往很不均衡，比如 CPU 和硬盘，比兔子和乌龟的速度差还大，那么按照我们前面介绍的木桶理论，可以说这个系统是存在着短板的。

当系统存在短板时，就会对性能造成较大的负面影响，比如当 CPU 的负载特别高时，任务就会排队，不能及时执行。而其中，CPU、内存、I/O 这三个系统组件，又往往容易成为瓶颈。

CPU

image-20201014145901815.png

具体情况如下。

1.top 命令 —— CPU 性能

如下图，当进入 top 命令后，按 1 键即可看到每核 CPU 的运行指标和详细性能。

image-20201014142818183.png

CPU 的使用有多个维度的指标，下面分别说明：

us 用户态所占用的 CPU 百分比，即引用程序所耗费的 CPU；
sy 内核态所占用的 CPU 百分比，需要配合 vmstat 命令，查看上下文切换是否频繁；
ni 高优先级应用所占用的 CPU 百分比；
wa 等待 I/O 设备所占用的 CPU 百分比，经常使用它来判断 I/O 问题，过高输入输出设备可能存在非常明显的瓶颈；
hi 硬中断所占用的 CPU 百分比；
si 软中断所占用的 CPU 百分比；
st 在平常的服务器上这个值很少发生变动，因为它测量的是宿主机对虚拟机的影响，即虚拟机等待宿主机 CPU 的时间占比，这在一些超卖的云服务器上，经常发生；
id 空闲 CPU 百分比。

一般地，我们比较关注空闲 CPU 的百分比，它可以从整体上体现 CPU 的利用情况。

2.负载 —— CPU 任务排队情况

如果我们评估 CPU 任务执行的排队情况，那么需要通过负载（load）来完成。除了 top 命令，使用 uptime 命令也能够查看负载情况，load 的效果是一样的，分别显示了最近 1min、5min、15min 的数值。

image-20201014143406966.png

image-20201014143634492.png

如上图所示，以单核操作系统为例，将 CPU 资源抽象成一条单向行驶的马路，则会发生以下三种情况：

马路上的车只有 4 辆，车辆畅通无阻，load 大约是 0.5；
马路上的车有 8 辆，正好能首尾相接安全通过，此时 load 大约为 1；
马路上的车有 12 辆，除了在马路上的 8 辆车，还有 4 辆等在马路外面，需要排队，此时 load 大约为 1.5。

那 load 为 1 代表的是啥？针对这个问题，误解还是比较多的。

很多人看到 load 的值达到 1，就认为系统负载已经到了极限。这在单核的硬件上没有问题，但在多核硬件上，这种描述就不完全正确，它还与 CPU 的个数有关。例如：

单核的负载达到 1，总 load 的值约为 1；
双核的每核负载都达到 1，总 load 约为 2；
四核的每核负载都达到 1，总 load 约为 4。

所以，对于一个 load 到了 10，却是 16 核的机器，你的系统还远没有达到负载极限。

3.vmstat —— CPU 繁忙程度

要看 CPU 的繁忙程度，可以通过 vmstat 命令，下图是 vmstat 命令的一些输出信息。(Mac OS下面是vm_stat)

image-20201014143837599.png

比较关注的有下面几列：

b 如果系统有负载问题，就可以看一下 b 列（Uninterruptible Sleep），它的意思是等待 I/O，可能是读盘或者写盘动作比较多；
si/so 显示了交换分区的一些使用情况，交换分区对性能的影响比较大，需要格外关注；

cs 每秒钟上下文切换（Context Switch）的数量，如果上下文切换过于频繁，就需要考虑是否是进程或者线程数开的过多。

ps -a

image-20201014144822462.png

cat /proc/15115/status

image-20201014145004810.png

进程状态是T—— Stopped。然后看看voluntary_ctxt_switches 和nonvoluntary_ctxt_switches的数值 —— 它可以告诉你进程占用（或者释放）了多少次CPU。等几秒钟之后，再次执行该命令，看看这些数值有没有增加。这些数值没有增加，据此可以得出结论，这个进程是挂死了

内存

image-20201014150305504.png

MMU是Memory Management Unit的缩写，中文名是内存管理单元。MMU的作用是把虚拟地址转换成物理地址。TLB其实就是一块高速缓存。

逻辑地址可以映射到两个内存段上：物理内存和虚拟内存，那么整个系统可用的内存就是两者之和。比如你的物理内存是 4GB，分配了 8GB 的 SWAP 分区，那么应用可用的总内存就是 12GB。

1. top 命令

image-20201014142818183.png

如上图所示，我们看一下内存的几个参数，从 top 命令可以看到几列数据，注意方块框起来的三个区域，解释如下：

VIRT 这里是指虚拟内存，一般比较大，不用做过多关注；
RES 我们平常关注的是这一列的数值，它代表了进程实际占用的内存，平常在做监控时，主要监控的也是这个数值；
SHR 指的是共享内存，比如可以复用的一些 so 文件等。

2. CPU 缓存

由于 CPU 和内存之间的速度差异非常大，解决方式就是加入高速缓存。实际上，这些高速缓存往往会有多层，如下图所示。

image-20201014151421124.png

Java 有大部分知识点是围绕多线程的，那是因为，如果一个线程的时间片跨越了多个 CPU，那么就会存在同步问题。

在 Java 中，和 CPU 缓存相关的最典型的知识点，就是在并发编程中，针对 Cache line 的伪共享（False Sharing）问题。

伪共享指的是在这些高速缓存中，以缓存行为单位进行存储，哪怕你修改了缓存行中一个很小很小的数据，它都会整个刷新。所以，当多线程修改一些变量的值时，如果这些变量都在同一个缓存行里，就会造成频繁刷新，无意中影响彼此的性能。

CPU 的每个核，基本是相同的，我们拿 CPU0 来说，可以通过以下的命令查看它的缓存行大小，这个值一般是 64。

cat /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size

当然，通过 cpuinfo 也能得到一样的结果：

image-20201014151549383.png

在 JDK8 以上的版本，通过开启参数 -XX:-RestrictContended，就可以使用注解 @sun.misc.Contended 进行补齐，来避免伪共享的问题。

3. 预先加载

另外，一些程序的默认行为也会对性能有所影响，比如 JVM 的 -XX:+AlwaysPreTouch 参数。

默认情况下，JVM 虽然配置了 Xmx、Xms 等参数，指定堆的初始化大小和最大大小，但它的内存在真正用到时，才会分配；但如果加上 AlwaysPreTouch 这个参数，JVM 会在启动的时候，就把所有的内存预先分配。

这样，启动时虽然慢了些，但运行时的性能会增加。

I/O

I/O 设备可能是计算机里速度最慢的组件了，它指的不仅仅是硬盘，还包括外围的所有设备。那硬盘有多慢呢？我们不去探究不同设备的实现细节，直接看它的写入速度（数据未经过严格测试，仅作参考）。

image-20201014154418546.png

如上图所示，可以看到普通磁盘的随机写与顺序写相差非常大，但顺序写与 CPU 内存依旧不在一个数量级上。

1. iostat

最能体现 I/O 繁忙程度的，就是 top 命令和 vmstat 命令中的 wa%。如果你的应用写了大量的日志，I/O wait 就可能非常高。

image-20201014155909092.png

便捷好用的查看磁盘 I/O 的工具，iostat 就是

image-20201014160056730.png

上图中的指标详细介绍如下所示。

%util：我们非常关注这个数值，通常情况下，这个数字超过 80%，就证明 I/O 的负荷已经非常严重了。
Device：表示是哪块硬盘，如果你有多块磁盘，则会显示多行。
avgqu-sz：平均请求队列的长度，这和十字路口排队的汽车也非常类似。显然，这个值越小越好。
awai：响应时间包含了队列时间和服务时间，它有一个经验值。通常情况下应该是小于 5ms 的，如果这个值超过了 10ms，则证明等待的时间过长了。
svctm：表示操作 I/O 的平均服务时间。你可以回忆一下第 01 课时的内容，在这里就是 AVG 的意思。svctm 和 await 是强相关的，如果它们比较接近，则表示 I/O 几乎没有等待，设备的性能很好；但如果 await 比 svctm 的值高出很多，则证明 I/O 的队列等待时间太长，进而系统上运行的应用程序将变慢

2. 零拷贝

硬盘上的数据，在发往网络之前，需要经过多次缓冲区的拷贝，以及用户空间和内核空间的多次切换。如果能减少一些拷贝的过程，效率就能提升，所以零拷贝应运而生。

零拷贝是一种非常重要的性能优化手段，比如常见的 Kafka、Nginx 等，就使用了这种技术。我们来看一下有无零拷贝之间的区别。

（1）没有采取零拷贝手段

如下图所示，传统方式中要想将一个文件的内容通过 Socket 发送出去，则需要经过以下步骤：

将文件内容拷贝到内核空间；
将内核空间内存的内容，拷贝到用户空间内存，比如 Java 应用读取 zip 文件；
用户空间将内容写入到内核空间的缓存中；
Socket 读取内核缓存中的内容，发送出去。

image-20201014161130644.png

没有采取零拷贝手段的图

（2）采取了零拷贝手段

零拷贝有多种模式，我们用 sendfile 来举例。如下图所示，在内核的支持下，零拷贝少了一个步骤，那就是内核缓存向用户空间的拷贝，这样既节省了内存，也节省了 CPU 的调度时间，让效率更高。

image-20201014161154536.png

采取了零拷贝手段的图

如何获取代码性能数据

nmon —— 获取系统性能数据

除了在上一课时中介绍的 top、free 等命令，还有一些将资源整合在一起的监控工具，

nmon 便是一个老牌的 Linux 性能监控工具，它不仅有漂亮的监控界面（如下图所示），还能产出细致的监控报表。

image-20201014170308528.png

nmon 监控界面

上一课时介绍的一些操作系统性能指标，都可从 nmon 中获取。它的监控范围很广，包括 CPU、内存、网络、磁盘、文件系统、NFS、系统资源等信息。

nmon 在 sourceforge 发布，我已经下载下来并上传到了仓库中。比如我的是 CentOS 7 系统，选择对应的版本即可执行。

./nmon_x86_64_centos7

按 C 键可加入 CPU 面板；按 M 键可加入内存面板；按 N 键可加入网络；按 D 键可加入磁盘等。

通过下面的命令，表示每 5 秒采集一次数据，共采集 12 次，它会把这一段时间之内的数据记录下来。比如本次生成了 localhost_200623_1633.nmon 这个文件，我们把它从服务器上下载下来。

./nmon_x86_64_centos7  -f -s 5 -c 12 -m .

scp -r root@10.162.12.96:/root/nmon/xs-cci-zhuji-sv_201014_1729.html /Users/chandler/Downloads

image-20201014174512330.png

jvisualvm —— 获取 JVM 性能数据

jvisualvm 原是随着 JDK 发布的一个工具，Java 9 之后开始单独发布。通过它，可以了解应用在运行中的内部情况。我们可以连接本地或者远程的服务器，监控大量的性能数据。

通过插件功能，jvisualvm 能获得更强大的扩展。如下图所示，建议把所有的插件下载下来进行体验。

image-20201014175149887.png

要想监控远程的应用，还需要在被监控的 App 上加入 jmx 参数。

-Dcom.sun.management.jmxremote.port=14000
-Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false

上述配置的意义是开启 JMX 连接端口 14000，同时配置不需要 SSL 安全认证方式连接。

对于性能优化来说，我们主要用到它的采样器。注意，由于抽样分析过程对程序运行性能有较大的影响，一般我们只在测试环境中使用此功能。

image-20201014175334085.png

jvisualvm CPU 性能采样图

对于一个 Java 应用来说，除了要关注它的 CPU 指标，垃圾回收方面也是不容忽视的性能点，我们主要关注以下三点。

CPU 分析：统计方法的执行次数和执行耗时，这些数据可用于分析哪个方法执行时间过长，成为热点等。
内存分析：可以通过内存监视和内存快照等方式进行分析，进而检测内存泄漏问题，优化内存使用情况。
线程分析：可以查看线程的状态变化，以及一些死锁情况。

JMC —— 获取 Java 应用详细性能数据

对于我们常用的 HotSpot 来说，有更强大的工具，那就是 JMC。 JMC 集成了一个非常好用的功能：JFR（Java Flight Recorder）。

JFR 功能是建在 JVM 内部的，不需要额外依赖，可以直接使用，它能够监测大量数据。比如，我们提到的锁竞争、延迟、阻塞等；甚至在 JVM 内部，比如 SafePoint、JIT 编译等，也能去分析。

1线程

以 C2 编译器线程为例，可以看到详细的热点类，以及方法内联后的代码大小。如下图所示，C2 此时正在疯狂运转。

image-20201014175927631.png

2内存

通过内存界面，可以看到每个时间段内内存的申请情况。在排查内存溢出、内存泄漏等情况时，这个功能非常有用。

image-20201014175951617.png

篇幅有限～～～暂时不介绍

案例分析

缓存

和缓冲类似，缓存可能是软件中使用最多的优化技术了，比如：在最核心的 CPU 中，就存在着多级缓存；为了消除内存和存储之间的差异，各种类似 Redis 的缓存框架更是层出不穷。

缓存的优化效果是非常好的，它既可以让原本载入非常缓慢的页面，瞬间秒开，也能让本是压力山大的数据库，瞬间清闲下来。

缓存，本质上是为了协调两个速度差异非常大的组件，如下图所示，通过加入一个中间层，将常用的数据存放在相对高速的设备中。

image-20201014180446328.png

在我们平常的应用开发中，根据缓存所处的物理位置，一般分为进程内缓存和进程外缓存。

今天主要聚焦在进程内缓存上，在 Java 中，进程内缓存，就是我们常说的堆内缓存。Spring 的默认实现里，就包含 Ehcache、JCache、Caffeine、Guava Cache 等。

Guava 的 LoadingCache

Guava 是一个常用的工具包，其中的 LoadingCache（下面简称 LC），是非常好用的堆内缓存工具。通过学习 LC 的结构，即可了解堆内缓存设计的一般思路。

缓存一般是比较昂贵的组件，容量是有限制的，设置得过小，或者过大，都会影响缓存性能：

缓存空间过小，就会造成高命中率的元素被频繁移出，失去了缓存的意义；
缓存空间过大，不仅浪费宝贵的缓存资源，还会对垃圾回收产生一定的压力。

通过 Maven，即可引入 guava 的 jar 包：

<dependency> 
    <groupId>com.google.guava</groupId> 
    <artifactId>guava</artifactId> 
    <version>29.0-jre</version> 
</dependency>

下面介绍一下 LC 的常用操作：

image-20201014180646566.png

1.缓存初始化

首先，我们可以通过下面的参数设置一下 LC 的大小。一般，我们只需给缓存提供一个上限。

maximumSize 这个参数用来设置缓存池的最大容量，达到此容量将会清理其他元素；
initialCapacity 默认值是 16，表示初始化大小；
concurrencyLevel 默认值是 4，和初始化大小配合使用，表示会将缓存的内存划分成 4 个 segment，用来支持高并发的存取。

2.缓存操作

那么缓存数据是怎么放进去的呢？有两种模式：

使用 put 方法手动处理，比如，我从数据库里查询出一个 User 对象，然后手动调用代码进去；
主动触发（这也是 Loading 这个词的由来），通过提供一个 CacheLoader 的实现，就可以在用到这个对象的时候，进行延迟加载。

public static void main(String[] args) { 

    LoadingCache<String, String> lc = CacheBuilder 

            .newBuilder() 

            .build(new CacheLoader<String, String>() { 

                @Override 

                public String load(String key) throws Exception { 

                    return slowMethod(key); 

                } 

            }); 

} 

static String slowMethod(String key) throws Exception { 

    Thread.sleep(1000); 

    return key + ".result"; 

}

上面是主动触发的示例代码，你可以使用 get 方法获取缓存的值。比如，当我们执行 lc.get("a") 时，第一次会比较缓慢，因为它需要到数据源进行获取；第二次就瞬间返回了，也就是缓存命中了。具体时序可以参见下面这张图。

image-20201014182825908.png

3.回收策略

缓存的大小是有限的，满了以后怎么办？这就需要回收策略进行处理，接下来我会向你介绍三种回收策略。

（1）第一种回收策略基于容量

这个比较好理解，也就是说如果缓存满了，就会按照 LRU 算法来移除其他元素。

（2）第二种回收策略基于时间

一种方式是，通过 expireAfterWrite 方法设置数据写入以后在某个时间失效；
另一种是，通过 expireAfterAccess 方法设置最早访问的元素，并优先将其删除。

（3）第三种回收策略基于 JVM 的垃圾回收

我们都知道对象的引用有强、软、弱、虚等四个级别，通过 weakKeys 等函数即可设置相应的引用级别。当 JVM 垃圾回收的时候，会主动清理这些数据。

关于第三种回收策略，有一个高频面试题：如果你同时设置了 weakKeys 和 weakValues函数，LC 会有什么反应？

答案：如果同时设置了这两个函数，它代表的意思是，当没有任何强引用，与 key 或者 value 有关系时，就删掉整个缓存项。这两个函数经常被误解。

4.缓存造成内存故障

LC 可以通过 recordStats 函数，对缓存加载和命中率等情况进行监控。

值得注意的是：LC 是基于数据条数而不是基于缓存物理大小的，所以如果你缓存的对象特别大，就会造成不可预料的内存占用。

围绕这点，我分享一个由于不正确使用缓存导致的常见内存故障。

大多数堆内缓存，都会将对象的引用设置成弱引用或软引用，这样内存不足时，可以优先释放缓存占用的空间，给其他对象腾出地方。这种做法的初衷是好的，但容易出现问题。

当你的缓存使用非常频繁，数据量又比较大的情况下，缓存会占用大量内存，如果此时发生了垃圾回收（GC），缓存空间会被释放掉，但又被迅速占满，从而会再次触发垃圾回收。如此往返，GC 线程会耗费大量的 CPU 资源，缓存也就失去了它的意义。

所以在这种情况下，把缓存设置的小一些，减轻 JVM 的负担，是一个很好的方法。

缓存算法

1.算法介绍

堆内缓存最常用的有 FIFO、LRU、LFU 这三种算法。

FIFO

这是一种先进先出的模式。如果缓存容量满了，将会移除最先加入的元素。这种缓存实现方式简单，但符合先进先出的队列模式场景的功能不多，应用场景较少。

LRU

LRU 是最近最少使用的意思，当缓存容量达到上限，它会优先移除那些最久未被使用的数据，LRU是目前最常用的缓存算法，稍后我们会使用 Java 的 API 简单实现一个。

LFU

LFU 是最近最不常用的意思。相对于 LRU 的时间维度，LFU 增加了访问次数的维度。如果缓存满的时候，将优先移除访问次数最少的元素；而当有多个访问次数相同的元素时，则优先移除最久未被使用的元素。

2.实现一个 LRU 算法

Java 里面实现 LRU 算法可以有多种方式，其中最常用的就是 LinkedHashMap，*这也是一个需要你注意的*面试高频考点**。

首先，我们来看一下 LinkedHashMap 的构造方法：

复制代码

public LinkedHashMap(int initialCapacity, 

            float loadFactor, 

            boolean accessOrder)

accessOrder 参数是实现 LRU 的关键。当 accessOrder 的值为 true 时，将按照对象的访问顺序排序；当 accessOrder 的值为 false 时，将按照对象的插入顺序排序。我们上面提到过，按照访问顺序排序，其实就是 LRU。

image-20201014183537730.png

如上图，按照缓存的一般设计方式，和 LC 类似，当你向 LinkedHashMap 中添加新对象的时候，就会调用 removeEldestEntry 方法。这个方法默认返回 false，表示永不过期。我们只需要覆盖这个方法，当超出容量的时候返回 true，触发移除动作就可以了。关键代码如下：

public class LRU extends LinkedHashMap { 
    int capacity; 
    public LRU(int capacity) { 
        super(16, 0.75f, true); 
        this.capacity = capacity; 
    } 
    @Override 
    protected boolean removeEldestEntry(Map.Entry eldest) { 
        return size() > capacity; 
    } 
}

相比较 LC，这段代码实现的功能是比较简陋的，它甚至不是线程安全的，但它体现了缓存设计的一般思路，是 Java 中最简单的 LRU 实现方式。

缓存优化的一般思路

一般，缓存针对的主要是读操作。当你的功能遇到下面的场景时，就可以选择使用缓存组件进行性能优化：

存在数据热点，缓存的数据能够被频繁使用；
读操作明显比写操作要多；
下游功能存在着比较悬殊的性能差异，下游服务能力有限；
加入缓存以后，不会影响程序的正确性，或者引入不可预料的复杂性。

缓存组件和缓冲类似，也是在两个组件速度严重不匹配的时候，引入的一个中间层，但它们服务的目标是不同的：

缓冲，数据一般只使用一次，等待缓冲区满了，就执行 flush 操作；
缓存，数据被载入之后，可以多次使用，数据将会共享多次。

缓存最重要的指标就是命中率，有以下几个因素会影响命中率。

（1）缓存容量

缓存的容量总是有限制的，所以就存在一些冷数据的逐出问题。但缓存也不是越大越好，它不能明显挤占业务的内存。

（2）数据集类型

如果缓存的数据是非热点数据，或者是操作几次就不再使用的冷数据，那命中率肯定会低，缓存也会失去了它的作用。

（3）缓存失效策略

缓存算法也会影响命中率和性能，目前效率最高的算法是 Caffeine 使用的 W-TinyLFU 算法，它的命中率非常高，内存占用也更小。新版本的 spring-cache，已经默认支持 Caffeine。

image-20201014183500124.png

推荐使用 Guava Cache 或者 Caffeine 作为堆内缓存解决方案，然后通过它们提供的一系列监控指标，来调整缓存的大小和内容，一般来说：

缓存命中率达到 50% 以上，作用就开始变得显著；

缓存命中率低于 10%，那就需要考虑缓存组件的必要性了。

引入缓存组件，能够显著提升系统性能，但也会引入新的问题。其中，最典型的问题：如何保证缓存与源数据的同步？

以后再说～～～