2016年8月，由极客邦、infoq和听云联合主办apmcon 2016 中国应用性能管理大会上，java性能调优专家monica beckwith进行了《java性能调优必读守则》（原题目：java performance engineer's survival guide）的演讲。演讲中，monica给出关于java调优最佳实践的个人建议：怎样设定需要调优的性能要求、需要对哪些指标进行分析、目标设定后又怎样具体地开展调优。
monica beckwith专注于企业级应用中java虚拟机和垃圾收集器的优化，发表过多篇垃圾收集器和java内存模型方面的文章。她之前就职于 oracle，带领g1垃圾收集器性能团队，目前是一位独立咨询师。在monica演讲之后，infoq又对她进行了专访。
性能调优前的准备工作
monica认为性能优化工程由两部分组成：性能需求分析及规划、性能结果分析。两者构成闭环，使得性能得到不断的提升。
一、性能需求分析及规划
在决定性能需求的时候，工程师们首先要问自己三个问题：
哪些会让用户开心？ 哪些会让用户懊恼？ 目前存在的问题需要被关注并解决吗？
接下来，需要站在用户的角度去思考qos；将qos标准量化为可测量的指标，即sla服务等级协议；然后对sla性能指标进行定义、梳理并排列优先级（吞吐量、响应时间、容量、请求足迹、cpu使用率等）。
吞吐量/率：
目标—是否可以比设定的吞吐量低？如果可以，这种状态可以持续多久？最低可以低到多少？
测量—怎样测量？（事务数/秒、消息数/秒或者两种方式）哪里测量？（客户端、服务器端或者浏览器端）
响应时间：
目标—是否可以超出设定的响应时长？如果可以，这种状态可以持续多久？最长可以达到多久？
测试—怎样测量？（取99%响应的时间计算均值、只统计某一段响应时间（5-9秒）、最差的情况或者全部）哪里测量？（客户端、服务器端或者整个环路）
容量管理：
可以接受的容量是多少？如果某个系统过载怎么办（负载均衡出现问题）？怎样测量容量？一个系统和所有系统能承受的最大容量是多少？可以承受多久？需要监测哪些指标？
二、性能结果分析
关于性能结果分析，这里只讨论java的性能分析。分析哪些因素会影响到终端用户体验，无法达到预期的qos；跟踪监测性能指标。下图是一个分层情况图：
应用层生态系统：应用服务、应用服务器、数据库、生态系统中其他服务 jre层：类加载情况、jit编译情况、垃圾回收情况、线程情况 操作系统层：系统/内核状态、锁状态、线程状态 硬件层：内存带宽/内存吞吐量/内存占用、cpu/内核的使用、cpu缓存效率/使用/级别、处理器结构、io状态
性能调优的执行
两种实现模式
monica提出了两种实现方式：自上而下、自下而上。采用哪一种要看你想要实现什么。
如果想从应用层面入手进行改进的话，且你是一个应用程序工程师，具备修改代码的能力，可以采用自上而下的方式。
如果想从平台层面入手进行改进的话，可采用自下而上的方式。首先你要明确平台的哪个模块是需要改进的；其次列出相关的应用、进行工作量的评估；然后再寻找恰当的工具。
四个步骤
不论哪一种方向，均可以分为四步：第一步监控、第二步归纳、第三步分析、第四步调优和应用。
通常而言，关心的指标有以下几个。
cpu：cpu状态、内核状态、缓存命中和没有命中的次数、分支预测、流水线、条件转移、load-store的工作模式等
内存：内存使用、内存、带宽、读写状态、读操作的最大带宽、写操作的最大带宽、最大容量、与结构相关的。
jvm/gc：收集与变化相关的信息、收集一般或者并发的gc各个阶段的信息、并发工作队列和工作状态、内部队列或缓存等。
监控
首先是从监控环节做起。
监控方式分为三种：主动（报警设定）、被动（网络分流器）、离线（日志抓取）。
可以选用的工具有三类：
第三方——visualvm、java flight recorder
jvm自带命令——printcompilation、printgcdetails(+printgcdatestamps)、jmap-clstats、jcmd gc.class-stats
操作系统自带——linux下面有mpstat、sysstat – iostat、pidstat、prstat、vmstat、dash、cpu – z、 cacti等；windows下面有performance monitor、task manager、resource monitor、cpu-z、cacti等
归纳和分析
接下来是归纳和分析环节。
这个时候你已经有了所有需要的信息，你需要辨识出哪些地方需要提升，分析出哪些是潜在需要改进的问题。这个环节可以使用的开源工具有两类：
第三方性能分析工具——oracle solaris studio performance analyzer、perftools、papi、code xl、 dtrace、oprofile、gprof、ltt
java 程序层面——visual vm、netbeans profiler、jconsole
调优
最后一步调优。jvm/gc的调优重点在于要选择对的堆、对的垃圾回收算法。首先正确划分对象的所属年代，然后只对长期存活的对象进行调优，每个虚拟机的所有gc工作线程（gc 的stop-the-world现象），同一个vm中多个 gc 线程来执行；看看压缩普通对象指针是否有效；大的堆也许需要使能alwayspretouch并且将uselargepages设置为最佳大小。此外，在代码层面优化满足sla目标，设置恰当的ramp-up和ramp-down，对象的年代划分和保留策略（理解lds文件的形成），确保测量正确。
对话monica
infoq: 在性能分析时，是否有必要收集所有的日志？
monica： 当我们知道某处需要调优时，通常来讲用户们会给我发送过来产品环境中的日志，我们基于此复制环境，然后在这个复制的环境中进行测试和检查。我不建议在真实的环境中进行测试，因为生产环境需要保持稳定。什么情况下需要所有的日志呢？当我们确定知道某个问题的存在，比如内存泄露的问题，在这个时候就需要尽可能收集所有日志。
infoq: 能否分析下几种gc方式，并做以简单评价？
monica： 垃圾回收是java应用调优的核心。gc不只有垃圾信息的收集、还有堆的管理分配信息；所有的分配都是类似的。一般而言，如果你有一个很小的空间可以给对象划分世代的话；hotspot jvm中我建议在老年代对象上进行优化。因为年轻代占大多数，而且会死掉。老年代的回收算法中常见默认为垃圾标记-压缩算法。
cms垃圾回收器针对的是年老代的回收，从root对象开始标记存活对象。一旦空间中有不再存活的对象，所占用的资源就会被释放，并且更新到free list中；cms所做的就是要将年老代中所有应该归属于free list的都划分其中。
另外一种设计就是g1。它将资源按区划分，有些区域共同构成年轻代，还有一些构成年老代，即同一个世代的所有区域并不一定是邻近的。每个区域最初都是任意的，需要通过声明才能定义为年轻代或者年老代。在收集时期，年老代并不是一定要全部参与。g1在意的是收集有很多垃圾的区域。此外，g1还会尝试调整年轻代的区间大小。
infoq: java中现在你最想改变的是什么？
monica： java的非堆内存管理可能会在jdk 9 或jdk 10 中得到改善；此外检测内存泄露很困难，我认为有许多需要提升的地方。
infoq: 为了实现更好的性能，你认为java软件开发工程师需要注意哪些事情？
monica： 在编程的时候，要想到java gc是怎样工作的。占用资源的并不是过期的对象，而是存活的对象；活的对象需要去维护。在编程的时候要明白对象的创立、保留策略还有垃圾回收器是怎样工作的。能考虑到这三点就很好了，你没有必要强制自己把每件事情都做对，只要整体可以协调妥帖就很好了。
本文转自d1net（转载）