大牛教你如何制定 Java 性能调优标准？

想让你的程序更快更稳，可是系统常常出各类 bug，无从下手？Java 性能调优全攻略来啦！

我有一个朋友，有一次他跟我说，他们公司的系统历来没有通过性能调优，功能测试完成后就上线了，线上也没有出现过什么性能问题呀，那为何不少系统都要去作性能调优呢？

当时我就回答了他一句，若是大家公司作的是 12306 网站，不作系统性能优化就上线，试试看会是什么状况。

若是是你，你会怎么回答呢？今天，咱们就从这个话题聊起，但愿能跟你一块儿弄明白这几个问题：咱们为何要作性能调优？何时开始作？作性能调优是否是有标准可参考？

为何要作性能调优？

一款线上产品若是没有通过性能测试，那它就比如是一颗定时炸弹，你不知道它何时会出现问题，你也不清楚它能承受的极限在哪儿。有些性能问题是时间累积慢慢产生的，到了必定时间天然就爆炸了；而更多的性能问题是由访问量的波动致使的，例如，活动或者公司产品用户量上升；固然也有多是一款产品上线后就半死不活，一直没有大访问量，因此尚未引起这颗定时炸弹。

如今假设你的系统要作一次活动，产品经理或者老板告诉你预计有几十万的用户访问量，询问系统可否承受得住此次活动的压力。若是你不清楚本身系统的性能状况，也只能战战兢兢地回答老板，有可能大概没问题吧。

因此，要不要作性能调优，这个问题其实很好回答。全部的系统在开发完以后，多多少少都会有性能问题，咱们首先要作的就是想办法把问题暴露出来，例如进行压力测试、模拟可能的操做场景等等，再经过性能调优去解决这些问题。

好比，当你在用某一款 App 查询某一条信息时，须要等待十几秒钟；在抢购活动中，没法进入活动页面等等。你看，系统响应就是体现系统性能最直接的一个参考因素。

那若是系统在线上没有出现响应问题，咱们是否是就不用去作性能优化了呢？再给你讲一个故事吧。

曾经个人前前东家系统研发部门来了一位大神，为何叫他大神，由于在他来公司的一年时间里，他只作了一件事情，就是把服务器的数量缩减到了原来的一半，系统的性能指标，反而还提高了。

好的系统性能调优不只仅能够提升系统的性能，还能为公司节省资源。这也是咱们作性能调优的最直接的目的。

何时开始介入调优？

解决了为何要作性能优化的问题，那么新的问题就来了：若是须要对系统作一次全面的性能监测和优化，咱们从何时开始介入性能调优呢？是否是越早介入越好？

其实，在项目开发的初期，咱们没有必要过于在乎性能优化，这样反而会让咱们疲于性能优化，不只不会给系统性能带来提高，还会影响到开发进度，甚至得到相反的效果，给系统带来新的问题。

咱们只须要在代码层面保证有效的编码，好比，减小磁盘 I/O 操做、下降竞争锁的使用以及使用高效的算法等等。遇到比较复杂的业务，咱们能够充分利用设计模式来优化业务代码。例如，设计商品价格的时候，每每会有不少折扣活动、红包活动，咱们能够用装饰模式去设计这个业务。

在系统编码完成以后，咱们就能够对系统进行性能测试了。这时候，产品经理通常会提供线上预期数据，咱们在提供的参考平台上进行压测，经过性能分析、统计工具来统计各项性能指标，看是否在预期范围以内。

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

Java架构/分布式：705127209（大牛交流群）没有开发经验勿加！

有哪些参考因素能够体现系统的性能？

上面咱们讲到了在项目研发的各个阶段性能调优是如何介入的，其中屡次讲到了性能指标，那么性能指标到底有哪些呢？

在咱们了解性能指标以前，咱们先来了解下哪些计算机资源会成为系统的性能瓶颈。

CPU：有的应用须要大量计算，他们会长时间、不间断地占用 CPU 资源，致使其余资源没法争夺到 CPU 而响应缓慢，从而带来系统性能问题。例如，代码递归致使的无限循环，正则表达式引发的回溯，JVM 频繁的 FULL GC，以及多线程编程形成的大量上下文切换等，这些都有可能致使 CPU 资源繁忙。

内存：Java 程序通常经过 JVM 对内存进行分配管理，主要是用 JVM 中的堆内存来存储 Java 建立的对象。系统堆内存的读写速度很是快，因此基本不存在读写性能瓶颈。可是因为内存成本要比磁盘高，相比磁盘，内存的存储空间又很是有限。因此当内存空间被占满，对象没法回收时，就会致使内存溢出、内存泄露等问题。

磁盘 I/O：磁盘相比内存来讲，存储空间要大不少，但磁盘 I/O 读写的速度要比内存慢，虽然目前引入的 SSD 固态硬盘已经有所优化，但仍然没法与内存的读写速度相提并论。网络：网络对于系统性能来讲，也起着相当重要的做用。若是你购买过云服务，必定经历过，选择网络带宽大小这一环节。带宽太低的话，对于传输数据比较大，或者是并发量比较大的系统，网络就很容易成为性能瓶颈。

