现在基于J2EE的系统使很多关键的IT和面向客户的业务系统变得很强大。虽然J2EE体系架构便于抽象，但是也存在着很大的复杂性。当应用在生产中或达到一定阶段，这些复杂性会导致不可预知的性能问题。J2EE技术栈的复杂性使得很难跟踪到性能问题的根源，他们可能存在于应用代码，数据库，应用服务器和集群的配置文件，操作系统，硬件或者这些组件之间的交互中。所以尽可能快地解决这些性能问题对于应用来说是极其重要的。
诊断测试产品
2010-03-11 14:02
——自动实现JAVA的单元测试和代码标准校验
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 17:48
垃圾收集就是自动释放不再被程序所使用的对象的过程。当一个对象不再被程序所引用时，它所引用的堆空间可以被回收，以便被后续的新对象所使用。垃圾收集器必须能够断定哪些对象是不再被引用的，并且能够把它们所占据的堆空间释放出来。如果对象不再被使用，但还有被程序所引用，这时是不能被垃圾收集器所回收的，此时就是所谓的“内存泄漏”。监控应用程序是否发生了内存泄漏，有一个非常优秀的监控工具推荐给大家——Quest公司的JProbe工具，使用它来观察程序运行期的内存变化，并可产生内存快照，从而分析并定位内存泄漏的确切位置，可以精确定位到源码内. 2009-10-14 17:35
最近发现一部分java写的解析xml程序运行的很慢，使用jprobe跑了一下，搞了一上午，发现问题的所在，检索xml节点时，XPath要进行词法分析，浪费时间，如果是固定的还好，但是每次生成的xpath都不一样，静态编译xpath表达式是不可能的。还好里面的element不是很多，循环里面嵌套，遍历一次就可以解决，速度提高了5000多倍。 事后想了一下，如果看程序定位的话，时间应该更少，速度更快，这还是jprobe定位准确的原因，如果定位不准确，耗时会更多。 页面 |