（点击上方公众号，可快速关注）
泉源：飒然Hang
链接：www.rowkey.me/blog/2016/11/02/java-profile/
对于调优这个事变来说，一样平常就是三个过程：
性能监控：题目没有发生，你并不知道你必要调优什么？此时必要一些体系、应用的监控工具来发现题目。
性能分析：题目已经发生，但是你并不知道题目到底出在那边。此时就必要利用工具、履历对体系、应用举行瓶颈分析，以求定位到题目缘故起因。
性能调优：颠末上一步的分析定位到了题目地点，必要对题目举行办理，利用代码、设置等本领举行优化。
Java调优也不外乎这三步。
别的，本文所讲的性能分析、调优等是抛开以下因素的：
体系底层环境：硬件、操纵体系等
数据布局和算法的利用
外部体系如数据库、缓存的利用
调优预备
调优是必要做好预备工作的，毕竟每一个应用的业务目标都不尽雷同，性能瓶颈也不会总在同一个点上。在业务应用层面，我们必要：
必要相识体系的总体架构，明白压力方向。比如体系的哪一个接口、模块是利用率最高的，面对高并发的挑衅。
必要构建测试环境来测试应用的性能，利用ab、loadrunner、jmeter都可以。
对关键业务数据量举行分析，这里重要指的是对一些数据的量化分析，如数据库一天的数据量有多少；缓存的数据量有多大等
相识体系的相应速率、吞吐量、TPS、QPS等指标需求，比如秒杀体系对相应速率和QPS的要求黑白常高的。
相识体系相干软件的版本、模式和参数等，偶然间限于应用依靠服务的版本、模式等，性能也会受到肯定的影响。
别的，我们还必要相识Java相干的一些知识：
Java内存相干：这一部分可以拜见谈谈Java内存管理一文
对Java代码举行基准性能测试：可以利用JMH来举行，[译]利用JMH举行微基准测试：不要猜，要测试！。
HotSpotVM相干知识：https://www.oracle.com/technetwork/cn/java/javase/tech/index-jsp-136373-zhs.html
jdk自带各种java工具：https://www.rowkey.me/blog/2016/11/03/jdk-tools/
性能分析
在体系层面可以或许影相应用性能的一样平常包罗三个因素：CPU、内存和IO，可以从这三方面举行程序的性能瓶颈分析。
CPU分析
当程序相应变慢的时间，起首利用top、vmstat、ps等下令查察体系的cpu利用率是否有非常，从而可以判定出是否是cpu繁忙造成的性能题目。此中，重要通过us（用户进程所占的%）这个数据来看非常的进程信息。当us靠近100%乃至更高时，可以确定是cpu繁忙造成的相应迟钝。一样平常说来，cpu繁忙的缘故起因有以下几个：
线程中有无穷空循环、无壅闭、正则匹配大概单纯的盘算
发生了频仍的gc
多线程的上下文切换
确定好cpu利用率最高的进程之后就可以利用jstack来打印出非常进程的堆栈信息：
jstack[pid]
接下来必要留意的一点是，Linux下全部线程终极还是以轻量级进程的情势存在体系中的，而利用jstack只能打印出进程的信息，这些信息内里包罗了此进程下面全部线程(轻量级进程-LWP)的堆栈信息。因此，进一步的必要确定是哪一个线程淹灭了大量cpu，此时可以利用top-p[processId]来查察，也可以直接通过ps-Le来表现全部进程,包罗LWP的资源淹灭信息。末了，通过在jstack的输出文件中查找对应的lwp的id即可以定位到相应的堆栈信息。此中必要留意的是线程的状态：RUNNABLE、WAITING等。对于Runnable的进程必要留意是否有淹灭cpu的盘算。对于Waiting的线程一样平常是锁的等待操纵。
也可以利用jstat来查察对应进程的gc信息，以判定是否是gc造成了cpu繁忙。
jstat-gcutil[pid]
还可以通过vmstat，通过观察内核状态的上下文切换(cs)次数，来判定是否是上下文切换造成的cpu繁忙。
vmstat15
别的，偶然间大概会由jit引起一些cpu飚高的情况，如大量方法编译等。这里可以利用-XX:+PrintCompilation这个参数输出jit编译环境，以排查jit编译引起的cpu题目。
内存分析
对Java应用来说，内存重要是由堆外内存和堆内内存构成。
1.堆外内存堆外内存重要是JNI、Deflater/Inflater、DirectByteBuffer（nio中会用到）利用的。对于这种堆外内存的分析，还是必要先通过vmstat、sar、top、pidstat等查察swap和物理内存的斲丧状态再做判定的。别的，对于JNI、Deflater这种调用可以通过Google-preftools来追踪资源利用状态。
2.堆内内存此部分内存为Java应用重要的内存地区。通常与这部分内存性能相干的有：
创建的对象：这个是存储在堆中的，必要控制好对象的数量和巨细，尤其是大的对象很轻易进入老年代
全局聚集：全局聚集通常是生命周期比力长的，因此必要特别留意全局聚集的利用
缓存：缓存选用的数据布局差别，会很大程序影响内存的巨细和gc
ClassLoader：重要是动态加载类轻易造成永世代内存不敷
多线程：线程分配会占用本地内存，过多的线程也会造成内存不敷
以上利用不当很轻易造成：
频仍GC-Stoptheworld，使你的应用相应变慢
OOM，直接造成内存溢堕落误使得程序退出。OOM又可以分为以下几种：
Heapspace：堆内存不敷
PermGenspace：永世代内存不敷
Nativethread：本地线程没有充足内存可分配
排查堆内存题目的常用工具是jmap，是jdk自带的。一些常用用法如下：
查察jvm内存利用状态：jmap-heap
查察jvm内存存活的对象：jmap-histo:live
把heap里全部对象都dump下来，无论对象是死是活：jmap-dump:format=b,file=xxx.hprof
先做一次fullGC，再dump，只包罗仍旧存活的对象信息：jmap-dump:format=b,live,file=xxx.hprof
别的，不管是利用jmap还是在OOM时产生的dump文件，可以利用Eclipse的MAT(MEMORYANALYZERTOOL)来分析，可以看到具体的堆栈和内存中对象的信息。固然jdk自带的jhat也可以或许查察dump文件，会启动web端供词开辟者利用欣赏器欣赏堆内对象的信息。
IO分析
通常与应用性能相干的包罗：文件IO和网络IO。
文件IO可以利用体系工具pidstat、iostat、vmstat来查察io的状态。这里可以看一张利用vmstat的结果图。
这里重要留意bi和bo这两个值，分别表现块装备每秒吸取的块数量和块装备每秒发送的块数量，由此可以判定io繁忙状态。进一步的可以通过利用strace工具定位对文件io的体系调用。通常，造成文件io性能差的缘故起因不外乎：
大量的随机读写
装备慢
文件太大
网络IO查察网络io状态，一样平常利用的是netstat工具。可以查察全部毗连的状态、数量、端口信息等。比方：当time_wait大概close_wait毗连过多时，会影相应用的相应速率。
netstat-anp
别的，还可以利用tcpdump来具体分析网络io的数据。固然，tcpdump出的文件直接打开是一堆二进制的数据，可以利用wireshark阅读具体的毗连以及此中数据的内容。
tcpdump-ieth0-wtmp.cap-tnndstport8080#监听8080端口的网络哀求并
打印日记到tmp.cap中
还可以通过查察/proc/interrupts来获取当前体系利用的停止的环境。
各个列依次是：
irq的序号，在各自cpu上发生停止的次数，可编程停止控制器，装备名称（request_irq的dev_name字段）
通过查察网卡装备的终端环境可以判定网络io的状态。
其他分析工具
上面分别针对CPU、内存以及IO讲了一些体系/JDK自带的分析工具。除此之外，尚有一些综合分析工具大概框架可以更加方便我们对Java应用性能的排查、分析、定位等。
VisualVM这个工具应该是Java开辟者们非常认识的一款java应用监测工具，原理是通过jmx接口来毗连jvm进程，从而可以或许看到jvm上的线程、内存、类等信息。
假如想进一步查察gc环境，可以安装visualgc插件。别的，visualvm也有btrace的插件，可以可视化直观的编写btrace代码并查察输出日记。与VisualVm雷同的，jconsole也是通过jmx查察长途jvm信息的一款工具，更进一步的，通过它还可以表现具体的线程堆栈信息以及内存中各个年代的占用环境，也支持直接长途实行MBEAN。固然，visualvm通过安装jconsole插件也可以拥有这些功能。
但由于这俩工具都是必要ui界面的，因此一样平常都是通过本地长途毗连服务器jvm进程。服务器环境下，一样平常并不消此种方式。
JavaMissionControl(jmc)此工具是jdk7u40开始自带的，原来是JRockit上的工具，是一款采样型的集诊断、分析和监控与一体的非常强大的工具。https://docs.oracle.com/javacomponents/jmc-5-5/jmc-user-guide/toc.htm
Btrace这里不得不提的是btrace这个神器，它利用javaattachapi+javaagent+instrumentapi可以或许实现jvm的动态追踪。在不重启应用的环境下可以参加拦截类的方法以打印日记等。具体的用法可以参考Btrace入门到纯熟小工完全指南。
JwebapJwebap是一款JavaEE性能检测框架，基于asm加强字节码实现。支持：http哀求、jdbc毗连、method的调用轨迹跟踪以及次数、耗时的统计。由此可以获取最耗时的哀求、方法，并可以查察jdbc毗连的次数、是否关闭等。但此项目是2006年的一个项目，已经将近10年没有更新。根据笔者利用，已经不支持jdk7编译的应用。假如要利用，发起基于原项目二次开辟，同时也可以参加对redis毗连的轨迹跟踪。固然，基于字节码加强的原理，也可以实现本身的JavaEE性能监测框架。
上图来自笔者公司二次开辟过的jwebap，已经支持jdk8和redis毗连追踪。
useful-s这里有一个本人参加的开源的项目：https://github.com/superhj1987/useful-s，封装了很多常用的性能分析下令，比如上文讲的打印繁忙java线程堆栈信息，只必要实行一个脚本即可。
性能调优
与性能分析相对应，性能调优同样分为三部分。
CPU调优
不要存在不停运行的线程(无穷while循环)，可以利用sleep休眠一段时间。这种环境广泛存在于一些pull方式斲丧数据的场景下，当一次pull没有拿到数据的时间发起sleep一下，再做下一次pull。
轮询的时间可以利用wait/notify机制
克制循环、正则表达式匹配、盘算过多，包罗利用String的format、split、replace方法(可以利用apache的commons-lang里的StringUtils对应的方法)，利用正则去判定邮箱格式(偶然间会造成死循环)、序列/反序列化等。
连合jvm和代码，克制产生频仍的gc，尤其是fullGC。
别的，利用多线程的时间，还必要留意以下几点：
利用线程池，镌汰线程数以及线程的切换
多线程对于锁的竞争可以思量减小锁的粒度(利用ReetrantLock)、拆分锁(雷同ConcurrentHashMap分bucket上锁),大概利用CAS、ThreadLocal、不可变对象等无锁技能。别的，多线程代码的编写最好利用jdk提供的并发包、Executors框架以及ForkJoin等，别的Discuptor和Actor在符合的场景也可以利用。
内存调优
内存的调优重要就是对jvm的调优。
公道设置各个代的巨细。克制新生代设置过小(不敷用，常常minorgc并进入老年代)以及过大(会产生碎片)，同样也要克制Survivor设置过大和过小。
选择符合的GC战略。必要根据差别的场景选择符合的gc战略。这里必要说的是，cms并非全能的。除非特别必要再设置，毕竟cms的新生代采取战略parnew并非最快的，且cms会产生碎片。别的，G1直到jdk8的出现也并没有得到广泛应用，并不发起利用。
jvm启动参数设置-XX:+PrintGCDetails-XX:+PrintGCDateStamps-Xloggc:[log_path]，以记录gc日记，便于排查问题。
此中，对于第一点，具体的尚有一点发起：
年轻代巨细选择：相应时间优先的应用，尽大概设大，直到靠近体系的最低相应时间限定（根据实际环境选择）。在此种环境下，年轻代网络发生gc的频率是最小的。同时，也可以或许镌汰到达大哥代的对象。吞吐量优先的应用，也尽大概的设置大，由于对相应时间没有要求，垃圾网络可以并行举行，发起得当8CPU以上的应用利用。
大哥代巨细选择：相应时间优先的应用，大哥代一样平常都是利用并发网络器，以是其巨细必要警惕设置，一样平常要思量并发会话率和会话连续时间等一些参数。假如堆设置小了，会造成内存碎片、高采取频率以及应用停息而利用传统的标记打扫方式；假如堆大了，则必要较长的网络时间。最优化的方案，一样平常必要参考以下数据得到：
并发垃圾网络信息
长期代并发网络次数
传统GC信息
花在年轻代和大哥代采取上的时间比例
一样平常吞吐量优先的应用都应该有一个很大的年轻代和一个较小的大哥代。如许可以尽大概采取掉大部分短期对象，镌汰中期的对象，而大哥代存放长期存活对象。
别的，较小堆引起的碎片题目：由于大哥代的并发网络器利用标记、打扫算法，以是不会对堆举行压缩。当网络器采取时，会把相邻的空间举行归并，如许可以分配给较大的对象。但是，当堆空间较小时，运行一段时间以后，就会出现“碎片”，假如并发网络器找不到充足的空间，那么并发网络器将会克制，然后利用传统的标记、打扫方式举行采取。假如出现“碎片”，大概必要举行如下设置：-XX:+UseCMSCompactAtFullCollection，利用并发网络器时，开启对大哥代的压缩。同时利用-XX:CMSFullGCsBeforeCompaction=xx设置多少次FullGC后，对大哥代举行压缩。
别的对于jvm的优化题目可见背面JVM参数进阶一节。
代码上，也必要留意：
克制生存重复的String对象，同时也必要警惕String.subString()与String.intern()的利用
只管不要利用finalizer
开释不须要的引用：ThreadLocal利用完记得开释以防止内存走漏，各种stream利用完也记得close。
利用对象池克制无控制创建对象，造成频仍gc。但不要任意利用对象池，除非像毗连池、线程池这种初始化/创建资源斲丧较大的场景，
缓存失效算法，可以思量利用SoftReference、WeakReference生存缓存对象
审慎热摆设/加载的利用，尤其是动态加载类等
不要用Log4j输出文件名、行号，由于Log4j通过打印线程堆栈实现，天生大量String。别的，利用log4j时，发起此种经典用法，先判定对应级别的日记是否打开，再做操纵，否则也会天生大量String。
if(logger.isInfoEnabled()){
logger.info(msg);
}
IO调优
文件IO上必要留意：
思量利用异步写入代替同步写入，可以鉴戒redis的aof机制。
利用缓存，镌汰随机读
只管批量写入，镌汰io次数和寻址
利用数据库代替文件存储
网络IO上必要留意：
和文件IO雷同，利用异步IO、多路复用IO/变乱驱动IO代替同步壅闭IO
批量举行网络IO,镌汰IO次数
利用缓存，镌汰对网络数据的读取
利用协程:Quasar
其他优化发起
算法、逻辑上是程序性能的重要，碰到性能题目，应该起首优化程序的逻辑处理惩罚
优先思量利用返回值而不是非常表现错误
查察本身的代码是否对内联是友爱的:你的Java代码对JIT编译友爱么？
别的，jdk7、8在jvm的性能上做了一些加强：
通过-XX:+TieredCompilation开启JDK7的多层编译（tieredcompilation）支持。多层编译连合了客户端C1编译器和服务端C2编译器的长处(客户端编译可以或许快速启动和及时优化，服务器端编译可以提供更多的高级优化)，是一个非常高效利用资源的切面方案。在开始时先举行低条理的编译，同时网络信息，在后期再进一步举行高条理的编译举行高级优化。必要留意的一点：这个参数会斲丧比力多的内存资源，由于同一个方法被编译了多次，存在多份native内存拷贝，发起把codecache调大一点儿（-XX:+ReservedCodeCacheSize，InitialCodeCacheSize）。否则有大概由于codecache不敷，jit编译的时间不绝的实行整理codecache，扬弃无用方法，斲丧大量资源在jit线程上。
CompressedOops：压缩指针在jdk7中的server模式下已经默认开启。
Zero-BasedCompressedOrdinaryObjectPointers：当利用了上述的压缩指针时，在64位jvm上，会要求操纵体系保存从一个假造地点0开始的内存。假如操纵体系支持这种哀求，那么就开启了Zero-BasedCompressedOops。如许可以使得无须在java堆的基地点添加任何地点增补即可把一个32位对象的偏移解码成64位指针。
逃逸分析(EscapeAnalysis):Server模式的编译器会根据代码的环境，来判定相干对象的逃逸范例，从而决定是否在堆中分配空间，是否举行标量更换(在栈上分配原子范例局部变量)。别的，也可以根据调用环境来决定是否主动消除同步控制，如StringBuffer。这个特性从JavaSE6u23开始就默认开启。
NUMACollectorEnhancements：这个紧张针对的是TheParallelScavenger垃圾采取器。使其可以或许利用NUMA(NonUniformMemoryAccess，即每一个处理惩罚器核心都有本地内存，可以或许低耽误、高带宽访问)架构的呆板的上风来更快的举行gc。可以通过-XX:+UseNUMA开启支持。
别的，网上尚有很多过期的发起，不要再盲目跟随:
变量用完设置为null，加快内存采取，这种用法大部分环境下并没故意义。一种环境除外：假如有个Java方法没有被JIT编译但内里仍旧有代码会实行比力长时间，那么在那段会实行长时间的代码前显式将不必要的引用范例局部变量置null是可取的。具体的可以见R大的表明：https://www.zhihu.com/question/48059457/answer/113538171
方法参数设置为final，这种用法也没有太大的意义，尤其在jdk8中引入了effectivefinal，会主动辨认final变量。
JVM参数进阶
jvm的参数设置不停是比力理不清的地方，很多时间都搞不清都有哪些参数可以设置，参数是什么意思，为什么要这么设置等。这里重要针对这些做一些知识性的阐明以及对一些轻易让人进入陷阱的参数做一些表明。
以下全部都是针对Oracle/SunJDK6来讲
1.启动参数默认值Java有很多的启动参数，而且很多版本都并不一样。但是如今网上充斥着各种资料，假如不加辨别的全部利用，很多是没有结果大概原来就是默认值的。一样平常的，我们可以通过利用java-XX:+PrintFlagsInitial来查察全部可以设置的参数以及其默认值。也可以在程序启动的时间参加-XX:+PrintCommandLineFlags来查察与默认值不雷同的启动参数。假如想查察全部启动参数(包罗和默认值雷同的)，可以利用-XX:+PrintFlagsFinal。输出里“=”表现利用的是初始默认值，而“:=”表现利用的不是初始默认值，大概是下令行传进来的参数、设置文件里的参数大概是ergonomics主动选择了别的值。
别的，还可以利用jinfo下令表现启动的参数。
jinfo-flags[pid]#查察如今启动利用的有效参数
jinfo-flag[flagName][pid]#查察对应参数的值
这里必要指出的是，当你设置jvm参数时，最好是先通过以上下令查察对应参数的默认值再确定是否必要设置。也最好不要设置你搞不清用途的参数，毕竟默认值的设置是有它的公道之处的。
动态设置参数当Java应用启动后，定位到了是GC造成的性能题目，但是你启动的时间并没有参加打印gc的参数，很多时间的做法就是重新加参数然后重启应用。但如许会造成肯定时间的服务不可用。最佳的做法是可以或许在不重启应用的环境下，动态设置参数。利用jinfo可以做到这一点(本质上还是基于jmx的)。
jinfo-flag[+/-][flagName][pid]#启用/克制某个参数
jinfo-flag[flagName=value][pid]#设置某个参数
对于上述的gc的环境，就可以利用以下下令打开heapdump并设置dump路径。
jinfo-flag+HeapDumpBeforeFullGC[pid]
jinfo-flag+HeapDumpAfterFullGC[pid]
jinfo-flagHeapDumpPath=/home/dump/dir[pid]
同样的也可以动态关闭。
jinfo-flag-HeapDumpBeforeFullGC[pid]
jinfo-flag-HeapDumpAfterFullGC[pid]
其他的参数设置雷同。
2.-verbose:gc与-XX:+PrintGCDetails很多gc保举设置都同时设置了这两个参数，着实，只要打开了-XX:+PrintGCDetails，前面的选项也会同时打开，无须重复设置。
3.-XX:+DisableExplicitGC这个参数的作用就是使得system.gc变为空调用，很多保举设置内里都是发起开启的。但是，假如你用到了NIO大概其他利用到堆外内存的环境，利用此选项会造成oom。可以用XX:+ExplicitGCInvokesConcurrent或XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses(共同CMS利用，使得system.gc触发一次并发gc)代替。别的，尚有一个比力故意思的地方。假如你不设置此选项的话，当你利用了RMI的时间，会周期性地来一次fullgc。这个征象是由于分布式gc造成的，为RMI服务。具体的可见此链接内容中与dgc相干的：https://docs.oracle.com/javase/6/docs/technotes/guides/rmi/sunrmiproperties.html
4.MaxDirectMemorySize此参数是设置的堆外内存的上限值。当不设置的时间为-1，此值为-Xmx减去一个survivorspace的预留巨细。
5.由于遗留缘故起因，作用雷同的参数
-Xss与-XX:ThreadStackSize
-Xmn与-XX:NewSize，别的这里必要留意的是设置了-Xmn的话，NewRatio就没作用了。
6.-XX:MaxTenuringThreshold利用工具查察此值默认值为15，但是选择了CMS的时间，此值会变成4。当此值设置为0时，全部eden里的活对象在履历第一次minorGC的时间就会直接提拔到oldgen，survivorspace直接就没用。
7.-XX:HeapDumpPath利用此参数可以指定-XX:+HeapDumpBeforeFullGC、-XX:+HeapDumpAfterFullGC、-XX:+HeapDumpOnOutOfMemoryError触发heapdump文件的存储位置。
参考资料
JavaHotSpot?VirtualMachinePerformanceEnhancements
JavaHotSpotVirtualMachineGarbageCollectionTuningGuide
[HotSpotVM]JVM调优的”标准参数”的各种陷阱
关注「ImportNew」
看更多Java技能精选文章
↓↓↓
CopyrightYourWebSite.SomeRightsReserved.
京ICP备2023016396号-1PoweredByESCLINK.
我要评论