扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
本篇内容介绍了“如何对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 命令示例
平均负载有三个数字：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 命令示例
上下文切换次数发生的场景主要有如下几种：
1）时间片用完，CPU 正常调度下一个任务；
2）被其它优先级更高的任务抢占；
3）执行任务碰到 I/O 阻塞，挂起当前任务，切换到下一个任务；
4）用户代码主动挂起当前任务让出 CPU；
5）多任务抢占资源，由于没有抢到被挂起；
6）硬件中断。
Java 线程上下文切换主要来自共享资源的竞争。一般单个对象加锁很少成为系统瓶颈，除非锁粒度过大。但在一个访问频度高，对多个对象连续加锁的代码块中就可能出现大量上下文切换，成为系统瓶颈。
比如在我们系统中就曾出现 log4j 1.x 在较大并发下大量打印日志，出现频繁上下文切换，大量线程阻塞，导致系统吞吐量大降的情况，其相关代码如清单 1 所示，升级到 log4j 2.x 才解决这个问题。
for(Category c = this; c != null; cc=c.parent) { // Protected against simultaneous call to addAppender, removeAppender,… synchronized(c) { if (c.aai != null) { write += c.aai.appendLoopAppenders(event); } … } }3、Memory
从操作系统角度，内存关注应用进程是否足够，可以使用 free –m 命令查看内存的使用情况。
通过 top 命令可以查看进程使用的虚拟内存 VIRT 和物理内存 RES，根据公式 VIRT = SWAP + RES 可以推算出具体应用使用的交换分区（Swap）情况，使用交换分区过大会影响 Java 应用性能，可以将 swappiness 值调到尽可能小。
因为对于 Java 应用来说，占用太多交换分区可能会影响性能，毕竟磁盘性能比内存慢太多。
4、I/O
I/O 包括磁盘 I/O 和网络 I/O，一般情况下磁盘更容易出现 I/O 瓶颈。通过 iostat 可以查看磁盘的读写情况，通过 CPU 的 I/O wait 可以看出磁盘 I/O 是否正常。
如果磁盘 I/O 一直处于很高的状态，说明磁盘太慢或故障，成为了性能瓶颈，需要进行应用优化或者磁盘更换。
除了常用的 top、 ps、vmstat、iostat 等命令，还有其他 Linux 工具可以诊断系统问题，如 mpstat、tcpdump、netstat、pidstat、sar 等。Brendan 总结列出了 Linux 不同设备类型的性能诊断工具，如图 4 所示，可供参考。
图 4.Linux 性能观测工具
5、Java 应用诊断及工具
应用代码性能问题是相对好解决的一类性能问题。通过一些应用层面监控报警，如果确定有问题的功能和代码，直接通过代码就可以定位；或者通过 top+jstack，找出有问题的线程栈，定位到问题线程的代码上，也可以发现问题。对于更复杂，逻辑更多的代码段，通过 Stopwatch 打印性能日志往往也可以定位大多数应用代码性能问题。
常用的 Java 应用诊断包括线程、堆栈、GC 等方面的诊断。之前分享了一份JVM 46页的干货资料，关注微信公众号：Java技术栈，在后台回复：jvm46，即可领取。见这里：46张PPT弄懂JVM、GC算法和性能调优。
jstack
jstack 命令通常配合 top 使用，通过 top -H -p pid 定位 Java 进程和线程，再利用 jstack -l pid 导出线程栈。由于线程栈是瞬态的，因此需要多次 dump，一般 3 次 dump，一般每次隔 5s 就行。将 top 定位的 Java 线程 pid 转成 16 进制，得到 Java 线程栈中的 nid，可以找到对应的问题线程栈。
图 5. 通过 top –H -p 查看运行时间较长 Java 线程
如图 5 所示，其中的线程 24985 运行时间较长，可能存在问题，转成 16 进制后，通过 Java 线程栈找到对应线程 0x6199 的栈如下，从而定位问题点，如图 6 所示。
图 6.jstack 查看线程堆栈
JProfiler
JProfiler 可对 CPU、堆、内存进行分析，功能强大，如图 7 所示。同时结合压测工具，可以对代码耗时采样统计。
图 7. 通过 JProfiler 进行内存分析
6、GC 诊断
Java GC 解决了程序员管理内存的风险，但 GC 引起的应用暂停成了另一个需要解决的问题。JDK 提供了一系列工具来定位 GC 问题，比较常用的有 jstat、jmap，还有第三方工具 MAT 等。
jstat
jstat 命令可打印 GC 详细信息，Young GC 和 Full GC 次数，堆信息等。其命令格式为jstat –gcxxx -t pid，如图 8 所示。
图 8.jstat 命令示例
jmap
jmap 打印 Java 进程堆信息 jmap –heap pid。通过 jmap –dump:file=xxx pid 可 dump 堆到文件，然后通过其它工具进一步分析其堆使用情况
MAT
MAT 是 Java 堆的分析利器，提供了直观的诊断报告，内置的 OQL 允许对堆进行类 SQL 查询，功能强大，outgoing reference 和 incoming reference 可以对对象引用追根溯源。
图 9.MAT 示例
图 9 是 MAT 使用示例，MAT 有两列显示对象大小，分别是 Shallow size 和 Retained size，前者表示对象本身占用内存的大小，不包含其引用的对象，后者是对象自己及其直接或间接引用的对象的 Shallow size 之和，即该对象被回收后 GC 释放的内存大小，一般说来关注后者大小即可。
对于有些大堆 (几十 G) 的 Java 应用，需要较大内存才能打开 MAT。
通常本地开发机内存过小，是无法打开的，建议在线下服务器端安装图形环境和 MAT，远程打开查看。或者执行 mat 命令生成堆索引，拷贝索引到本地，不过这种方式看到的堆信息有限。
为了诊断 GC 问题，建议在 JVM 参数中加上-XX:+PrintGCDateStamps。常用的 GC 参数如图 10 所示。
图 10. 常用 GC 参数
对于 Java 应用，通过 top+jstack+jmap+MAT 可以定位大多数应用和内存问题，可谓必备工具。有些时候，Java 应用诊断需要参考 OS 相关信息，可使用一些更全面的诊断工具，比如 Zabbix（整合了 OS 和 JVM 监控）等。
在分布式环境中，分布式跟踪系统等基础设施也对应用性能诊断提供了有力支持。
7、性能优化实践
在介绍了一些常用的性能诊断工具后，下面将结合我们在 Java 应用调优中的一些实践，从 JVM 层、应用代码层以及数据库层进行案例分享。
JVM 调优：GC 之痛
XX商业平台某系统重构时选择 RMI 作为内部远程调用协议，系统上线后开始出现周期性的服务停止响应，暂停时间由数秒到数十秒不等。
通过观察 GC 日志，发现服务自启动后每小时会出现一次 Full GC。由于系统堆设置较大，Full GC 一次暂停应用时间会较长，这对线上实时服务影响较大。
经过分析，在重构前系统没有出现定期 Full GC 的情况，因此怀疑是 RMI 框架层面的问题。
通过公开资料，发现 RMI 的 GDC（Distributed Garbage Collection，分布式垃圾收集）会启动守护线程定期执行 Full GC 来回收远程对象，清单 2 中展示了其守护线程代码。
清单 2.DGC 守护线程源代码
private static class Daemon extends Thread { public void run() { for (;;) { //… long d = maxObjectInspectionAge(); if (d >= l) { System.gc(); d = 0; } //… } } }定位问题后解决起来就比较容易了。一种是通过增加-XX:+DisableExplicitGC 参数，直接禁用系统 GC 的显示调用，但对使用 NIO 的系统，会有堆外内存溢出的风险。
另一种方式是通过调大 -Dsun.rmi.dgc.server.gcInterval 和-Dsun.rmi.dgc.client.gcInterval 参数，增加 Full GC 间隔，同时增加参数-XX:+ExplicitGCInvokesConcurrent，将一次完全 Stop-The-World 的 Full GC 调整为一次并发 GC 周期，减少应用暂停时间，同时对 NIO 应用也不会造成影响。
从图 11 可知，调整之后的 Full GC 次数 在 3 月之后明显减少。
图 11.Full GC 监控统计
GC 调优对高并发大数据量交互的应用还是很有必要的，尤其是默认 JVM 参数通常不满足业务需求，需要进行专门调优。GC 日志的解读有很多公开的资料，本文不再赘述。关注微信公众号：Java技术栈，在后台回复：jvm，可以获取我整理的 N 篇 jvm 教程，都是干货。
GC 调优目标基本有三个思路：降低 GC 频率，可以通过增大堆空间，减少不必要对象生成；降低 GC 暂停时间，可以通过减少堆空间，使用 CMS GC 算法实现；避免 Full GC，调整 CMS 触发比例，避免 Promotion Failure 和 Concurrent mode failure（老年代分配更多空间，增加 GC 线程数加快回收速度），减少大对象生成等。
应用层调优：嗅到代码的坏味道
从应用层代码调优入手，剖析代码效率下降的根源，无疑是提高 Java 应用性能的很好的手段之一。推荐阅读：Java性能优化的50个细节！
某商业广告系统（采用 Nginx 进行负载均衡）某次日常上线后，其中有几台机器负载急剧升高，CPU 使用率迅速打满。我们对线上进行了紧急回滚，并通过 jmap 和 jstack 对其中某台服务器的现场进行保存。
图 12. 通过 MAT 分析堆栈现场
堆栈现场如图 12 所示，根据 MAT 对 dump 数据的分析，发现最多的内存对象为 byte[] 和 java.util.HashMap Entry 对象存在循环引用。
初步定位在该 HashMap 的 put 过程中有可能出现了死循环问题
简要的说就是 HashMap 本身并不具备多线程并发的特性，在多个线程同时 put 操作的情况下，内部数组进行扩容时会导致 HashMap 的内部链表形成环形结构，从而出现死循环。
针对此次上线，最大的改动在于通过内存缓存网站数据来提升系统性能，同时使用了懒加载机制，如清单 3 所示。
清单 3. 网站数据懒加载代码