IBM 的 Java 诊断,第 5 部分: 使用 Health Center 优化应用程序

快速并轻松地修复性能问题、识别配置问题并监控 Java 应用程序

IBM Monitoring and Diagnostic Tools for Java™ - Health Center 是一个用于监控一个正在运行的 Java 应用程序的工具。它通过图表、曲线图和表全面报告系统健康状况,并就如何修复问题提供建议。Health Center 包含一个开销极低的方法配置程序(profiler)、一个垃圾收集可视化程序和一个锁定配置程序,用于识别争用瓶颈;它还包含一个配置浏览器。了解如何使用这个工具诊断和修复应用程序中的性能、配置和稳定性问题。

Toby Corbin, 软件工程师, EMC

Toby Corbin 的照片Toby Corbin 是 IBM Java 技术中心的一名软件工程师,目前正在开发 RAS 工具。他在 2001 加入了 IBM,四年的时间里一直开发 Java Runtime Environment 的国际语言支持和全球化,之后的两年开发 Swing 和 AWT 库。



2009 年 11 月 24 日

关于本系列

IBM 的 Java 诊断 介绍了来自 IBM 的新工具,可帮助解决 Java 应用程序中的问题并提高性能。您可从每篇文章学到新的知识,并且马上就可以投入使用。

本系列的每位作者都属于一个团队,它致力于创建工具来帮助您解决 Java 应用程序的问题。每位作者都拥有不同的知识背景,并为团队带来各种技能和专业领域的知识。

您可以单独联系各个作者,讨论您对这些文章的评论或问题。

是什么原因导致我的应用程序产生性能问题?如果我不是性能专家,如何修复这些问题?我的应用程序稳定吗?它的配置是否合理?IBM Monitoring and Diagnostic Tools for Java - Health Center 是设计用于解答这些问题和其他相关问题的新工具。它检查垃圾收集行为、方法执行、应用程序同步和配置。除了提供问题诊断所需的信息之外,Health Center 中的专家系统还能为您解决问题:提供分析、标记有关区域、提供推荐方法并建议相应的命令行。Health Center 是一个非常轻量级的工具,甚至可以用于生产。本文介绍如何下载和安装 Health Center,以及如何使用它对您的应用程序进行故障诊断和故障排除。

Health Center 入门

Health Center 工具包含两个部分:客户端代理。代理将来自受监控的 JVM 的信息发送到客户端。客户端连接到代理,并在一个 GUI 中显示正在运行的 Java 应用程序的健康状况。

JVM 要求

Health Center 设计用于在 Java 5 或更高版本的 IBM JVM 上运行。它需要的 Java 版本至少为 Java 5 service refresh 8 或 Java 6 service refresh 1。为了用于生产,您需要 Java 5 service refresh 10 或 Java 6 service refresh 5。

安装客户端

Health Center 客户端是 IBM Support Assistant (ISA) 的一部分。要安装客户端,请执行以下步骤:

  1. 下载 并安装 ISA Workbench。
  2. 启动 ISA Workbench,从菜单栏选择 Update > Find New... > Tools Add-ons
  3. Find new tools add-ons 向导的搜索框中输入 health,然后展开 JVM-based Tools 旁边的 Twistie 以显示 Health Center 条目,如图 1 所示。
    图 1. 在 ISA 中安装 Health Center 客户端
    在 ISA 中安装 Health Center 客户端的过程
  4. 选择 Health Center 条目,单击 Next,根据提示完成安装过程,然后启动 ISA。

安装代理

安装客户端后,必须从客户端中下载代理并安装:

  1. 单击 ISA Welcome 页面上的 Analyze Problem
  2. 选择 Tools 子选项卡。从已安装工具列表中选择 IBM Monitoring and Diagnostic Tools for Java - Health Center 并单击 Launch,这将打开 Health Center 连接向导,如图 2 所示。
    图 2. 连接向导
    Health Center 连接向导
  3. 单击 Enabling the application for monitoring 链接。
  4. 在下一页面上,单击 Installing the Health Center agent into an IBM JVM
  5. Installing the Health Center agent into an IBM JVM 页面上,单击与您的系统上的 JVM 对应的链接,以下载代理文件的压缩文档。
  6. 将该压缩文档解压缩到要监控的 JVM 的根目录中。从 Java 6 service refresh 2 和 Java 5 service refresh 8 开始,Health Center 代理就包含在 JVM 中。但是,这个代理可能不是最新版本,因此,最好使用新版本覆盖现有的 Health Center 代理。如果安装过程中提示是否覆盖文件,请选择 yes

