多应用+插件架构,代码干净,二开方便,首家独创一键云编译技术,文档视频完善,免费商用码云13.8K 广告
# 性能优化攻略 为什么程序总是那么慢?它现在到底在干什么?时间都花到哪去了?也许,你经常会抱怨这些问题。如果是这样,那说明你的程序出了性能问题。和功能性问题相比,性能问题在有些情况下,可能并不算太大的问题,将就将就,也就过去了。但是,严重的性能问题会导致程序瘫痪、假死,甚至崩溃。 ### 看懂程序的性能 **a.执行速度**   程序的反应是否迅速,响应时间是否足够短。 **b.内存分配**   内存分配是否合理,是否过多地消耗内存或者存在泄露。 **c.启动时间**    程序从运行到可以正常处理业务需要花费多少时间。 **d.负载承受能力**   当系统压力上升时,系统的执行速度、响应时间的上升曲线是否平缓。 ### 性能的参考指标 **a.执行时间**    一段代码从开始运行到运行结束,所使用的时间。 **b.CPU时间**    函数或者线程占用CPU的时间。 **c.内存分配**    程序在运行时占用的内存空间。 **d.磁盘吞吐量**    描述I/O的使用情况。 **e.网络吞吐量**    描述网络的使用情况。 **f.响应时间**    系统对某用户行为或者事件做出响应的时间。响应时间越短,性能越好。 ### 木桶原理与性能瓶颈 木桶原理又称“短板理论”,其核心思想是:一只木桶盛水的多少,并不取决于桶壁上最高的那块木块,而是取决于桶壁上最短的那块。 根据木桶原理,系统的最终性能瓶颈取决于系统中性能表现最差的组件。因此,为了提升系统整体性能,必须对系统中表现最差的组件进行优化,而不是对系统中表现良好的组件进行优化。 根据应用的特点不同,任何计算机资源都有可能成为系统瓶颈。其中,最有可能成为系统瓶颈的计算资源如下: **a.磁盘I/O** 由于磁盘I/O读写的速度要比内存慢很多,程序在运行过程中,如果需要等待磁盘I/O完成,那么低效的I/O操作会拖累整个系统。 **b.网络操作** 对网络数据进行读写的情况与磁盘I/O类似。由于网络环境的不确定性,尤其是互联网上数据的读写,网络操作的速度可能比本地磁盘I/O更慢。因此,如不加特殊处理,也极可能成为系统瓶颈。 **c.CPU** 对计算机资源要求较高的应用,由于其长时间、不间断地大量占用CPU资源,那么对CPU的争夺将导致性能问题。如科学计算、3D渲染等对CPU需求旺盛的应用。 **d.异常** 对Java应用来说,异常的捕获和处理是非常耗费资源的,如果程序高频率地进行异常处理,则整理性能便会有明显下降。 **e.数据库** 大部分应用程序都离不开数据库,而海量数据的读写操作操作可能是相当费时的。而应用程序可能需要等待数据库操作完成或者返回请求的结果集,那么缓存的同步操作将成为系统瓶颈。 **f.锁竞争** 对高并发程序来说,如果存在激烈的锁竞争,无疑是对性能极大的打击。锁竞争将会明显增加线程上下文切换的开销。而且,这些开销都是与应用需求无关的系统开销,白白占用宝贵的CPU资源,去不带来任何好处。 **g.内存** 一般来说,只要应用程序设计合理,内存在读写速度上不太可能成为系统瓶颈。除非应用程序进行了高频率的内存交换和扫描,但这些情况比较少见。使内存制约系统性能瓶颈的情况是内存大小不足。与磁盘相比,内存的大小似乎小的可怜,这意味着应用软件只能尽可能将常用的核心数据读入内存,这在一定程序上降低了系统性能。 ### Amadahl定律 Amadahl定律是计算机科学中非常重要的定律,它定义了串行系统并行化后加速比的计算公式和理论上限。 加速比定义:加速比=优化前系统耗时/优化后系统耗时 加速比越高,表明优化效果越明显。 Amadahl定律给出了加速比与系统并行度和处理器数量的关系。 设加速比为Speedup,系统内必须串行化的程序比重为F,CPU数量为N,则有: Speedup<= 1/ (F+ (1-F) /N) 根据这个公式,如果CPU数量趋于无穷,那么加速比与系统的串行化成反比。如果系统中必须有50%的代码穿行执行,那么系统的最大加速比是2。 ### 性能调优的层次 #### **a.设计调优** 设计调优处于所有调优手段的上层,它往往需要在软件开发之前进行。 设计优化的一大显著特点是,它可以规避某一个组件的性能问题,而非改良该组件的实现, 如果说,代码优化和JVM优化是对系统微观层面上“量”的优化,那么设计优化就是对系统在宏观层面上“质”的优化。 一个良好的系统设计可以规避很多潜在的性能问题。因此,尽可能多花时间在系统设计上,是创建高性能程序的关键。 #### **b.代码调优** 代码调优涉及诸多编码技巧,需要开发人员熟悉相关语言的API,并在合适的场景中正确使用相关API或类库。同时,对算法、数据结构的灵活运用。 虽然代码优化是从微观上对性能进行调整,但是一个“好”的实现和一个“坏”的实现对系统的影响还是很大的。比如同样作为List的实现,LinkedList和ArrayList在随机访问上的性能却可以相差几个数量级。 作为微观层面的优化,却是对系统性能产生直接影响的优化方法。 #### **c.JVM调优** 作为Java软件的运行平台,JVM的各项参数将会直接影响Java程序的性能。比如JVM堆的大小、垃圾回收策略。 #### **d.数据库调优** 可以分为3个部分: 在应用层对SQL语句进行优化; 对数据库进行优化,比如建立索引; 对数据库软件进行优化。 #### **e.操作系统调优** Windows,Linux。 最大文件句柄数、虚拟内存大小等系统参数对系统性能有影响。 ### 基本调优策略和手段 #### 优化的一般步骤 明确目标,通过性能监控和统计工具,观察和确认当前系统是否已经达到相关目标,若已经达到,则没有必要再优化;否则,查找当前的系统瓶颈,通过定位相关代码查找代码性能问题,其次考虑JVM层、数据库层或者操作系统。 考虑修改原有设计或者升级硬件也是一种方式。 ####系统优化注意事项 性能优化可能对软件功能、正确性和可维护性造成负面影响。 比如改进算法使得代码出现了新的Bug,使得代码更难懂。