对于 Java 性能比较关心的同学大概都知道《Java Performance》这本书，一般而言，很多同学在日常写 Java Code 的时候很少去关心性能问题，但是在我们写 Code 的过程中必须考虑到性能对程序的影响。小到我们使用位运算来实现算术运算，大到我们对 Java 代码的总体架构设计，「性能」其实离我们很近。本篇文章主要提到几个点，希望能够对大家有所启发。

对于性能调优而言，通常我们需要经过以下三个步骤：1，性能监控；2，性能剖析；3，性能调优

作为国内在技术层面遥遥领先的 APM 厂商，One APM 的 Ai 产品对于 Java Application 性能优化提供了非常完善的指标：

性能监控：
影响 Java 性能多维度指标监控

性能剖析：
Application 性能剖析

性能调优：通过分析影响Application性能问题根源，进行优化Application；

我们对于操作系统的性能关注主要在下面几个点上：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」，这种场景经常会发生，比如在 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 密集型的，比如数据库。磁盘的使用通常还存在于应用日志系统，日志通常是我们用来记录系统运行过程中重要信息的。

OneAPM for Java 能够深入到所有 Java 应用内部完成应用性能管理和监控，包括代码级别性能问题的可见性、性能瓶颈的快速识别与追溯、真实用户体验监控、服务器监控和端到端的应用性能管理。想技术文章，请访问 OneAPM 官方博客。