这篇文章节选自《java performance》，对java性能比较关心的同学大概都知道这本书，性能这个东西可能是很多同学在日常写java code的时候很少去关心的，但是在我们写code的过程中确又时时离不开对程序性能的影响，小到我们使用位运算来实现算术运算，大到我们对JAVA代码的总体架构设计，性能其实离我们很近。本片文章主要提到几个点，主要是在性能领域我们比较关注的一些问题，并且是有启发性的，如果同学对性能较感兴趣，那么我们可以一起深入研究各个点。
对于性能调优，通常会有三个步骤：1，性能监控；2，性能剖析；3，性能调优
我们对于操作系统的性能关注主要在下面几个点上：CPU利用率、CPU调度执行队列、内存利用率、网络I/O、磁盘I/O。
1.CPU利用率
对于一个应用来说，为了让应用达到最好的性能和可扩展性，我们不仅仅要充分利用CPU周期内可用的部分，而且要让这部分CPU的使用更有价值，而不是浪费。能够让CPU的周期利用的更充分对于多线程应用运行在多处理器和多核系统上至很有挑战性的。另外，当CPU达到饱和状态的时候并不能说明CPU的性能和伸缩性已经达到了最佳的状态。为了区分应用是如何利用CPU资源的，我们必须从操作系统级别来检测。在很多操作系统上，CPU的利用率统计报告通常包括用户和系统或内核对操作系统的使用。用户对CPU的使用是指应用用来执行应用代码执行所需要的时间。相比之下，内核和系统对CPU的使用是指应用用来执行操作系统内核代码锁花费的时间。高的内核或者系统CPU使用率可以表明共享资源紧迫，或者是有大量的I/O设备交互。理想的状态为了提高应用的性能和伸缩性，让内核或系统CPU时间为0%，因为花在执行内核或系统代码的时间是可以用来执行应用代码的。因此CPU使用优化的一个正确方向就是尽可能减少CPU花在执行内核代码或者系统代码上的时间。
对于计算密集型应用，性能监控比监测用户CPU使用和内核或系统CPU使用要更深层次，在计算密集型应用中，我们需要监测CPU时钟周期内的执行执行条数（Instructions per clock；IPC）或者是每条CPU执行所使用的CPU周期（cycles per instruction；CPI）。对于计算密集型应用来说我们从这两个维度来监测CPU是不错的选择，因为现代操作系统的打包CPU性能报告工具通常只会打印CPU的利用率，而不会打印CPU周期内CPU用来执行指令的时间。这意味着当CPU正在等待内存中的数据的时候，操作系统CPU性能报告工具也会认为CPU是正在使用的状态，我们把这个场景叫做“Stall”，“Stall”场景经常会发生，比如在CPU正在执行指令的任何时候，只要是指令需要的数据没有准备好，也就是没有在寄存器或者CPU缓存内，都会发生“Stall”场景。
当“Stall”场景发生的时候CPU会浪费时钟周期，因为CPU必须要等待指令需要的数据到达寄存器或者缓冲器。而且在这个场景中，数百个CPU时钟周期被浪费是很正常的事情，因此在计算密集型应用中，提高性能的策略是减少“Stall”场景的发生或者是增强CPU的缓存使用从而使得更少的CPU周期因为等待数据而浪费掉。这类的性能监控知识已经超越了本书的内容，需要性能专家的帮助了。然而，后面讲到的Oracle Solaris Studio Performance Analyzer这种性能剖析工具将会包括此类数据。
2.CPU调度队列
除了对CPU使用的监控，我们也可以通过监控CPU执行队列来检查系统是否已经满负载。执行队列是用来存储轻量级进程，这些进程通常是已经准备好执行了但是正在等待CPU调度而在调度队列等待的一种状态，当轻量级进程别当前处理器能来得及处理的数量更多的时候，调度队列将会产生。比较深的CPU调度队列表明系统已经满负荷了。系统的执行队列深度等于虚拟处理器执行不了的等待数，虚拟处理器数等于系统的硬件线程数。我们可以用java的api来拿到虚拟处理器数，Runtime.avaliableProcessors()。当执行队列深度大于虚拟处理器个数的四倍或更多的时候，操作系统将会出现反应迟钝的现象。
对于CPU调度队列的检测的一个通用指导是当我们发现队列深度高于虚拟进程数一倍的时候就要注意了，但是没有必要立即采取行动。当大于三倍或四倍或者更高的时候就要注意了，解决问题刻不容缓。
通常有两个可选的途径来观察队列的深度，第一个是通过增加CPU来分担负载或者减少对现有CPU的负载。这种途径从本质上减少了每个执行单元的负载线程数，从而减少执行执行队列的深度。
另外的一种途径是通过剖析系统运行的应用来增加CPU的使用率，换个说法就是寻找一种可以减少花费在垃圾回收上的CPU周期，或者寻找更好的算法来以更少的CPU周期来执行CPU指令。性能专家通常专注后面的一种途径:减少代码的执行路径长度和更好的CPU指令选择。JAVA程序员可以通过更好的执行算法和数据结构来提高代码的执行效率。
3.内存利用率
除了CPU的使用率，系统的内存属性也需要被监控，这些属性包括比如：分页、交换、锁、多线程引起的上下文交换等。
交换通常发生在当应用需要的内存大于实际的物理内存的时候，处理这种情况操作系统通常会配置一个相应的区域叫做交换区。交换区通常位于物理磁盘上，当物理内存内应用耗尽的时候，操作系统会将一部分内存数据暂时交换到磁盘空间上，这部分内存区域通常是访问频率最低的一块区域，而不会影响比较“忙”的内存区域；当被交换到磁盘区域的内存又被应用访问的时候，这个时候就需要从磁盘交换区将以页为单位读入内存，交换会影响应用的性能。
虚拟机的垃圾收集器在交换的时候性能非常差，因为垃圾收集器所访问的大部分区域都是不可达的，也就是垃圾收集器会引起交换活动的发生。场景是戏剧性的，如果垃圾收集的堆区域已经被交换到了磁盘空间，这个时候将会以页为单位发生交换，这样才能够被垃圾收集器所扫描到，在交换的过程中会戏剧性的引发垃圾收集器的收集时间延长，这个时候如果垃圾收集器是“Stop The World”（使得应用响应停止）的，那么这个时间就会被延长。
4.网络I/O
分布式JAVA应用的性能和伸缩性会受到网络带宽和网络性能的限制。例如，如果我们往网络接口发送比他能够处理的更多的数据包，数据包将会堆积在操作系统的缓冲区内，这将会引发应用延迟，另外其他的情况也会导致网络应用的延迟。
区分和监控的工具通常在操作系统的打包工具中很难找到。尽管linux提供了netstat命令，linux和solaris都提供了网络使用情况的实现，他们都提供了包括每秒发包、接包、错包、冲突等信息的统计。在以太网中，一小部分包冲突是很正常的现象。如果错包情况比较多那可能是网卡有问题了。同时，尽管netstat可以统计网络接口的发送和接收数据情况，这很难断定网卡是否被充分利用。例如，如果netstat -i显示现在每秒有2500个包从网卡发出，但是我们仍然无法判断当前的网络利用率是100%还是1%，我们仅仅能够知道目前有流量。这仅仅是在不知道网络包大小的情况下能够得到的结论。简单的说我们无法通过linux和solaris提供的netstat来判断当前网络是否影响了性能。我们需要一些其他的工具在我们的JAVA应用运行的过程中来监测网络。
5.磁盘I/O
如果应用有对磁盘进行操作，我们需要对磁盘进行监控，来监测可能出现的磁盘性能问题。一些应用是I/O密集型的，比如数据库。磁盘的使用通常还存在于应用日志系统，日志通常是我们用来记录系统运行过程中重要信息的。