使用 NetBeans Profiler 5.5
分析方案
与分析应用程序的所有方法相比，分析部分应用程序代码可以显著减少性能分析开销。如果分析长时间运行且反复执行相同或类似操作的应用程序（如服务器端应用程序），建议选择一个或多个根方法，然后分析其调用子图。但是，如果要分析应用程序启动时的性能情况或分析短时间运行的命令行应用程序，则分析大部分或全部应用程序代码会更有效。
Profiler 中包含以下三种分析方案，用于确定分析方法的顺序以及所分析方法的近似数量：Lazy 分析、Total 分析和 Eager 分析。
-
Lazy 分析方案。
这是“预定义的任务”->“分析性能”->“部分应用程序”模式中使用的缺省方案，并且最适于分析长时间运行的应用程序。使用此方案时，Profiler 将按照以下方式来分析方法。首先分析根方法。然后，在第一次执行任意分析的
m()方法时，先扫描其代码，然后依次分析m()可能调用的所有方法。通过这种方法，可以确保分析的方法数近似于目标应用程序在其执行生命周期内实际调用的方法数。通过最大限度地减少已分析但未从根方法中调用的方法数，可以减少分析时间。我们还可以避免以下情况产生的开销：未从根中实际调用分析的方法，但仍从程序的某些其他部分调用它。
但是，分析的方法数通常大于实际调用的方法数。主要原因是，在一般的 Java 应用程序中，很多方法是虚拟的（即不是static的）。因此，如果源代码中包含类似于x.m()的调用，并且x变量的类型为X，则 Profiler 不仅需要分析X.m()方法，而且还需要分析X子类中的m()方法的所有实现。这是因为通常无法提前找出x在运行时的实际类（实际上，它可能会更改多次），因此也无法找出要调用的特定m()实现。
lazy 分析方案最适于分析长时间运行的应用程序，但是，如果需要在应用程序装入很多类或者仅在执行分析时对应用程序进行分析，此方案可能并不适用。这是因为，在 Profiler 使用的 HotSpot JVM 中，通常会将很多应用程序方法编译为计算机代码以提高性能。如果随后对某个方法进行分析，JVM 最初会切换回其字节代码解释（它可以以后再次编译此方法）。甚至某些自身不被分析，但是调用了被分析的方法的方法，也可能会发生临时切换到解释的情况。出于以上原因，在 Profiler 发现调用图形及其以后的一段时间内，应用程序的运行速度会比正常情况慢很多，所以在此期间获得的 CPU 性能分析结果并不代表其正常执行的情况。建议您在启动调用图形分析后先让应用程序运行一段时间（例如，如果是服务器端应用程序，可以让其处理几百或几千个请求），再通过调用“性能分析”->“重置收集的结果”按钮 (
) 来丢弃已累积的性能分析结果。此后收集的性能分析结果会更符合实际情况。 Total 分析方案。
在“分析性能”->“整个应用程序”和“分析应用服务器启动时的性能情况”预定义性能分析任务中将使用此方案。选定这种方案时，Profiler 与大多数其他分析器的工作方式类似，即在装入包含目标应用程序方法的类时，Profiler 将立即分析所有这些方法。此方案会在分析长时间运行的应用程序时产生巨大的开销，但它通常会提供更精确的结果；在将其用于分析应用程序启动时的性能情况或分析相对较小且运行时间较短的应用程序（如命令行实用程序）时，它会产生较小的开销。这是因为，它不会出现上述 lazy 分析方案存在的重复方法反编译和重新编译问题。
-
Eager 分析方案。
Eager 分析是以上两种方案的折衷方案。与 lazy 方案不同，装入某个类后，eager 方案会立即在该类中查找所有可能执行的方法（即，根方法可以直接或间接调用的方法）。通过 Eager 分析所有可能执行的方法，可能会使分析的方法比调用的方法多很多（有时多 10 倍以上），因此，通常建议您不要使用此方案来分析长时间运行的应用程序。但是，它通常会使重复方法的反编译和重新编译次数变少，而这可能很有用。适用的情形如：分析在应用程序启动期间执行的操作时，以及在 total 分析产生过多的开销时。
另请参见