启动要监控的应用程序

要使用 Health Center 监控一个应用程序,您必须使用一个启用 Health Center 代理的命令行选项启动该应用程序。选项语法取决于您的 JVM 版本:

  • 对于 Java6 SR5 和以上版本,使用 -Xhealthcenter
  • 对于 SR1 和以上版本,使用 -agentlib:healthcenter -Xtrace:output=perfmon.out 选项。
  • 对于 Java 5、SR10 和以上版本,使用 -Xhealthcenter。否则,使用 -agentlib:healthcenter -Xtrace:output=perfmon.out

如果您不知道自己的 Java 版本号,可以通过运行 java -version 命令将版本号输出到控制台,如图 3 所示。

图 3. 获取 Java 版本号
从 Java 6 SR5 JVM 列出版本号

要确定使用哪个命令选项来启用代理,一个简单的方法是首先尝试 -Xhealthcenter 选项。如果不行,再尝试 -agentlib:healthcenter -Xtrace:output=perfmon.out

如果在您的应用程序启动时,Health Center 代理也成功启动,控制台上将显示一条消息。例如,如图 4 显示,当我们使用 -Xhealthcenter 选项运行 java -version 时,Health Center 代理在端口 1972 上启动。代理通常监听端口 1972,但如果该端口已被使用(比如另一个 Health Center 代理),该代理将自动递增端口号。

图 4. 运行 java -version 并启用 Health Center
运行 java -version 并启用 Health Center

一旦代理启动,您就可以使用 Health Center 客户端监控您的应用程序并解决各种性能和配置问题。


示例 1:修复一个性能问题

性能优化必须以具体证据为依据。通过检查应用程序代码来识别潜在的性能改进并直接进行修复固然很容易也很诱人,但是,不成熟的优化可能会降低生产率,甚至很危险。与更慢但更自然的代码相比,优化后的代码通常更难以维护。而且,进行这些优化也会耗费大量时间。如果性能的确得到改进,那么优化成本和高度优化的代码所需的额外维护工作仍然是值得的;然而,许多优化并没有取得任何性能改进效果。优化必须瞄准那些能够产生显著效果的位置。识别优化会在哪些位置产生显著效果的过程也是发现瓶颈的过程。

分析性能问题

本质上,所有性能问题的根源都是因为资源有限。影响性能的几种基本计算资源是:CPU、内存、I/O 和锁。一个 CPU 关键型应用程序不能得到足够处理器时间来完成既定工作。一个内存关键型应用程序得不到足够的内存。一个 I/O 关键型应用程序的 I/O 速度无法被系统处理。在一个锁关键型应用程序中,多个线程在相同的锁上争用。线程之间的同步导致了锁争用。随着这些系统变得越来越并行化,同步成为一个影响它们的伸缩性的限制因素。

通过识别瓶颈,您可以识别哪个资源是有限的。Health Center 有几个用于检查和诊断低劣的应用程序性能的工具。性能分析过程是这样的:发现瓶颈、修复瓶颈问题,识别下一个瓶颈、修复瓶颈问题,循环往复,直至获得满意的性能。Health Center 自动化用于识别有限资源的多种流程。目前,Health Center 不能分析 I/O 使用情况,但它能为 CPU 使用、内存使用和锁使用提供形象化显示和建议。

Health Center 的 Status 透视图显示一个带有状态指示器的仪表板,每一个潜在的受限资源都有一个状态指示器。红色和橙色状态表示应用程序性能可以提高的区域。图 5 显示打开的 Status 透视图:

图 5. Status 透视图
status 透视图

检查垃圾收集

过度的垃圾收集(Garbage Collection,GC)是性能低下的一个普遍原因。GC 是 JVM 用于自动管理应用程序内存的过程。它的好处 — 就代码安全和简单性而言,甚至经常就性能而言 — 是巨大的。但是,垃圾收集器确实占用处理资源,不当的应用程序内存使用模式和配置不当的堆大小都可能会导致垃圾收集器成为一个重大的性能瓶颈。

