当我在帮助一些开发者或架构师分析及优化Java应用程序的性能时，关键往往不在于对个别方法进行微调，以节省一或两微秒的执行时间。虽然对某些软件来说，微秒级的优化确实非常重要，但我认为这并非着眼点所在。我在年间对数百个应用进行了分析，发现多数性能与可伸缩性问题都来源于糟糕的架构决策、框架的错误配置、错误的数据库访问模式、过量的日志记录，以及由于内存过度消耗而导致的垃圾回收所带来的影响。
在我看来，性能工程的根本在于通过大量的观察，将关键的架构指标、可伸缩性指标以及性能指标关联在一起。通过对每次构建的结果以及不同负载情况下的表现进行分析，以发现系统中的回归缺陷或瓶颈所在。以下图中的仪表板作为示例：
通过将系统负载、响应时间与SQL语句的执行次数等指标相关联，可得出某些性能工程方面问题的根本原因。
最上面一张图叫做“层分解”图表，它显示了你的应用中各个逻辑组件（例如WebService、数据库访问、业务逻辑、Web服务器等等）的总体执行时间。红色部分所表示的是某个后端WebService所花费的时间，很明显这里产生了一个组件热点。
我们同时可以发现，该WebService并没有承受异常的负载，因为从第二张图来看，当时应用程序所处理的请求数量这条线比较平稳。一般情况下，整体响应时间多数都耗费在数据层，但这并不代表数据库本身的速度缓慢！我了解，低效的数据库访问往往是造成性能不佳的主要原因，因此通常会结合分析SQL语句的执行次数。在这个示例中，已经能够很清楚地看到它与大多数响应时间的峰值是相关的。
我所观察到最常见的问题模式就是糟糕的数据库访问模式，此外还有过于细粒度的服务调用、糟糕的共享数据访问共享、过度的日志记录，以及由内存泄露以及大量的对象创建所导致的垃圾回收影响或是应用程序的崩溃。
可选的诊断工具在本文中，我将专注于探讨数据库方面的问题，因为我十分确信你的所有应用都是因这些访问模式中的某一种而产生问题的！你可以在市场上已有的各种性能诊断、追踪，或是APM工具之间随意选择，不过我所选择的是免费的DynatracePersonalLicense。Java本身也提供了各种出色的工具，例如JavaMissionControl等等。许多提供数据访问功能的框架也经常通过其日志输出提供各种诊断选项，例如Hibernate或Spring等等。
在使用这些跟踪工具时，通常不需要对代码进行任何修改，因为他们都利用了JVMTI（JVMToolingInterface）以捕获代码层面的信息，甚至能够跨远程的各层次进行调用追踪，这一点对于分布式、面向（微）服务的应用来说非常实用。你所要做的就是修改你的JVM启动命令行选项，以加载这些工具。
某些工具的开发商还提供了与IDE的集成功能，你只需简单地表示“在运行时开启XYZ性能诊断功能”。我在YouTube上做了一个简单的视频指南，演示了如何对在Eclipse中启动的应用进行追踪。