【Java程序性能优化 第一版】第一章

1.1 性能概述

  1.1.1看懂程序的性能

    对客户端程序而言， 拙劣的性能会严重影响用户体验。 界面停顿， 抖动， 响应延迟等问题会遭到用户的抱怨。 一个典型的例子就是Eclipse IDE工具的Full GC时会出现程序假死现象，相信一定被不少开发人员所诟病。对于服务器程序来说， 性能问题则更为重要， 相信不少后台服务器软件都有各自的性能目标。以Web服务器为例，服务器的响应时间，吞吐量就是两个重要的性能参数。当服务器承受巨大的压力时，可能出现响应时间边长， 吞吐量下降， 甚至是抛出内存溢出异常而崩溃。这些问题，都是性能调优需要解决的。

     一般来说，程序的性能通过一下几个方面来表现：

     □执行速度：程序的反应是否迅速，响应时间是否足够短。

     □内存分配：内存分配是否合理，是否过多消耗内存或者存在内存泄露。

     □启动时间：程序从运行到可以正常处理业务需要花费多长时间。

     □负载承受能力：当系统压力上升时，系统的执行速度，响应时间的上升曲线是否平缓。

 

1.1.2

    为了能够科学地进行性能分析，对性能指标进行定量评测是非常重要的。目前，一些可以用于定量评测的性能指标有：

     □执行时间：一段代码从开始运行到运行结束，所使用的时间。

     □CPU时间：函数或者线程占用CPU的时间。

     □内存分配：程序在运行时占用的内存空间。

     □磁盘吞吐量：描述1/O的使用情况。

     □网络吞吐量：描述网络的使用情况。

     □响应时间：系统对某用户行为或者事件做出响应的时间。响应的时间越短，性能越好。

1.1.3 木桶原理，顾名思义，就是短板

    将这个理论应用到系统性能优化上，可以这么理解，即使系统拥有充足的内存资源和CPU资源，但是如果磁盘的I/O性能低下，那么系统的总体性能是取决于当前最慢的磁盘I/O速度，而不是最快的CPU或者内存。在这种情况下，如果需要进一步提升系统性能，就必须从磁盘I/O 着手，因为此时，它就是性能瓶颈。

   根据应用的特点的不同，任何计算机资源都有可能成为系统瓶颈。其中，最有可能成为系统瓶颈的计算资源如下：

    □磁盘I/O：由于磁盘I/O读写速度要比内存慢很多，程序在运行过程中， 如果需要等待磁盘I/O完成，那么低效的I/O操作会拖累整个系统。

    □网络操作：对网络数据进行读写的情况与磁盘I/O类似。由于网络环境的不确定性。尤其是对互联网上数据的读写，网络操作的速度可能比本地磁盘I/O更慢。因此，如不加特殊处理，也极可能成为系统瓶颈。

    □CPU：对计算资源要求较高的应用，由于其长时间，不间断地大量占用CPU资源，那么对它的争夺将导致性能问题。如科学计算，3D渲染等对CPU需求旺盛的应用。

    □异常：对Java应用来说，异常捕获和处理都是非常消耗资源的。如果程序高频率地进行异常处理，则整体性能便会有明显下降。

    □数据库：大部分应用程序都离不开数据库，而海量数据的读写操作可能是相当费时的。而应用程序可能需要等待数据库操作完成或者返回请求的结果集，那么缓慢的同步操作将成为系统瓶颈。

    □锁竞争：对高并发程序来说，如果存在激烈的锁竞争，无疑是对性能极大的打击。锁竞争将会明显增加线程上下文切换的开销。而且，这些开销都是与应用需求无关的系统开销，白白占用宝贵的CPU资源，却不带来任何好处。

    □ 内存：一般来说，只要应用程序设计合理，内存在读写速度上不太可能成为性能瓶颈。除非应用程序进行了高频率的内存交换和扫描，但这些情况比较少见。使内存制约系统性能的最可能的情况是内存大小不足。与磁盘相比，内存的大小似乎小的可怜，这意味着应用软件只能尽可能将常用的核心数据读入内存，这在一定程度上降低了系统性能。 

1.1.4Amdahl定律

    首先获取加速比：定义如下： 加速比 = 优化前的系统耗时 / 优化后的系统耗时，加速比数值越高，表明优化效果越明显。

    Amdahl定律给出了加速比与系统并行度和处理器数量的关系。设加速比为Speedup,系统内必须串行化的程序比重为F,CPU的处理器数量为N，则有  speedup <= 1 / (F + (1-F)/N)

  根据这个公式，如果cpu处理器数量趋于无穷，那么加速比与系统的串行化率成反比，如果系统中必须有50%的代码串行执行，那么系统的最大加速比为2。

 

1.2 性能调优的层次

1.2.1设计调优

    设计调优处于所有调优手段的上层，它往往需要在软件开发之前进行。在软件开发之初，软件架构师评估系统可能存在的各种潜在问题，并给出合理的设计方案。由于软件设计和架构对整体质量有决定性的影响，所以，设计调优对系统性能的影响也是最大的。如果说，代码优化，JVM优化都是对系统微观层面上“量”的优化，那么设计优化就是对系统在宏观层面上“质”的变化。

1.2.2代码优化

    代码条有是在软件开发过程中，或者在软件开发完成后，软件维护过程中进行的对程序的改进和优化。代码优化涉及诸多编码技巧，需要开发人员熟悉相关语言的API，并在合适的场景中正确使用相关的API或类库。同时，对算法，数据结构的灵活使用，也是代码优化的重要内容。

    虽然代码优化是微观上对性能进行调整，但是一个好的实现和一个坏的实现对系统的影响也是非常打的。比如，同样做为List的实现，LinkedList和ArrayList在随机访问上的性能却可以相差几个数量级；又如，同样是文件读写的实现，使用Stream方式与NIO的方式，其性能可能又会相差一个数量级。

    因此，虽然与设计优化相比，笔者将代码优化称为在微观层面上的优化，但是他却是对系统性能产生最直接影响的优化方法。

1.2.3JVM调优

   由于java软件总是运行在JVM虚拟机上，对JVM虚拟机进行优化也能在一定程度上提升java程序的性能。JVM调优通常可以在软件开发后期进行，如在软件开发完成，或者在软件开发的某一里程碑阶段。

   做为Java软件的运行平台， JVM的各项参数将会直接影响Java程序的性能。比如，JVM的堆大小， 垃圾回收策略等。

   要进行JVM层面的调优，需要开发人员对JVM的运行原理和基本内存结构有一定了解。如堆内存的结构，GC的种类等。然后，依据应用程序的特点，设置合理的JVM启动参数。

 1.2.4数据库调优  （待完善..）

 1.2.5操作系统调优 （待完善..）