记得在前些年，有一次，在客户那里做系统的性能分析和调整时，也是一点一点的分析，也没有什么头绪。有一个客户那边的负责人，对我们当时的一些做法表示不理解，当时他说了一句话：“做性能分析和调整，首先你得有自己的方法论，然后再谈具体的技术手段”。当时我们还觉得这个客户对我们有意见，觉得自己的做法没有什么不对的。但是在后面这些年里，我深刻的感觉到，这句话真是金玉良言。
其实我并不大喜欢充满哲学味道的东西，我喜欢简单直白的，但是，过于直白，直指目标的一些做法，让自己走了很多弯路，付了很多额外的代价，回过头来，再琢磨，原来那些简单又质朴的话，是不能违背的规律，是必须遵守的守则。
意识到这些之后，我特意针对性能分析和性能调优进行了很多的总结，尤其侧重在方法论，简单的描述一下吧。
第一：要判断性能分析的目标
是为了PK，还是为了实际使用？
你的真实场景，到底需要什么样的性能？
第二：你的周边环境，到底可以为你提供什么样的效率和性能？
例如数据库、例如网络
第三：业务的分析
业务流程是否可以优化？来提高效率？这个最好是对着每一个业务的流程图仔细思考。
第四：检查你的架构
软件实现层面的效率问题，很多都是由架构不良带来的，你即便每一行代码都精简，都无法扭转坏的架构带来的影响。
例如在哪里应当使用缓存，在哪里必须实时读数据库；在哪里需要等待（Sleep），在哪里可以立即进行；在哪里必须使用同步锁，在哪里可以并行或异步，等等等等。
第五：使用性能分析工具
一般来讲，一般不使用性能分析工具来判断架构是否存在问题，而是用来判断具体代码环节是否有问题。使用工具，理念就是“先查找到瓶颈，再进行优化”。实际上，应该是前边几条之后，再进行这一层面上的分析。
工具有几类，有Java自带的工具，有其他第三方工具。
Java命令行可以通过参数，直接进行CPU、内存的分析。当然，还有JConsole和VisualVM，可以用来辅助进行性能分析。还可以分析GC的活动。
第三方工具包括JProfile之类工具，可以进行更加细致的分析，分析结果直接转换成实时的曲线图，非常容易定位性能瓶颈。
使用工具，一般应该首先关注CPU（当然，除非你怀疑自己的系统有内存泄漏问题而进行排查，那样的话，优先关注内存），其次得关注线程（是否有过多的锁定和等待）。
关注CPU，直接定位到最消耗CPU的部分和方法，那么可以非常有针对性的把方法替换为高效实现，这是最简单的系统优化方法。
例如在某个系统分析时，发现Base64.encode消耗CPU非常多，于是在网上搜到了一个FastBase64的实现，替换上去，就发现系统性能马上提高一大截。
当然，最常见的是，解决了一个瓶颈，性能有所改进，又遇到另外一个瓶颈，每一步都非常艰难，每一步都有所进步。
关注线程，非常有利于发现配置不当引起的性能问题。例如数据库连接池配置的太小，例如线程池配置的太小，引起很多时候都在等待空闲连接（或空闲线程）的释放，发现哪里的问题，就可以通过调整配置的方式来改进系统。
关注内存，可以发现是否因为内存的不当使用，使系统很多时候在做GC，从而引起业务的暂停。
最后一点：要考虑系统特性的平衡
系统在某一个性能数据上，达到了一种极致。在此时，再继续做性能的优化，一定会牺牲系统的其他特性。在此时，如何折衷？是性能至上，继续高歌猛进，牺牲其他特性（例如可扩展性等等）；还是优先考虑其他特性，接受当前的性能呢？这是所有架构师需要仔细考虑的问题。
说句题外话，在产品的设计、实现期间，又何尝不是如此，先要有了工作的方法论，再谈技术。没有方法论，产品变成一堆技术的杂烩，是一件可悲的事情。
标签：分析,方法论,性能,线程,内存,设计,PK,工具,CPU From： https://blog.51cto.com/u_2650279/6142648