概述：
Java是目前软件开发领域中使用最广泛的编程语言之一。Java应用程序在许多垂直领域（银行、电信、医疗保健等）中都有广泛使用。Refcard的目的是，帮助开发者通过专注于JVM内部，性能调整原则和最佳实践，以及利用现有监测和故障诊断工具，来提升应用程序在商业环境中的性能。
它能以不同的方式定义“optimal
performance（最佳性能）”，但基本要素是：Java程序在业务响应时间要求内执行计算任务的能力，程序在高容量下执行业务功能的能力，并具有可靠性高和延迟低的特点。有时,数字本身变得模式化：对于一些大型网站，优秀的页面响应时间应该在500ms以下。在适当的时候，Refcard包括目标数字。
1、背景介绍
一个系统的上线除了常规的功能性测试外，还需要经过严格的性能测试，满足预期的性能指标（常见的有响应时间，tps等），才允许上生产环境。广义的性能测试一般还包含负载测试（用于测试系统的容量：即系统在保证一定响应时间的情况下能够允许多少并发用户的访问），压力测试（用于测试系统的稳定性：即在保证一定压力的情况下，查看测试系统的稳定性），并发测试（即测试系统多并发能力：即模拟多用户访问同一应用的测试，用于发现并发问题，比如线程锁，资源竞争，数据库死锁等）等。
通过性能测试，可以帮助我们尽快发现系统的瓶颈。如果发现未能满足预期的业务目标，则需要进行性能调优。性能调优的需求，有时候来自于原型的验证，有时候来自于生产上实际的问题，不管哪一类的性能调优，我们一般按照性能监控，性能分析，性能优化这几个步骤进行。以下章节会对每个步骤进行详细分析。
2、性能监控
性能监控是性能调优的第一步，主要目的在于了解当前系统运行的状态，了解当前服务器资源使用情况，JVM的内存使用，线程使用等情况，以便于第一时间找到瓶颈点。
2.1 查看服务器配置
为了更好评估服务器性能，首先应了解当前宿主服务器的配置情况。以下主要是针对linux服务器给出的常见的查看命令。
2.1.1 CPU配置
对于CPU，比较关心的是CPU的总逻辑核数，可以直接使用mpstat查看。
可以使用cat /proc/cpuinfo查看CPU的型号：
2.1.2 内存配置
使用free命令进行查看，可以看到总的内存，以及使用的情况
2.1.3 磁盘配置
使用fdisk -l可以查看到所有的磁盘配置情况，使用df -TH可以看到当前磁盘的目录挂载情况
有时候，需要确认当前磁盘是否为SSD盘，判断cat
/sys/block/*/queue/rotational的返回值（其中*为你的硬盘设备名称，例如sda等等），如果返回1则表示磁盘可旋转，那么就是HDD了；反之，如果返回0，则表示磁盘不可以旋转，那么就有可能是SSD了。如下图所示，sda是SSD盘。
2.1.4 网络配置
使用ifconfig命令，可以看到网卡的配置情况。有时候，需要查看当前网卡是千M还是万M，可以通过ethtool查看speed可以判断。如下图所示，eth4是千M网卡。
2.2 服务器监控
为了能实时了解系统运行时，资源的占用情况，我们就需要对服务器的系统资源进行监控，以下列出常见的命令以及常用的监控事项。
2.2.1 CPU监控
使用vmstat命令，vmstat 2代表每2秒统计一次
重点观察
Ø Procs中r值，它代表调度程序运行队列的长度，如果该值长时间大于CPU逻辑核数1倍以上，需要关注，超过3-4倍需要马上采取行动
Ø System中in（中断），cs（上下文切换）如果两值较大，说明系统内核消耗CPU较多
Ø Cpu列中，如果us（用户态）占比长期大于50%时，就需要考虑优化算法。根据经验us+sy占比参考值为80%
可以使用pidstat -w -I -p pid 2，监控应用的锁竞争情况
让步式上下文切换(cswch)时钟周期占用3% ~ 5%，说明Java应用面临锁竞争，抢占式上下文切换率(nvcswch)高，说明预备运行的线程数多于可用的虚拟处理器数。
2.2.2 内存监控
也可以使用上述的vmstat查看内存页面交换，
重点观察free，si，so这几列，如果free变小，而且si，so在变化，说明存在内存不足，跟磁盘swap，有发生页面交换的情况，需要考虑加大内存。
2.2.3 网络监控
使用第三方软件iptraf，它提供了可视化的页面，通过它可以实时监控网络流量情况。
2.2.4 磁盘
使用iostat进行监控
cpu属性值说明：
Ø 如果%iowait的值过高，表示硬盘存在I/O瓶颈，%idle值高，表示CPU较空闲，如果%idle值高但系统响应慢时，有可能是CPU等待分配内存，此时应加大内存容量。%idle值如果持续低于10，那么系统的CPU处理能力相对较低，表明系统中最需要解决的资源是CPU。
disk属性值说明：
Ø 如果%util接近100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。如果svctm比较接近await，说明I/O几乎没有等待时间；如果await远大于svctm，说明I/O队列太长，io响应太慢，则需要进行必要优化。如果avgqu-sz比较大，也表示有当量io在等待。
2.3 JVM监控
使用jdk中自带的jvisualvm工具，在要连接的远程java进程，启动时增加jmx的配置，如下：
这样jvisualvm就可以通过ip+1111端口侦听远程JVM的情况了。
2.4 连接池监控
2.4.1 查看数据库连接池数量
使用netstat –an | grep ‘db ip’ | wc –l命令，可以看到与数据库创建的连接池，看这个值跟设置的数据库连接池的最小值，以及最大值的关系。如果始终通过最大值，需要考虑调整连接的最大值。
2.4.2 查看工作线程数
方法1：使用jvisualvm工具远程监控来查看
方法2：使用命令查看
2.5 Oracle监控
2.5.1 查看oracle配置
Ø 使用oracle的用户登录oracle的服务器（su - oracle）
Ø 启动sqlplus命令行模式（sqlplus / as sysdba）
Ø 查看配置（Show parameter sga;）
2.5.2 性能监控
Ø 使用sqlplus命令行模式
Ø 开始时启动快照命令，停止时再执行一遍快速命令
备注：快照命令（exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();）
Ø 快照执行完后，取报告(@?/rdbms/admin/awrrpt)
Ø 分析报告（重点关注top 5 time events）
3 性能分析
3.1 JVM分析
3.1.1 堆分析
为了不影响线上的性能，可以使用堆转储，命令如下：
jmap -dump:live，format=b，file=heap_dump.hprofpid
然后可以将生成的.hprof文件导入mat，或者jvisualvm进行分析，可以了解哪些对象正在消耗内存。同时对于识别由创建太多某一特定对象所引发的内存问题，软件提供的直方图方法快速且方便。
3.1.2 垃圾回收分析
Jvm启动时，可以设置-Xloggc，-XX:PrintGCDetails等参数，开启gc日志收集。也可以使用jstat进行监控分析，比如jstat–gcutil pid 2用于每隔2秒打印当前Java堆及GC情况。
3.1.3 线程分析
使用jdk自带的JMC和jstack工具，可以查看堵塞的线程。JMC内部集成的JFR可以很方便的检索出引发线程堵塞的事件。而jstack在一定程度上可以检查线程是堵塞在什么资源上。以下给出jstack定位思路：
4 性能优化
在深度优化系统前，应该先弄清为何CPU的使用率低。优化代码的目的是提升而不是降低更短时间内的CPU使用率。
4.1 JVM启动参数优化
4.1.1 原生内存的优化
对原生内存的优化，包含使用压缩的OOP（jvm启动参数上增加-XX:+UseCompressedOops）以及调整大内存分页（同时修改linux配置以及jvm启动参数-XX:LargePageSizeInBytes）等，都可以提升性能。
4.1.2 垃圾回收机制的优化
Ø 合理设置堆的大小，以及合理设置好代空间的划分：设置太小容易频繁GC，而设置太大，GC时停顿时间太长。同时为了避免可能使用到虚拟内存，内存页交换导致更慢，至少保留1G的物理内存。
Ø 如何选择各分区大小应该依赖应用程序中对象生命周期的分布情况：如果应用存在大量的短期对象，应该选择较大的年轻代；如果存在相对较多的持久对象，老年代应该适当增大。
Ø 稳定与震荡的堆大小：将-Xms和-Xmx的大小一致，对垃圾回收有利。
4.1.3 大对象分配优化
Ø 大对象尽量分配在TLAB，如果大量发生在TLAB外，需要考虑调整TLAB参数，或者减少分配对象的大小。可以通过-XX:PrintTLAB标志查看结果。
Ø 大对象划入老年代：将大对象直接分配到老年代，保持新生代对象的结构的完整性，以提高GC效率，以通过-XX:PretenureSizeThreshold设置进入老年代的阀值。
4.2 java编程优化
因为实际的编程中，涉及性能优化的点比较多，以下只是列举一些常见的优化项供参考。
4.2.1 线程池优化
Ø 根据当前服务器CPU的数量合理设置最大线程数，最小线程数，线程池任务队列大小。CPU密集型任务配置尽可能小的线程，如配置Ncpu+1个线程的线程池。IO密集型任务则由于线程并不是一直在执行任务，则配置尽可能多的线程，如2*Ncpu。
Ø 建议使用有界队列，有界队列能增加系统的稳定性和预警能力。
Ø 优先级不同的任务可以使用优先级队列PriorityBlockingQueue来处理。
Ø 执行时间不同的任务可以交给不同规模的线程池来处理，或者也可以使用优先级队列，让执行时间短的任务先执行。设置线程的优先级。
4.2.2 其它编程细节
Ø 尽量减少内存的使用，减少对象的大小，设置类型时考虑最小原则，去掉不用的属性，以及没有用到的实例变量。
Ø 通过使用对象池以及线程局部变量的方式来加强对象的重复。对象重用跟GC是有点矛盾，所以主要考虑对象初始化时成本比较高的情况（即初始化时间比较长）。
Ø 对于保存实际不需要在多个线程间共享的同步对象，同时又在不同的实际中进行传递的对象，可以考虑使用线程局部变量，减少同步竞争。
Ø 在一些场景下，优化使用java8并行流的模式
4.3 数据库优化
4.3.1 使用预编译
使用preparedStatement方式，重用预处理语句池可以极大提升性能，同时也要避免出现大量大型对象池化而引起的GC方面的问题。
4.3.2 使用连接池
引入hikari连接池，在启动时就配置好
Ø 创建连接的代价很大，通过JDBC连接池获取连接可省去创建连接时间。同时需要合理设置连接池的大小。
Ø 合理设值：比如设置检索时的批量值，设置最优的预取值，设置ResultSet的批量值，可以提高检索的性能。
Ø 事务的优化：事务的提交以及事务相关的锁机制都会影响系统的性能，需要考虑合理设置事务隔离的级别，以及批量提交的策略等。
5 性能实战经验汇总
5.1 清算并发性能上不去
5.1.1 问题的现象
使用java8的并行流计算时，发现并发的性能上不去，并且性能会随着时间推移，不断的下降
5.1.2 优化点
Ø 引入hikari连接池，将单笔延时降到5ms
Ø 关闭日志
Ø 将sql改成预编译的模式
Ø Oracle服务器的把oracle的内存提高
5.2 Hsiar跟中台的连接上，存在很多FIN_WAIT2连接
5.3 Server_name是否可以随便配置
6 小结
6.1 性能工具箱
6.1.1 压测工具jmeter
Jmter是开源的压测工具，也易于上手。它的使用就不介绍了，这里主要讲一些注意的事项：
Ø 它的实时绘图依赖于服务器端的响应，如果压测机与服务器时间不同步的话，会出现展示图断层现象，为了得到更准确的性能曲线，建议使用命令行的方式。
Ø 有时候发现压测性能上不去，有可能的原因在于客户端。主要考虑的因素：客户端的CPU不足以支持所需数量的客户端线程，或者客户端需要花大量时间处理响应后才能发送请求。
6.1.2 JVM相关
除了上文提到的jdk自带的工具外，还有IBM提供的MemoryAnalyzer，以及商用软件jprofile都很强大。
6.1.3 数据库相关
对于数据库的性能监控，可以使用Spotlight，它有基于mysql以及oracle的不同版本支持。
6.1.4 网络相关
常用Linux自带的Tcpdump命令导出抓包，然后使用wireshark进行分析，很强大。