什么是性能分析
“性能分析”一词有许多种定义，但在我看来最有用的一个是：
一种由测量驱动的方法，用以了解一个应用程序在负载下的行为。
这个定义的好处是，它提醒您注意测量是整个过程的关键点。并通过简单的延伸，也提醒您统计和数据分析可能是性能工程师的重要工具。
进一步讲，它使我们更相信应把性能分析看作是一项基础的实证研究活动，是它把输入和输出粘合在一起组成实验科学。
这样，这些输出就可以被框定为一系列具有量化答案的问题，比如：
如果有10倍的客户数，系统还有足够的内存来应付吗？
在客户看来，应用程序的平均响应时间是多少？
（这个响应时间）在其余部分的分布是什么样子的？
与我们的竞争对手相比如何？
在这种形式中，使用这些最佳实践所表达出的性能更具有科学性，而不是艺术性；更是一种从根本上可以量化的行为，并且与业务活动有着直接的关系。
然而，尽管有这些属性，性能指标却常常屈居于一个尴尬的状态，知名的最佳实践滞后于从业者的现实处境。
有一些不同的模型可以佐证这一点，可能其中很有趣的一个就来自Carey Flichel的精湛之作《为什么开发者总是选昏招（Why Developers Keep Making Bad Technology Choices）》。
在文章中，Carey特别提出了导致开发者做出错误选择的五大因素：
乏味；
简历加料；
同侪压力；
缺乏了解现有系统；
被误读的，或者根本不存在的问题。
在本篇文章中，我们提出一些在企业平台上最常见的性能分析反模式，并尝试使用Carey所列举的几种基本因素进行阐述。获得以下的结论所使用到的具体例子是从Java生态系统抽取来的，但类似的描述也适用于许多其他类型的企业系统。
每一项基本因素都对应于一些常见的认知偏差。例如，乏味和简历加料都源于对现有技术的逃离——这些技术是开发人员在他的日常工作中整天使用的——以及他们对美好明天的雄心壮志。
以下就列举这些反模式，这里使用了一种向“四人组（Gang of Four）”，当然也包括反模式的开创者Brown等前辈致敬的风格和格式。
反模式目录
只见光鲜亮丽
描述
最新最酷的技术往往是第一指向目标。
典型意见
万事开头难，我们需要颠覆性的开始。
真实情况
这只是在黑暗中的灵光一闪；
开发者并不真正了解新技术。
根本原因
乏味；
简历加料。
探讨
这种反模式在年轻的团队中最常见。急于证明自己，或者尽力避免绑在他们眼中的“遗留”系统上，他们往往倡导新的、“热”的技术。也可能巧合的是，这类技术又常常在跳槽时能为他们带来更高的薪水。
因此，面对任何性能问题时，合乎逻辑的潜意识结论就是先来看看新的技术。毕竟，它还没有为人熟知，所以一双有创见的眼睛总是有益的，不是吗？
解决方法
测量，并去找出真正的瓶颈；
确保围绕新的组件有足够的日志记录。