Health Center 提供 GC 行为的详细形象化显示和关于 GC 调优的建议。图 6 显示了 Health Center 的 Garbage Collection 透视图,它包含已用堆(用于估计应用程序的内存使用)和暂停时间(用于估计 GC 的性能影响)的形象化显示,以及一个 GC 统计摘要表和一组推荐方法,其中包括命令行建议(如果需要的话)。

图 6. Garbage Collection 透视图
Garbage Collection 透视图

查看 大图

评估 GC 的性能影响时,需要检查的最重要的项目是暂停时间和开销:用于进行垃圾收集而不是执行应用程序工作的时间的比例。图 7 展示了 Health Center 计算的 GC 开销。如果开销值较高,则应用程序可用的处理时间就不足。如果暂停时间值较高,则应用程序响应性就低,因为应用程序活动将在 GC 暂停期间停止。

图 7. GC 开销展示表
Garbage Collection 摘要表,表示开销的行用圆圈标识

GC 性能改进策略

GC 的性能影响可以通过几种方法降低。第一种方法是生成更少的垃圾。应用程序是否创建对象并立即丢弃这些对象?字符串被反复连接并没有使用字符串缓冲?自动装箱(autoboxing)是否在后台创建无关的原语包装器吗?代码正在生成不需要的大对象吗?其他性能改进方法包括提高堆大小、调整保育室(nursery)大小(用于分代收集器)和尝试另一个 GC 策略。但是,使用这些技术时要小心。

例如,调优代码以改进 GC 时必须小心。某些明显的优化可能最终会导致更糟糕的性能。例如,通过重用现有对象实例来避免重复创建对象看起来很不错。但是,安全地管理对象池可能会导致同步开销。如果对象池大小没有正确调优,许多未使用的对象实例最终会被闲置,耗尽内存而不产生任何价值。然而,最严重的是,使用一个分代垃圾收集器(比如 gencon 策略所使用的)时,短期存在的对象根本收集不到,而长期存在的对象的收集成本则太昂贵。重复创建并丢弃对象的方法产生很小的性能开销,而持有现有对象实例以便重用的方法则为垃圾收集器增加大量的工作负担。

另一个 GC 调优陷阱是过度关注减小 headline GC 开销(参见 图 7),而忘记了总体目标是优化应用程序 的性能。尽管减小 GC 开销通常会提高应用程序性能,但也有例外情况。例如,使用 gencon 策略执行 GC 花费的时间通常比使用 optthruput 策略花费的时间更多(参见 参考资料)。但是,由于 gencon 策略在堆中放置对象的特定方式,该策略支持更快的对象分配和更快的对象访问。由于应用程序通常花费很多时间来分配和访问对象,所以,对多数应用程序来说,在这个区域获取的性能改进(没有在 GC 开销中反映出来)超出了 GC 本身的额外成本。甚至还有更具戏剧性的例子:optavgpause 策略几乎能同时执行所有 GC 工作,只有非常短的 “stop-the-world” 暂停。这导致非常低的 GC 开销(通常低于 1%)和极好的应用程序响应性。但是,在应用程序吞吐量方面不如 optthruputgencon 策略。

检查锁争用

当一个锁当前正在使用,而另一个线程试图获取它,那么就会出现锁争用。以下三种锁会出现较高程度的争用:经常获取的锁,长期占用的锁,以及经常使用且长期占用的锁。一个高度争用的锁(许多线程试图访问的锁)可能会变成系统中的一个瓶颈,因为每个正在运行的线程在其需要的锁可用之前都会暂停执行,从而限制了应用程序的性能。同步很可能会阻止应用程序的可伸缩性;系统中的线程数越多,用于等候锁而不是执行有用的工作所花费的时间也就越多。Health Center 可视化锁行为并突出显示那些正在阻塞请求且有可能影响性能的锁。

图 8 展示了 Health Center 的 Locking 透视图:

图 8. Locking 透视图
Locking 透视图

查看 大图

要理解图 8 展示的柱形图,您需要理解显示的数据。柱形图中的竖条用颜色编码,从绿色到红色,以显示争用的程度。激烈争用的锁显示为鲜红色,没有争用的锁显示为鲜绿色。每个竖条的高度(相对于其他竖条)显示锁堵塞的程度。因此,颜色和高度共同显示哪些锁的争用最激烈。

