java性能调优学习笔记一

最新推荐文章于 2023-06-02 06:52:39 发布

wangrr827927

最新推荐文章于 2023-06-02 06:52:39 发布

阅读量477

点赞数

分类专栏： java基础文章标签： java

本文链接：https://blog.csdn.net/wangrr827927/article/details/114175977

版权

java基础专栏收录该内容

5 篇文章 0 订阅

订阅专栏

一、为什么要做性能调优

所有的系统在开发完成之后，多多少少都会有性能问题。我们首先要做的是想办法把问题提前暴露出来，例如进行压力测试、模拟可能的操作场景等等，再通过性能调优去解决这些问题。系统响应是体现系统性能最直接的一个参考因素。做好性能调优，可以有以下益处：

性能调优可以使系统更加稳定，清楚系统的极限。因为一款线上的产品没有经过性能测试，那就好比是一颗定时炸弹，你不知道它什么时候会出现问题，你也不清楚它能承受的极限在哪。性能问题分以下两种情况：有的是时间累积慢慢产生的，到一定时间自然就会爆炸；更多的是由访问量的波动导致的，例如，在活动或者公司产品用户量上升。而且当你清楚知道系统的极限，在产品经理或老板告诉你预计有几十万的用户访问量，询问系统能否承受住压力，你可以很明确的回答。
让用户体验更佳。如果系统没有进行调优，系统的部分功能的响应时间可能会长达十几秒以上；在抢购活动中，无法进入活动页面等，这些都会给用户带来不好的体验。
在比较大的系统中，还能帮助公司节约资源。例如系统调优前需要10台服务器才能保证系统性能指标正常，但是做好系统调优，可以在不占用这么多服务器资源的情况下，把系统的各项性能指标提升上去。

二、什么时候开始介入调优

在项目开发的初期，我们没必要过于在意性能优化，这样反而让我们疲于性能优化，不仅不会给系统性能带来提升，还会影响开发进度，甚至获得相反的结果，给系统带来新的问题。

在开发阶段，我们只需要保证编码优秀、高效以及良好的程序设计，比如，减少磁盘I/O操作、降低竞争锁的使用以及使用高效的算法等。遇到比较复杂的业务，我们可以充分利用设计模式来优化业务代码。比如设计商品价格的时候，往往会有很多折扣活动、红包活动，我们可以用装饰模式去设计这个业务。

在系统编码完成之后，我们就可以对系统进行性能测试了。根据产品经理提供的线上预期数据，在提供的参考平台上进行压测，通过性能分析、统计工具来统计各项性能指标，看是否在预期范围之内。性能调优的标准，响应时间、吞吐量、计算机资源分配使用率、负载承受能力。

在项目成功上线后，我们还需要根据线上的实际情况，依据日志监控以及性能统计日志，来观测系统性能问题，一旦发现问题，就要对日志进行分析并及时修复问题。

三、哪些计算机资源会成为系统的性能瓶颈

CPU：有的应用需要大量计算，他们会长时间、不间断地占用 CPU 资源，导致其他资源无法争夺到 CPU 而响应缓慢，从而带来系统性能问题。例如，代码递归导致的无限循环，正则表达式引起的回溯（https://www.cnblogs.com/leeego-123/p/11119416.html），JVM 频繁的 FULL GC，以及多线程编程造成的大量上下文切换等，这些都有可能导致 CPU 资源繁忙。
内存：Java 程序一般通过 JVM 对内存进行分配管理，主要是用 JVM 中的堆内存来存储 Java 创建的对象。系统堆内存的读写速度非常快，所以基本不存在读写性能瓶颈。但是由于内存成本要比磁盘高，相比磁盘，内存的存储空间又非常有限。所以当内存空间被占满，对象无法回收时，就会导致内存溢出、内存泄露等问题。
磁盘 I/O：磁盘相比内存来说，存储空间要大很多，但磁盘 I/O 读写的速度要比内存慢，虽然目前引入的 SSD 固态硬盘已经有所优化，但仍然无法与内存的读写速度相提并论。
网络：网络对于系统性能来说，也起着至关重要的作用。如果你购买过云服务，一定经历过，选择网络带宽大小这一环节。带宽过低的话，对于传输数据比较大，或者是并发量比较大的系统，网络就很容易成为性能瓶颈。
异常：Java 应用中，抛出异常需要构建异常栈，对异常进行捕获和处理，这个过程非常消耗系统性能。如果在高并发的情况下引发异常，持续地进行异常处理，那么系统的性能就会明显地受到影响。
数据库：大部分系统都会用到数据库，而数据库的操作往往是涉及到磁盘 I/O 的读写。大量的数据库读写操作，会导致磁盘 I/O 性能瓶颈，进而导致数据库操作的延迟性。对于有大量数据库读写操作的系统来说，数据库的性能优化是整个系统的核心。
锁竞争：在并发编程中，我们经常会需要多个线程，共享读写操作同一个资源，这个时候为了保持数据的原子性（即保证这个共享资源在一个线程写的时候，不被另一个线程修改），我们就会用到锁。锁的使用可能会带来上下文切换，从而给系统带来性能开销。JDK1.6 之后，Java 为了降低锁竞争带来的上下文切换，对 JVM 内部锁已经做了多次优化，例如，新增了偏向锁、自旋锁、轻量级锁、锁粗化、锁消除等。而如何合理地使用锁资源，优化锁资源，就需要你了解更多的操作系统知识、Java 多线程编程基础，积累项目经验，并结合实际场景去处理相关问题。

