为什么Java CPU配置文件(使用visualvm)在一个什么都不做的方法上

发布时间：2020-12-14 05:53:17 所属栏目：Java 来源：网络整理

导读：这是我以前在其他环境中使用其他分析工具时所看到的,但在这种情况下它尤其引人注目. 我正在运行一个运行大约12分钟的任务的CPU配置文件,并且它显示了几乎一半的时间花费在一个字面上什么都不做的方法：它有一个空体.是什么导致这个？我不相信这种方法被称为

这是我以前在其他环境中使用其他分析工具时所看到的,但在这种情况下它尤其引人注目.

我正在运行一个运行大约12分钟的任务的CPU配置文件,并且它显示了几乎一半的时间花费在一个字面上什么都不做的方法：它有一个空体.是什么导致这个？我不相信这种方法被称为荒谬的次数,当然不会占用执行时间的一半.

对于它的价值,所讨论的方法称为startContent(),它用于通知解析事件.事件沿着一系列过滤器传递(可能是十几个),并且每个过滤器上的startContent()方法除了在链中的下一个过滤器上调用startContent()之外几乎没有任何作用.

这是纯Java代码,我在Mac上运行它.

附件是CPU采样器输出的屏幕截图：

这是一个显示调用堆栈的示例：

(因休假而延误)以下是一些显示探查器输出的图片.这些数字远远超出我期望的配置文件的样子.探查器输出似乎完全有意义,而采样器输出是虚假的.

正如你们中的一些人已经猜到的那样,有问题的工作是Saxon XML模式验证器的运行(在9Gb输入文件上).该配置文件显示大约一半的时间用于验证元素内容与简单类型(在endElement处理期间发生),大约一半用于测试关键约束的唯一性;两个探查器视图显示了该任务的这两个方面所涉及的活动.

我无法提供来自客户端的数据.

解决方法

我没有使用VisualVM,但我怀疑问题可能是因为这种空方法的检测开销. Here’s the relevant passage in JProfiler’s documentation (which I have used extensively):

If the method call recording type is set to Dynamic instrumentation,all methods of profiled classes are instrumented. This creates some overhead which is significant for methods that have very short execution times. If such methods are called very frequently,the measured time of those method will be far to high. Also,due to the instrumentation,the hot spot compiler might be prevented from optimizing them. In extreme cases,such methods become the dominant hot spots although this is not true for an uninstrumented run. An example is the method of an XML parser that reads the next character. This method returns very quickly,but may be invoked millions of times in a short time span.

基本上,分析器基本上添加了它自己的“时间长度检测代码”,但是在一个空方法中,分析器将花费所有时间来做这些而不是实际允许该方法运行.

如果可能,我建议告诉VisualVM停止检测该线程,如果它支持这样的过滤.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!