一个锁可以拥有很高的竖条但仍然处于绿色。这表示尽管该锁拥有大量受到堵塞的请求,但总的来说它拥有很多的成功获取,因此总堵塞请求的百分比仍然很低。但是,这仍然会影响性能。在图 9 中的锁定柱形图中,您将看到两个橙色的竖条:

图 9. 锁定柱形图
Locking 透视图柱形图

在图 9 中,有两个锁值得深入研究,因为两个竖条都表明激烈的争用。它们是最高的两个竖条,这说明它们拥有最多的受阻请求;它们正在变为红色,这说明请求那些锁的受阻请求的总百分比很高。

锁性能改进策略

带有非常慢的计数的锁都可能影响性能。如何减小这些锁的性能影响?第一步是检查哪些代码正在使用问题锁。Health Center 显示锁的类别,在某些情况下,这足以识别锁,但在另一些情况下则无法识别。例如,如果锁对象的类别是 Object,搜索代码以引用它可能不太容易。图 10 展示 Health Center 对锁行为的分析,涉及 DataStore 类别和 Object 类别的各种锁。如果 Health Center 将锁定标识为一个性能问题,但从 Health Center 分析中又不能确定具体是由哪个锁引起问题,那么您可以重构代码以在锁对象中使用更明确的类名称,或者使用一系列 javacore 来捕获调用最常用锁的调用堆栈。

图 10. 锁定表
锁定表特写

确定问题锁后,您应该重写应用程序来减少该锁的争用。可以用两种方法最小化争用:减少占用锁的时间,这将降低冲突发生的几率;提高使用的锁对象的数量,这样每个锁对象将用于更少的上下文中(参见 参考资料)。

检查代码执行

一个方法配置文件将告诉您应用程序正在运行的是哪些代码。(它并不告诉您应用程序何时等待锁而不是运行您的代码,它也不会告诉您 JVM 何时收集垃圾而不是运行您的代码)。如果有一个或两个方法消耗的 CPU 时间不正常,那么优化这些方法可以极大地改进性能。图 11 显示 Health Center 的 Profiling 透视图,它包含一个按照活跃程度(热度)排序的最活跃方法表和一组建议。

图 11. Profiling 透视图
Profiling 透视图

查看 大图

如果没有一个方法的颜色为橙色或红色,则应用程序的执行在几个方法之间相对均衡。优化最热的方法仍然是值得的,因为它们产生的性能也许还不够好。例如,某个方法可能过度使用 I/O。在本例中,某个方法占用的 CPU 资源明显比其他方法多,因此它的颜色为红色。通过图 11 中左边的 Self 列的值可以看出,在 JVM 检查的应用程序的工作时间中,42.1% 的时间用于执行 DataStore.storeData(I) 方法。右边的 Tree 列显示应用程序在 DataStore.storeData(I) 方法及其子方法上花费的时间。在一个简单的单线程应用程序中,100% 的 Tree 时间将用于 main() 方法。

代码优化策略

性能优化的目标是减少应用程序的工作。由于大部分工作发生在方法配置文件中排在前面的方法中,因此这些方法应该重点考虑。您可以放心地忽略方法配置文件中排在底部的方法。

采样配置程序和跟踪配置程序

Health Center 通过每 2 毫秒对调用堆栈进行一次采样来生成方法配置文件。有些配置程序称为跟踪配置程序,它们跟踪方法的进入和离开。这提供关于所有被调用方法及其调用时间的详细信息,但这将为被配置的应用程序带来巨大的开销。Health Center 之所以能够实现如此低的开销,方法之一是使用采样配置程序替代跟踪配置程序。但是,由于不知道方法何时开始以及何时结束,采样配置程序不能区分以下两种方法:由于被经常调用而频繁出现在调用堆栈上的方法;由于需要很长时间才能完成而频繁出现的方法。

一个方法出现在方法配置文件顶部的原因有两个:要么该方法被频繁调用,要么它在被调用时执行的工作太多。执行带有循环(特别是嵌套循环)的方法可能需要耗费很多时间。包含多行代码的方法的执行时间通常也比代码行较少的方法的执行时间更长。如果一个只有少量代码并且不包含循环的方法位于配置文件的顶部,那么它可能正被频繁调用。