四、衡量系统性能的指标

1、响应时间
响应时间是衡量系统性能的重要指标之一，响应时间越短，性能越好，一般一个接口的响应时间是在毫秒级。在系统中，我们可以把响应时间自下而上细分为以下几种：
数据库响应时间：数据库操作所消耗的时间，往往是整个请求链中最耗时的；
服务端响应时间：服务端包括 Nginx 分发的请求所消耗的时间以及服务端程序执行所消耗的时间；
网络响应时间：这是网络传输时，网络硬件需要对传输的请求进行解析等操作所消耗的时间；
客户端响应时间：对于普通的 Web、App 客户端来说，消耗时间是可以忽略不计的，但如果你的客户端嵌入了大量的逻辑处理，消耗的时间就有可能变长，从而成为系统的瓶颈。

2、吞吐量
在测试中，我们往往会比较注重系统接口的 TPS（每秒事务处理量），因为 TPS 体现了接口的性能，TPS 越大，性能越好。在系统中，我们也可以把吞吐量自下而上地分为两种：磁盘吞吐量和网络吞吐量。
我们先来看磁盘吞吐量，磁盘性能有两个关键衡量指标。
一种是 IOPS（Input/Output Per Second），即每秒的输入输出量（或读写次数），这种是指单位时间内系统能处理的 I/O 请求数量，I/O 请求通常为读或写数据操作请求，关注的是随机读写性能。适应于随机读写频繁的应用，如小文件存储（图片）、OLTP 数据库、邮件服务器。
另一种是数据吞吐量，这种是指单位时间内可以成功传输的数据量。对于大量顺序读写频繁的应用，传输大量连续数据，例如，电视台的视频编辑、视频点播 VOD（Video On Demand），数据吞吐量则是关键衡量指标。
接下来看网络吞吐量，这个是指网络传输时没有帧丢失的情况下，设备能够接受的最大数据速率。网络吞吐量不仅仅跟带宽有关系，还跟 CPU 的处理能力、网卡、防火墙、外部接口以及 I/O 等紧密关联。而吞吐量的大小主要由网卡的处理能力、内部程序算法以及带宽大小决定。
3、计算机资源分配使用率
通常由 CPU 占用率、内存使用率、磁盘 I/O、网络 I/O 来表示资源使用率。这几个参数好比一个木桶，如果其中任何一块木板出现短板，任何一项分配不合理，对整个系统性能的影响都是毁灭性的。
4、负载承受能力
当系统压力上升时，你可以观察，系统响应时间的上升曲线是否平缓。这项指标能直观地反馈给你，系统所能承受的负载压力极限。例如，当你对系统进行压测时，系统的响应时间会随着系统并发数的增加而延长，直到系统无法处理这么多请求，抛出大量错误时，就到了极限。

五、TPS与QPS对比

TPS(transaction per second)是单位时间内处理事务的数量，QPS(query per second)是单位时间内请求的数量。TPS代表一个事务的处理，可以包含了多次请求。很多公司用QPS作为接口吞吐量的指标，也有很多公司使用TPS作为标准，两者都能表现出系统的吞吐量的大小，TPS的一次事务代表一次用户操作到服务器返回结果，QPS的一次请求代表一个接口的一次请求到服务器返回结果。当一次用户操作只包含一个请求接口时，TPS和QPS没有区别。当用户的一次操作包含了多个服务请求时，这个时候TPS作为这次用户操作的性能指标就更具有代表性了。

六、cpu利用率和系统负载

系统负载代表单位时间内正在运行或等待的进程或线程数，代表了系统的繁忙程度，CPU利用率则代表单位时间内一个线程或进程实时占用CPU的百分比。我们知道，一个进程或者线程在运行时，未必都在实时的利用CPU的。

比如，在CPU密集型的情况下，系统的负载未必会高，但CPU的利用率肯定会高，一个线程/进程一直在计算，它对CPU的实时利用率是100%，而系统负载是0.1;

又比如，而对于I/O密集型的程序来说，有可能CPU的利用率不高，但系统的负载却会非常高，这是因为I/O经常引起阻塞，这样导致很多线程/进程被处于阻塞等待状态，处于等待的线程或进程也是属于负载线程/进程的。

七、抛出异常需要构建异常栈，对异常进行捕获和处理，这个过程比较消耗系统的性能，怎么理解，为什么这个过程消耗性能？

创建异常对象时，会调用父类的Throwable的fillStackTrace()方法生成栈追踪信息，也就是调用native的fillStakTrace()方法去爬取线程堆栈信息，为运行时栈做一份快照，正是这一部分开销很大。所以平时的业务异常避免生吃栈追踪信息，在异常中用字符串描述业务异常信息即可，平时的业务异常可以自己实现自定义异常，继承RuntimeException，然后将writableStackTrace设置为false。

以下是RuntimeException的构造函数：

protected RuntimeException(String message, Throwable cause,
boolean enableSuppression,
boolean writableStackTrace) {
super(message, cause, enableSuppression, writableStackTrace);
}

。而系统异常，一般都会生成堆栈追踪信息，以便追踪源头，更好的排查问题。