Java性能调优实战 --- 亿级流量系列 --- 掘金 --- author : 树下搜胡正则表达式

本文主要说明经过服务部署看性能是否提高的实践试验方法算法

若有须要，能够参考数据库

若有帮助，不忘点赞 ❥编程

微信公众号已开启，cto联盟，没关注的同窗们记得关注哦！设计模式

前几天跟某互联网主题旅游网架构师聊起性能调优的话题，那个时候正好遇到一些线上调优的一些困惑，但愿一块儿探讨一下。缓存

他跟我说，他们公司的系统历来没有通过性能调优，功能测试完成后就上线了，线上也没有出现过什么性能问题呀，为何要进行调优呢？？性能优化

可谓底气十足啊！！！无知者无畏啊；就不怕为公司埋雷，到时候追究他的责任？微信

当时我一脸懵逼，既然不作性能优化就直接上线，至关于给系统埋了一个定时炸弹，一旦到某个临界点，说炸就炸，到时候回天乏力；markdown

所以我就回答了他一句，“我去，若是大家公司作的是淘宝，京东，12306 这样的网站，不作系统性能优化就上线，试试看会是什么状况”。网络

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

一、为何要作性能调优？

在互联网项目开发中，老是不断针对新的需求去研发新的系统，而不少系统的设计都是能够举一反三的，在系统架构设计中，咱们必须遵循一些原则：

海恩法则

· 事故的发生是量的积累的结果（并发量，数据量，服务量…….）

· 再好的技术、再完美的规章，在实际操做层面也没法取代人自身的素质和责任心。

墨菲定律

· 任何事情都没有表面看起来那么简单。

· 全部事情的发展都会比你预计的时间长。

· 会出错的事总会出错。

· 若是你担忧某种状况发生，那么它更有可能发生。

这些原则警示咱们，在互联网公司里，对生产环境发生的任何怪异现象和问题都不要轻易忽视，对于其背后的缘由必定要彻查。

一样，海恩法则也强调任何严重事故的背后都是屡次小问题的积累，积累到必定的量级后会致使质变，严重的问题就会浮出水面。

那么，咱们须要对线上服务产生的任何征兆，哪怕是一个小问题，也要刨根问底: 这就须要咱们有技术攻关的能力，对任何现象都要秉着如下原则： 为何发生？ 发生了怎么应对？ 怎么恢复？ 怎么避免？ 对问题要彻查，不能由于问题的现象不明显而忽略 。
复制代码

一款线上产品若是没有通过性能测试，那它就比如是一颗定时炸弹，你不知道它何时会出现问题，你也不清楚它能承受的极限在哪儿，性能测试的目的在于验证软件系统是否可以达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，以优化软件。

有些性能问题是时间累积慢慢产生的，到了必定时间天然就爆炸了；而更多的性能问题是由访问量的波动致使的，例如，活动或者公司产品用户量上升；固然也有多是一款产品上线后就半死不活，一直没有大访问量，因此尚未引起这颗定时炸弹。

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

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

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

2、何时开始介入调优？

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

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

咱们只须要在代码层面保证有效的编码，同时在架构层面作好设计便可，具体架构设计能够参考以下几条行之有效的法则；

（1）系统的架构设计，如何在架构层面减小没必要要的处理（网络请求，数据库操做等）例如：使用Cache来减小IO次数，使用异步来增长单服务吞吐量，使用无锁数据结构来减小响应时间；
   
   （2）网络拓扑优化减小网络请求时间、如何设计拓扑结构，分布式如何实现？
   
   （3）系统代码级别的代码优化，使用什么设计模式来进行工做？哪些类须要使用单例，哪些须要尽可能减小new操做？
   
   （4）提升代码层面的运行效率、如何选取合适的数据结构进行数据存取？如何设计合适的算法？
   
   （5）任务执行方式级别的同异步操做，在哪里使用同步，哪里使用异步？
   
   （6）JVM调优，如何设置Heap、Stack、Eden的大小，如何选择GC策略,控制Full GC的频率？
   
   （7）服务端调优（线程池，等待队列）
   
   （8）数据库优化减小查询修改时间。数据库的选取？数据库引擎的选取？数据库表结构的设计？数据库索引、触发器等设计？是否使用读写分离？仍是须要考虑使用数据仓库？
   
   （9）缓存数据库的使用，如何选择缓存数据库？是Redis仍是Memcache? 如何设计缓存机制？
   
   （10）数据通讯问题，如何选择通讯方式？是使用TCP仍是UDP，是使用长链接仍是短链接？NIO仍是BIO？netty、mina仍是原生socket？
   
   （11）操做系统选取，是使用winserver仍是Linux？或者Unix？
   
   （12）硬件配置？是8G内存仍是32G，网卡10G仍是1G? 例如：增长CPU核数如32核，升级更好的网卡如万兆，升级更好的硬盘如SSD，扩充硬盘容量如2T，扩充系统内存如128G；
复制代码

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

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

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

在咱们进行调优以前，必须对性能指标有必定的认知，不然咱们调优就是空中楼阁，没有任何的可参考的依据；是没法实现调优的；

在咱们了解性能指标以前，咱们先来了解下哪些计算机资源会成为系统的性能瓶颈，这些东西各位应该都很是清楚，在系统上线后，无外乎就是 CPU、内存、磁盘、网络等等这些问题；

CPU：有的应用须要大量计算，他们会长时间、不间断地占用 CPU 资源，致使其余资源没法争夺到 CPU 而响应缓慢，从而带来系统性能问题。

例如，代码递归致使的无限循环，正则表达式引发的回溯，JVM 频繁的 FULL GC，以及多线程编程形成的大量上下文切换等，这些都有可能致使 CPU 资源繁忙。

大量线程抢占CPU资源，致使cpu占用率升高\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 越大，性能越好。在系统中，咱们也能够把吞吐量自下而上地分为两种：磁盘吞吐量和网络吞吐量。

咱们先来看磁盘吞吐量，磁盘性能有两个关键衡量指标。

一种是 IOPS（Input/Output Per Second），即每秒的输入输出量（或读写次数），这种是指单位时间内系统能处理的 I/O 请求数量，I/O 请求一般为读或写数据操做请求，关注的是随机读写性能。适应于随机读写频繁的应用。

另外一种是数据吞吐量，这种是指单位时间内能够成功传输的数据量。对于大量顺序读写频繁的应用，传输大量连续数据；

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

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

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

四、负载承受能力

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

亿级流量系列-如何制定调优的标准