有两种方法可以优化一个应用程序:一是在耗费时间的方法中执行更少的工作,二是减少频繁调用的方法的调用次数。要减少方法中执行的工作,最有效的方法是尽量将代码移出循环。要减少一个方法的调用次数,方法是找出哪些代码正在调用该方法,然后取消这些调用。通常,至少是在优化的初始阶段,对配置文件顶部的方法的调用中,相当大的一部分调用都是不必要的,可以安全删除。在 Health Center 的方法配置文件中选择一个方法,将在屏幕底部显示它的调用路径。图 12 显示,对 DataStore.storeData 方法的 90.3% 的调用来自 StoreData.run 方法。

图 12. 一个调用路径树
调用一个方法

关注不同的时间间隔

有时,一个应用程序的行为在某个时段内会剧烈变化:垃圾行为变得密集,或者对某个锁的争用十分激烈,或者某个方法迅速蹿升至方法配置文件的顶部。Health Center 支持对某个选定时段进行分析。用鼠标在柱形图上拖动一个方框将缩小显示的时段,这种剪裁将影响所有透视图。建议将被更新,以只基于选定的时段。方法配置表也会被更新,以便样例计数和百分比只针对选定的时段。这允许您,例如,只看到在 GC 出现问题时执行的方法;或者排除在应用程序启动期间分析的数据。


示例 2:修复配置问题

在现代环境中,创建和部署一个 Java 应用程序可能需要几个不同的个人,也可能需要很多大型团队,尤其是当应用程序在一个应用服务器或框架中运行时更是如此。启动参数可以在几个不同的位置设置,要了解哪个 JVM 使用什么配置运行何种应用程序将非常困难。尽管在正常情况下这完全可以接受,但如果出现问题,更好地理解 Java 应用程序的配置方式可能非常关键。不当的配置可能会导致性能问题,这些问题并不总是能通过前面介绍过的方法识别,它们会导致异常的应用程序行为并危害服务能力。

Health Center 包含一个名为 Environment 的透视图,它显示受监控的应用程序的类路径、系统属性和环境变量。它还分析 Java 配置并提供关于潜在问题的建议。图 13 显示 Environment 透视图:

图 13. Environment 透视图
Environment 透视图

查看 大图

我运行的是哪个 JVM?

在 Environment 透视图中显示的最简单的信息之一是正在被监控的 JVM 的地址。令人惊讶的是,这个简单信息通常足以用于解决问题。预期的类不可用吗?对 JAVA_HOME 中的文件的修改(如日志配置、安全配置或库更改)没有起作用吗?诊断这些问题时,首要任务是检查正在运行的 JVM 是不是您所预期的。大多数现代系统可以安装许多 JVM,大型应用程序甚至可以在不同的位置包含几个不同的 JVM。

我正在使用哪些启动参数运行?

Java 技术支持的命令行选项范围非常广泛。某些选项适用特定环境,但不适用其他环境。在一个现代应用程序部署中,可以在几个嵌套启动脚本中设置选项,应用程序实际运行哪些选项并不总是很清楚。Health Center 提供一个视图以显示最终的 Java 命令行,这允许您确定异常的应用程序配置。例如,最大堆大小可能被限制为较小的值。对于较小的实用应用程序而言,这没有问题;但对于需要在内存中操作大型数据集的应用程序而言,这种限制可能会导致崩溃。如果负责这个崩溃的应用程序的团队不知道这个最大堆大小设置,他们很难理解为何内存总是不够用。图 14 显示 Health Center 列出一组命令行选项:

图 14. 命令行选项清单
Java 参数

查看 大图

Health Center 还能分析可能具有不良后果的 Java 配置和标记选项。例如,在部署的测试阶段添加的选项可能没有在进入生产阶段之前删除。特别是,几个调试选项(如 -Xdebug-Xcheck 选项)可能对于在测试过程中发现问题很方便。但是,这些选项会增加性能开销,如果要获得最优性能,应该避免使用这些选项。其他选项(如 -Xnoclassgc)也许能够提供一些性能好处,但面临扩展内存需求不确定的风险。

我有足够的信息来诊断应用程序崩溃吗?

并不是所有的配置问题都与 Java 命令行相关,有些问题的原因是底层系统属性。最显著的因素与 Linux® 和 AIX® 系统对一个进程使用的资源的限制有关。CPU 使用、消耗的虚拟内存量、文件大小和内核文件大小可以使用 ulimit 命令限制。尽管这个命令很有用,但它也可能会阻碍问题诊断。如果内核文件因为 ulimit 设置过低而被截短,则几乎不可能从它们提取有意义的信息。在某些系统上,默认的 ulimit 设置几乎总是导致截短内核文件。(内核文件是进程意外结束时操作系统自动创建的进程映像。对于诊断多种应用程序问题,特别是崩溃问题,内核文件起到关键作用)。

