Java应用的性能调优实战实践

Myth丶恋晨 2024-03-26 13:28 67阅读 0赞

Java 应用性能优化是一个老生常谈的话题，典型的性能问题如页面响应慢、接口超时，服务器负载高、并发数低，数据库频繁死锁等。尤其是在“糙快猛”的互联网开发模式大行其道的今天，随着系统访问量的日益增加和代码的臃肿，各种性能问题开始纷至沓来。 Java 应用性能的瓶颈点非常多，比如磁盘、内存、网络 I/O 等系统因素，Java 应用代码，JVM GC，数据库，缓存等。笔者根据个人经验，将 Java 性能优化分为 4 个层级：应用层、数据库层、框架层、JVM 层，如图 1 所示。 图 1.Java 性能优化分层模型

![format_png][]

每层优化难度逐级增加，涉及的知识和解决的问题也会不同。比如应用层需要理解代码逻辑，通过 Java 线程栈定位有问题代码行等；数据库层面需要分析 SQL、定位死锁等；框架层需要懂源代码，理解框架机制；JVM 层需要对 GC 的类型和工作机制有深入了解，对各种 JVM 参数作用了然于胸。 围绕 Java 性能优化，有两种最基本的分析方法：现场分析法和事后分析法。 现场分析法通过保留现场，再采用诊断工具分析定位。现场分析对线上影响较大，部分场景（特别是涉及到用户关键的在线业务时）不太合适。 事后分析法需要尽可能多收集现场数据，然后立即恢复服务，同时针对收集的现场数据进行事后分析和复现。下面我们从性能诊断工具出发，分享一些案例与实践。 1性能诊断工具 性能诊断一种是针对已经确定有性能问题的系统和代码进行诊断，还有一种是对预上线系统提前性能测试，确定性能是否符合上线要求。 本文主要针对前者，后者可以用各种性能压测工具（例如 JMeter）进行测试，不在本文讨论范围内。 针对 Java 应用，性能诊断工具主要分为两层：OS 层面和 Java 应用层面（包括应用代码诊断和 GC 诊断）。 OS 诊断 OS 的诊断主要关注的是 CPU、Memory、I/O 三个方面。 2 CPU 诊断 对于 CPU 主要关注平均负载（Load Average），CPU 使用率，上下文切换次数（Context Switch）。 通过 top 命令可以查看系统平均负载和 CPU 使用率，图 2 为通过 top 命令查看某系统的状态。 图 2.top 命令示例

![format_png 1][]

平均负载有三个数字：63.66，58.39，57.18，分别表示过去 1 分钟、5 分钟、15 分钟机器的负载。按照经验，若数值小于 0.7\*CPU 个数，则系统工作正常；若超过这个值，甚至达到 CPU 核数的四五倍，则系统的负载就明显偏高。 图 2 中 15 分钟负载已经高达 57.18，1 分钟负载是 63.66（系统为 16 核），说明系统出现负载问题，且存在进一步升高趋势，需要定位具体原因了。 通过 vmstat 命令可以查看 CPU 的上下文切换次数，如图 3 所示： 图 3.vmstat 命令示例

![format_png 2][]

上下文切换次数发生的场景主要有如下几种：

*  1）时间片用完，CPU 正常调度下一个任务；
 *  2）被其它优先级更高的任务抢占；
 *  3）执行任务碰到 I/O 阻塞，挂起当前任务，切换到下一个任务；
 *  4）用户代码主动挂起当前任务让出 CPU；
 *  5）多任务抢占资源，由于没有抢到被挂起；
 *  6）硬件中断。

Java 线程上下文切换主要来自共享资源的竞争。一般单个对象加锁很少成为系统瓶颈，除非锁粒度过大。但在一个访问频度高，对多个对象连续加锁的代码块中就可能出现大量上下文切换，成为系统瓶颈。 比如在我们系统中就曾出现 log4j 1.x 在较大并发下大量打印日志，出现频繁上下文切换，大量线程阻塞，导致系统吞吐量大降的情况，其相关代码如清单 1 所示，升级到 log4j 2.x 才解决这个问题。 for(Category c = this; c != null; c=c.parent) \{ //

[format_png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/ae85df9d0e5d4e7b882482bf1a7e4324.png
[format_png 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/e1fb0cc293354eb4a2a3609183c230b1.png
[format_png 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/adb2c4cc362145d9b98e070159d13fed.png