性能调优 -- 哪些计算机资源有可能成为系统的性能瓶颈？

Posted 2021-03-25 yzh-blog

• 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内部锁已经做了多次优化，比如：新增了偏向锁、自旋锁、轻量级锁、锁粗化、锁消除等。如何合理地使用锁资源，也是性能优化时需要注意的一点。

• 响应时间　　

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

1. 数据库响应时间：数据库操作所消耗的时间，往往是整个请求链中最耗时的；
2. 服务端响应时间：服务端包括nginx分发的请求所消耗的时间以及服务端程序执行所消耗的时间；
3. 网络响应时间：这是网络传输时，网络硬件需要对传输的请求进行解析等操作所消耗的时间；
4. 客户端响应时间：对于普通的Web、App客户端来说，消耗时间是可以忽略不计的，但如果你的客户端嵌入了大量的逻辑处理，消耗的时间就有可能变长，从而成为系统的瓶颈。

• 吞吐量

　　在测试中，我们往往会比较注重系统接口的TPS(每秒事务处理量)，因为TPS体现了接口的性能，TPS越大，性能越好。在系统中，我们也可以把吞吐量自下而上地分为两种：磁盘吞吐量和网络吞吐量