异常：Java 应用中，抛出异常须要构建异常栈，对异常进行捕获和处理，这个过程很是消耗系统性能。若是在高并发的状况下引起异常，持续地进行异常处理，那么系统的性能就会明显地受到影响。

数据库：大部分系统都会用到数据库，而数据库的操做每每是涉及到磁盘 I/O 的读写。大量的数据库读写操做，会致使磁盘 I/O 性能瓶颈，进而致使数据库操做的延迟性。对于有大量数据库读写操做的系统来讲，数据库的性能优化是整个系统的核心。

锁竞争：在并发编程中，咱们常常会须要多个线程，共享读写操做同一个资源，这个时候为了保持数据的原子性（即保证这个共享资源在一个线程写的时候，不被另外一个线程修改），咱们就会用到锁。锁的使用可能会带来上下文切换，从而给系统带来性能开销。JDK1.6 以后，Java 为了下降锁竞争带来的上下文切换，对 JVM 内部锁已经作了屡次优化，例如，新增了偏向锁、自旋锁、轻量级锁、锁粗化、锁消除等。而如何合理地使用锁资源，优化锁资源，就须要你了解更多的操做系统知识、Java 多线程编程基础，积累项目经验，并结合实际场景去处理相关问题。

了解了上面这些基本内容，咱们能够获得下面几个指标，来衡量通常系统的性能。

一、响应时间

响应时间是衡量系统性能的重要指标之一，响应时间越短，性能越好，通常一个接口的响应时间是在毫秒级。在系统中，咱们能够把响应时间自下而上细分为如下几种：

数据库响应时间：数据库操做所消耗的时间，每每是整个请求链中最耗时的；

服务端响应时间：服务端包括 Nginx 分发的请求所消耗的时间以及服务端程序执行所消耗的时间；

网络响应时间：这是网络传输时，网络硬件须要对传输的请求进行解析等操做所消耗的时间；

客户端响应时间：对于普通的 Web、App 客户端来讲，消耗时间是能够忽略不计的，但若是你的客户端嵌入了大量的逻辑处理，消耗的时间就有可能变长，从而成为系统的瓶颈。

二、吞吐量

在测试中，咱们每每会比较注重系统接口的 TPS（每秒事务处理量），由于 TPS 体现了接口的性能，TPS 越大，性能越好。在系统中，咱们也能够把吞吐量自下而上地分为两种：磁盘吞吐量和网络吞吐量。咱们先来看磁盘吞吐量，磁盘性能有两个关键衡量指标。

接下来看网络吞吐量，这个是指网络传输时没有帧丢失的状况下，设备可以接受的最大数据速率。网络吞吐量不只仅跟带宽有关系，还跟 CPU 的处理能力、网卡、防火墙、外部接口以及 I/O 等等紧密关联。而吞吐量的大小主要由网卡的处理能力、内部程序算法以及带宽大小决定。

三、计算机资源分配使用率

一般由 CPU 占用率、内存使用率、磁盘 I/O、网络 I/O 来表示资源使用率。这几个参数比如一个木桶，若是其中任何一块木板出现短板，任何一项分配不合理，对整个系统性能的影响都是毁灭性的。

四、负载承受能力

当系统压力上升时，你能够观察，系统响应时间的上升曲线是否平缓。这项指标能直观地反馈给你，系统所能承受的负载压力极限。例如，当你对系统进行压测时，系统的响应时间会随着系统并发数的增长而延长，直到系统没法处理这么多请求，抛出大量错误时，就到了极限。

总结

经过今天的学习，咱们知道性能调优可使系统稳定，用户体验更佳，甚至在比较大的系统中，还能帮公司节约资源。

可是在项目的开始阶段，咱们没有必要过早地介入性能优化，只需在编码的时候保证其优秀、高效，以及良好的程序设计。

在完成项目后，咱们就能够进行系统测试了，咱们能够将如下性能指标，做为性能调优的标准，响应时间、吞吐量、计算机资源分配使用率、负载承受能力。

回顾我本身的项目经验，有电商系统、支付系统以及游戏充值计费系统，用户级都是千万级别，且要承受各类大型抢购活动，因此我对系统的性能要求很是苛刻。除了经过观察以上指标来肯定系统性能的好坏，还须要在更新迭代中，充分保障系统的稳定性。

这里，给你延伸一个方法，就是将迭代以前版本的系统性能指标做为参考标准，经过自动化性能测试，校验迭代发版以后的系统性能是否出现异常，这里就不只仅是比较吞吐量、响应时间、负载能力等直接指标了，还须要比较系统资源的 CPU 占用率、内存使用率、磁盘 I/O、网络 I/O 等几项间接指标的变化。