java计算机系统的性能瓶颈_Java 性能优化

Java 性能优化

哪些资源,容易成为瓶颈?

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

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

CPU

c5a0d470ef6d

image-20201014145901815.png

具体情况如下。

1.top 命令 —— CPU 性能

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

c5a0d470ef6d

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 的数值。

c5a0d470ef6d

image-20201014143406966.png

c5a0d470ef6d

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)

c5a0d470ef6d

image-20201014143837599.png

比较关注的有下面几列:

b 如果系统有负载问题,就可以看一下 b 列(Uninterruptible Sleep),它的意思是等待 I/O,可能是读盘或者写盘动作比较多;

si/so 显示了交换分区的一些使用情况,交换分区对性能的影响比较大,需要格外关注;

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

ps -a

c5a0d470ef6d

image-20201014144822462.png

cat /proc/15115/status

c5a0d470ef6d

image-20201014145004810.png

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

内存

c5a0d470ef6d

image-20201014150305504.png

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

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

1. top 命令

c5a0d470ef6d

image-20201014142818183.png

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

VIRT 这里是指虚拟内存,一般比较大,不用做过多关注;

RES 我们平常关注的是这一列的数值,它代表了进程实际占用的内存,平常在做监控时,主要监控的也是这个数值;

SHR 指的是共享内存,比如可以复用的一些 so 文件等。

2. CPU 缓存

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

c5a0d470ef6d

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 也能得到一样的结果:

c5a0d470ef6d

image-20201014151549383.png

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

3. 预先加载

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

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

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

I/O

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

c5a0d470ef6d

image-20201014154418546.png

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

1. iostat

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

c5a0d470ef6d

image-20201014155909092.png

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

c5a0d470ef6d

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 读取内核缓存中的内容,发送出去。

c5a0d470ef6d

image-20201014161130644.png

没有采取零拷贝手段的图

(2)采取了零拷贝手段

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

c5a0d470ef6d

image-20201014161154536.png

采取了零拷贝手段的图

如何获取代码性能数据

nmon —— 获取系统性能数据

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

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

c5a0d470ef6d

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

c5a0d470ef6d

image-20201014174512330.png

jvisualvm —— 获取 JVM 性能数据

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

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

c5a0d470ef6d

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 安全认证方式连接。

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

c5a0d470ef6d

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 此时正在疯狂运转。

c5a0d470ef6d

image-20201014175927631.png

2内存

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

c5a0d470ef6d

image-20201014175951617.png

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

案例分析

缓存

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

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

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

c5a0d470ef6d

image-20201014180446328.png

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

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

Guava 的 LoadingCache

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

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

缓存空间过小,就会造成高命中率的元素被频繁移出,失去了缓存的意义;

缓存空间过大,不仅浪费宝贵的缓存资源,还会对垃圾回收产生一定的压力。

通过 Maven,即可引入 guava 的 jar 包:

com.google.guava

guava

29.0-jre

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

c5a0d470ef6d

image-20201014180646566.png

1.缓存初始化

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

maximumSize 这个参数用来设置缓存池的最大容量,达到此容量将会清理其他元素;

initialCapacity 默认值是 16,表示初始化大小;

concurrencyLevel 默认值是 4,和初始化大小配合使用,表示会将缓存的内存划分成 4 个 segment,用来支持高并发的存取。

2.缓存操作

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

使用 put 方法手动处理,比如,我从数据库里查询出一个 User 对象,然后手动调用代码进去;

主动触发( 这也是 Loading 这个词的由来),通过提供一个 CacheLoader 的实现,就可以在用到这个对象的时候,进行延迟加载。

public static void main(String[] args) {

LoadingCache lc = CacheBuilder

.newBuilder()

.build(new CacheLoader() {

@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") 时,第一次会比较缓慢,因为它需要到数据源进行获取;第二次就瞬间返回了,也就是缓存命中了。具体时序可以参见下面这张图。

c5a0d470ef6d

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。

c5a0d470ef6d

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。

c5a0d470ef6d

image-20201014183500124.png

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

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

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

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

以后再说~~~

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值