JProbe Suite

2010-03-19 16:16

 

 

2010-03-11 13:03

(JProbe 已于2013年退市,请选择类似的优秀德国产品 JProfiler

2009-10-22 17:39

我曾经在刚入行的时候做过一个小的swing程序,用到了java SE,swing,Thread等东东,当初经验少也没有做过严格的性能测试,布到生产环境用了一段时间后发现那个小程序有时候会抛java.lang.OutofMemoryError异常,就是java的内存溢出。当时也上网查了不少资料,试过一些办法,代码也稍微做了些优化,但是有一个问题我始终是找不到解决的方案 - 不知为什么子窗体关闭后java的垃圾回收机制无法回收其资源,因为这个Java程序可能要经常开关一些子窗体,那么这些子窗体关闭后无法释放资源就造成了Java程序OutOfMemoryError的潜在的隐患!

2009-10-14 18:10

JProbe Suite支持下列应用服务器:

2009-10-14 17:48

垃圾收集就是自动释放不再被程序所使用的对象的过程。当一个对象不再被程序所引用时,它所引用的堆空间可以被回收,以便被后续的新对象所使用。垃圾收集器必须能够断定哪些对象是不再被引用的,并且能够把它们所占据的堆空间释放出来。如果对象不再被使用,但还有被程序所引用,这时是不能被垃圾收集器所回收的,此时就是所谓的“内存泄漏”。监控应用程序是否发生了内存泄漏,有一个非常优秀的监控工具推荐给大家——Quest公司的JProbe工具,使用它来观察程序运行期的内存变化,并可产生内存快照,从而分析并定位内存泄漏的确切位置,可以精确定位到源码内.

2009-10-14 17:35

最近发现一部分java写的解析xml程序运行的很慢,使用jprobe跑了一下,搞了一上午,发现问题的所在,检索xml节点时,XPath要进行词法分析,浪费时间,如果是固定的还好,但是每次生成的xpath都不一样,静态编译xpath表达式是不可能的。还好里面的element不是很多,循环里面嵌套,遍历一次就可以解决,速度提高了5000多倍。

事后想了一下,如果看程序定位的话,时间应该更少,速度更快,这还是jprobe定位准确的原因,如果定位不准确,耗时会更多。

2009-09-22 09:03

    我们评价一个应用的有效性,通常要进行覆盖代码的单元测试,分析代码是否都能被有效的使用。

     一般性过程是采用全面的测试用例,然后分析代码覆盖情况,对于未执行过的代码需要特别关注和分析。未执行的代码一般是由于测试用例不完善或代码本身是无用代码。

2009-09-22 08:53

        Call Graph(见图1)提供一个非常有力的方法调用关系视图。它把J2EE应用放到WebLogic Server上下文环境中,所以你能看到WebLogic启动的所有线程,包括调用J2EE应用的线程。为了方便查找,Call Graph下面有"Method List"。

2009-09-22 08:44

Method List窗口(见图1)以表的形式显示性能数据。 JProbe

页面