Java性能实战1

认识性能

所谓性能，就是使用有限的资源在有限的时间内完成工作。最主要的衡量因素就是时间，所以很多衡量指标，都可以把时间作为横轴。

加载缓慢的网站，会受到搜索排名算法的惩罚，从而导致网站排名下降。 因此加载的快慢是性能优化是否合理的一个非常直观的判断因素，但性能指标不仅仅包括单次请求的速度，它还包含更多因素。

性能衡量指标

1. 吞吐量和响应速度
分布式的高并发应用并不能把单次请求作为判断依据，它往往是一个统计结果。其中最常用的衡量指标就是吞吐量和响应速度，而这两者也是考虑性能时非常重要的概念。要理解这两个指标的意义，我们可以类比为交通环境中的十字路口。

在交通非常繁忙的情况下，十字路口是典型的瓶颈点，当红绿灯放行时间非常长时，后面往往会排起长队。

从我们开车开始排队，到车经过红绿灯，这个过程所花费的时间，就是响应时间。

当然，我们可以适当地调低红绿灯的间隔时间，这样对于某些车辆来说，通过时间可能会短一些。但是，如果信号灯频繁切换，反而会导致单位时间内通过的车辆减少，换一个角度，我们也可以认为这个十字路口的车辆吞吐量减少了。

像我们平常开发中经常提到的，QPS 代表每秒查询的数量，TPS 代表每秒事务的数量，HPS 代表每秒的 HTTP 请求数量等，这都是常用的与吞吐量相关的量化指标。

在性能优化的时候，我们要搞清楚优化的目标，到底是吞吐量还是响应速度。 有些时候，虽然响应速度比较慢，但整个吞吐量却非常高，比如一些数据库的批量操作、一些缓冲区的合并等。虽然信息的延迟增加了，但如果我们的目标就是吞吐量，那么这显然也可以算是比较大的性能提升。

一般情况下，我们认为：

响应速度是串行执行的优化，通过优化执行步骤解决问题；

吞吐量是并行执行的优化，通过合理利用计算资源达到目标。

我们平常的优化主要侧重于响应速度，因为一旦响应速度提升了，那么整个吞吐量自然也会跟着提升。

**但对于高并发的互联网应用来说，响应速度和吞吐量两者都需要。**这些应用都会标榜为高吞吐、高并发的场景，用户对系统的延迟忍耐度很差，我们需要使用有限的硬件资源，从中找到一个平衡点。

2. 响应时间衡量

既然响应时间这么重要，我们就着重看一下响应时间的衡量方法。

（1）平均响应时间

我们最常用的指标，即平均响应时间(AVG)，该指标能够体现服务接口的平均处理能力。它的本质是把所有的请求耗时加起来，然后除以请求的次数。举个最简单的例子，有 10 个请求，其中有 2 个 1ms、3 个 5ms、5 个 10ms，那么它的平均耗时就是(21+35+5*10)/10=6.7ms。

除非服务在一段时间内出现了严重的问题，否则平均响应时间都会比较平缓。因为高并发应用请求量都特别大，所以长尾请求的影响会被很快平均，导致很多用户的请求变慢，但这不能体现在平均耗时指标中。

为了解决这个问题，另外一个比较常用的指标，就是百分位数(Percentile)。

3. 并发量

并发量是指系统同时能处理的请求数量，这个指标反映了系统的负载能力。

在高并发应用中，仅仅高吞吐是不够的，它还必须同时能为多个用户提供服务。并发高时，会导致很严重的共享资源争用问题，我们需要减少资源冲突，以及长时间占用资源的行为。

针对响应时间进行设计，一般来说是万能的。因为响应时间减少，同一时间能够处理的请求必然会增加。值得注意的是，即使是一个秒杀系统，经过层层过滤处理，最终到达某个节点的并发数，大概也就五六十左右。我们在平常的设计中，除非并发量特别低，否则都不需要太过度关注这个指标。

4. 秒开率

在移动互联网时代，尤其对于 App 中的页面，秒开是一种极佳的用户体验。如果能在 1 秒内加载完成页面，那用户可以获得流畅的体验，并且不会产生更多的焦虑感。

通常而言，可以根据业务情况设定不同的页面打开标准，比如低于 1 秒内的数据占比是秒开率。业界优秀的公司，比如手淘，其页面的秒开率基本可达到 80% 以上。

5. 正确性

说一个比较有意思的事情。我们有个技术团队，在进行测试的时候，发现接口响应非常流畅，把并发数增加到 20 以后，应用接口响应依旧非常迅速。

但等应用真正上线时，却发生了重大事故，这是因为接口返回的都是无法使用的数据。

其问题原因也比较好定位，就是项目中使用了熔断。在压测的时候，接口直接超出服务能力，触发熔断了，但是压测并没有对接口响应的正确性做判断，造成了非常低级的错误。