| | | | | | | [文章信息] | | | 作者: | baggirl编译 | | 时间: | 2003-10-07 | | 出处: | yesky | | 责任编辑: | 方舟 | |
| [文章导读] | | | 本文回顾了三种商用Java分析器并且判断出哪一种分析器更容易满足开发人员的需要 | |
| |
|
| | | |
|
|
|
|
|
Borland Optimizeit Suite
Borland的Optimizeit Suite是三者中最成熟，功能最齐全的分析器包。定价$1,599 ， Borland无疑并不想占领独立开发者市场。它的分析器由三个自由耦合的组件组成： Optimizeit Profiler、 Optimizeit Thread Debugger和Optimizeit Code Coverage。
Borland Optimizeit Suite的核心特征
Borland的Optimizeit分析器是用于CPU和堆栈/对象评价的组合工具包。图2展示了一个典型的GUI屏幕快照。
Figure 2. Optimizeit Profiler的类实例图:好看，但不中用。
图2的类实例图将现实中的对象分布制成表格，按类分组并且按照对象的多少进行排序。如果你之前没有使用过堆栈分析器，请对此做好准备：不但在这个镜头中看到的你的程序低层实体可能完全让你感到迷惑，而且一旦你迷惑了，你同样看不到你的程序的源代码。
Borland的分析器允许你点击任何类并且看清分配了的该类的实例所在的位置。分析器不但告诉你存在分配的方法在哪里（见图3），而且只要你双击方法名，就会弹出一个分配语句行的源代码阅读器。
Figure 3. Optimizeit 分析器的对象分配回溯图。
如果你的程序饱受分配热点（即程序的某部分分配了太多的对象）之苦，或者你想追踪你程序中不应该出现的真实对象的来源（如XML解析器中的抽象窗口工具包（AWT）的有颜色的对象，或者混乱出现在只应该出现命令行的实体中的Swing 对象），那么上述特征就非常非常有用了。
存储检漏仪（Memory Leak Detector）允许你比较你的程序的堆栈的两种瞬象，从而有希望找出被引用的对象中有多少就要断裂的被遗漏的对象。注意，尽管这个工具称做存储检漏仪，而且它也大大的削减了大海捞针的范围，但检测存储漏洞仍然是一件艰巨的手工劳动。
分析器的实例演示（Instance Display）也揭示存储漏洞。 这个工具可让你深入到对象图表的极度精微的程序。你可以分析你的应用程序中的任何一个真实对象的进出索引。我对这个实例演示的疑问就是： Borland没有为了工具的这个部分而使用传统的可视化图表；相反，这个工具使用的是表格和树的综合，如图4所示。
Figure 4. Optimizeit 分析器的对象实例视图。
线程调试器被放在Borland的分析器的第二个模块内。它由所有真实线程以及它们状态（运行，等待，调度，在本机输入/输出（I/O）设备上的阻塞）的实时显示，再加上几种其它的可帮助你分析死锁和资源瓶颈的视图组成。在实时的视图中，每个线程行告诉你对象锁定多少--程序称作"监控器"--线程有多少以及该线程锁住多久了。图5举例说明了一个典型的线程调试会话期。
Figure 5. 线程调试器的默认视图显示实时线程活动和状态。
如果你曾经花过一段时间调试线程问题的话，你肯定会同意下列特征使得线程调试器非常有价值：直接死锁检测和可视化（见图6）、线程争用、线程等待、和附加嵌套的锁定分析。
Figure 6.线程调试器包含检测和显示死锁的逻辑。
Borland 的三件套中的第三个模块Code Coverage，作了一件相当好的工作，它向你展示 所有你系统的线程所观察到的程序部分。这个综合图将类按百分比列出，点击任何类都会弹出执行行用黄色显示的源代码视图。
Borland Optimizeit Suite的缺陷
Borland的三件套结构还不如一个结构，因为它只是一个将三个完全不同的程序放在一起的缺乏弹性的皮带。这就是说，如果你正在使用分析器，接下来又想使用线程调试器做一些线程分析，那你就要切换程序并启动一个全新的会话期。这就不是我们所说的模块组集成了。
线程调试器确实可以使用过滤器特征，它可让你调整你必须费力完成的数据的数量。目前，你不得不观察所有的真实的线程（从任何线程组信息中剥离出来的），就像观察颜色编码的彩虹带卷动的传送带一样：漂亮，但要将信号从噪音中分离出来并不是一件十分容易的事情。 反映Java线程组层级的分层观察特征也不会出现什么差错。另外，时间表示的格式也可以改进：不打印Thread-2 waited 23507561 ms，改为Thread-2 waited 6 h:31 m:47.561 s 可能更会受到程序员的欢迎。
Optimizeit只要用字节显示对象，它就会使用124b的格式。像我这样一个已经灌了一些东西到许多的十六进制垃圾桶的老黑客，这种格式总是触发十六进制的 "B" déjà vu。我的大脑已经大大地将同样的信息格式化成124字节。
Code Coverage的源代码显示也是有一点花架子：它只是用黄色使得执行的代码行突出，而剩下的均为白色（即不突出显示）。这种方法看起来当然不错，但如果它也认为紧挨被执行的代码之后的白色部分（包括注释）也同样的被执行，那这个特征将会有用的多。结果可能要好看得多得多，在显示的间隙还可以显示线程没有涉及的代码。
|
|
|
|
|
|
|
|
