在实时应用程序无法满足非功能性要求（例如性能、吞吐量和响应时间）时对其进行故障排除？这就是为什么每个 DevOps 团队都应该有一个明确的 Java 性能优化策略来帮助识别和解决 JVM 性能问题。
但是，在你说你遇到了 Java 性能问题之前，你必须首先确认你不希望你的应用程序的性能超出系统的最大容量。你当前的硬件实际上可以实现什么类型的性能？如果你的 JVM 性能目标超出了底层服务器的能力，那么 Java 代码优化将毫无用处。
系统容量基准
开发人员不太可能知道托管其应用程序的服务器的确切性能。但是你通常可以找到与你在生产中使用的系统相似的系统的已发布基准。
找出你自己的服务器落在该范围内的哪个位置，并查看你的生产系统与已建立的性能基准有多接近。如果你的应用程序执行低于既定基准，Java 性能优化是可能的。尽管如此，仅仅因为可以优化并不一定意味着你应该这样做。
JVM 性能目标
在 Java 性能优化上投入时间的触发因素不是你是否充分利用每个时钟周期的滴答声，相反，看看你是否能够达到绩效目标。DevOps 团队不应该把时间花在充分利用每个时钟周期滴答声上。仅当你当前的性能目标未达到时，你才应该投资于Java 性能优化。
每个应用程序都应该有明确的性能基准，最长可接受的响应时间是多少？每秒应该处理多少事务？应用程序必须能够处理的最大吞吐量是多少？
应用程序的性能宣言可能包括如下语句：
该应用程序将支持每秒 500 个事务。
页面加载时间将少于两秒。
故障转移在不到五秒的时间内发生。
99% 的事务发生在不到 40 毫秒 (ms) 的时间内。
无状态响应时间平均为 50 毫秒。
有状态的响应时间平均为 500 毫秒。
Java CPU 使用率不会超过连续两分钟超过 50% 的使用率。
如果你的应用程序的性能低于系统的既定基准，并且你的性能基准处于被破坏的危险之中，那么你可以开始调查如何优化 Java 性能。
Java 性能优化指南
大多数 Java 性能问题可归因于以下四种共享资源之一：中央处理器、记忆、输入输出操作、线程。
Java 分析器（例如 Java Flight Recorder）可以帮助立即识别应用程序中的瓶颈。使用 Java Mission Control 调查飞行记录，特别注意以下指标：CPU 利用率、系统上下文切换、物理内存利用率、随时间的堆消耗、使用的网络带宽、磁盘 I/O 延迟、数据库锁、SQL 延迟、垃圾收集频率、垃圾收集暂停时间、线程争用、线程暂停、线程锁。
Java 性能优化目标
一旦你知道哪个共享资源会导致 JVM 性能问题，请检查堆栈跟踪以在性能问题发生时识别活动的 Java 类和方法。百分之八十的情况下，当你执行以下操作时，可以实现 Java 性能优化：
使用更快的数据库查询；
识别并修复内存泄漏；
优化垃圾收集程序；
解决线程锁和并发问题；
修复应用程序中低效的代码；
使用正确的集合类进行列表处理。
一旦你确定了导致性能下降的软件组件，就由开发团队来确定 Java 代码优化任务的优先级。
代码更改、错误修复、迭代更新和性能测试例程最终会产生一个性能补丁，该补丁将修复瓶颈、优化应用程序并使 JVM 性能重新符合你组织的既定目标。
解决性能问题从来都不是一项有趣的任务。但是，有了有效的 Java 性能优化指南，注意什么是可能的，性能目标是什么，并着眼于当瓶颈出现时如何识别瓶颈，Java 性能优化的工作变得容易得多。
发表评论 取消回复