由于内核文件只在问题出现时才生成,因此当找到有问题的 ulimit 设置时通常为时已晚:JVM 已经崩溃,带走了诊断问题所需的所有信息。通常,确保 ulimit 不会阻止生成完整的内核文件的惟一方法是猜测 ulimit 设置可能会出现问题,然后手动检查 ulimit 设置。遗憾地是,这并不是理想的方法,因为它涉及相当模糊的知识和大量防御系统管理工作。Health Center 能够自动探测这种常见的服务能力问题。使用 Health Center,没有必要亲自检查 ulimit 设置 — 它将在 ulimit 需要调整时发出一条警告。


示例 3:评估系统稳定性

尽管在 Java 环境中崩溃并不常见,但 Java 应用程序仍然可能意外终止。这种崩溃有几个原因。一个常见原因是:Java 代码通过 Java Native Interface (JNI) 调用本机代码,本机代码中的一个不安全的内存访问触发了一个常规保护错误(General Protection Fault,GPF)。另一个常见原因是 Java 应用程序已经耗尽内存堆,不能继续执行。Java 应用程序也有可能耗尽本机内存,这也会导致崩溃(参见 参考资料)。由于内存耗尽(Java 堆或本机内存)而导致的崩溃的特征是一个 OutOfMemoryException

诊断一个内存漏洞

大多数崩溃都是不可预见的,但某些崩溃则不然。特别是,Health Center 试图预测由于 Java 堆耗尽而导致的崩溃。Health Center 不能预测由于企图实例化一个过大的对象而导致的 OutOfMemoryException,但是大多数 OutOfMemoryException 的原因是内存泄漏:对不再需要的内存的引用。这个内存不能被垃圾收集器释放。如果不需要的对象持续增加,最终将没有空间容纳需要的对象,这时就会出现一个 OutOfMemoryException。图 15 展示了 Health Center 对一个存在内存泄漏的应用程序使用的堆的形象化显示。应用程序的内存需求一直在持续上升,Health Center 发出一条警告,指出最终可能会导致崩溃。

图 15. 可疑内存泄漏图
一个内存漏洞

查看 大图

Heath Center 识别出漏洞后,如何修复漏洞呢?关键是要确定哪些对象正在使用泄露的内存。这种分析最好从一个堆或系统转储进行。系统转储为堆中的每个对象创建一条记录,记录对象使用的内存量,哪些对象正在引用该对象。持有对不再需要的对象的引用是 Java 应用程序中产生内存泄漏的最普遍原因。

没有工具支持的话,几乎不可能执行堆分析,好在我们有一些优秀的工具可用。尽管 Health Center 不分析转储,诊断工具家族的另一个成员能够完成这个工作。与 Health Center 一样,IBM Monitoring and Diagnostic Tools for Java - Memory Analyzer 可以在 ISA 内免费下载(参见 参考资料)。它提供高级堆内容摘要,包括可疑漏洞的识别。通常,这个工具本身就足以确定泄漏原因并修复漏洞。图 16 展示运行的 Memory Analyzer:

图 16. ISA 的 Memory Analyzer
ISA 中的 Memory Analyzer

查看 大图

对于更复杂的情况,Memory Analyzer 还提供强大的工具以向下钻取堆内容,其中包括一个对象查询语言。


结束语

Health Center 提供范围广泛的关于应用程序执行、稳定性和性能的信息。它提供关于 GC 使用的建议、识别热方法、突出显示锁争用区域,提供关于应用程序的运行环境的信息。

Health Center 是一个宝贵的开发工具,它能帮助您消除性能问题、内存泄漏和低效代码,避免问题出现在生产阶段。另外,由于 Health Center 的开销特别低,它还可以用于解决生产系统上的问题。借助 Health Center 提供的分析和建议,即使您不是一位 Java 管理和性能调优专家,也能识别和修复问题。

参考资料

学习

获得产品和技术

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Java technology
ArticleID=449301
ArticleTitle=IBM 的 Java 诊断,第 5 部分: 使用 Health Center 优化应用程序
publish-date=11242009