使用 JVMTI 测量方法执行情况
使用 JVMTI 提供的 MethodEntry 和 MethodExit 事件挂钩，如何测量 Java 中执行方法的时间？
简单来说，它只是： time2 - time1 但我看到的问题是，如何区分不同的方法？有methodID，但是递归调用怎么办？方法打开后什么时候关闭？
我应该比较堆栈跟踪吗？什么是有意义的数据结构来跟踪输入的方法？像 Map
Using the MethodEntry and MethodExit event hooks provided by the JVMTI how would I measure the time of a method executed in Java?
In simple means it's just: time2 - time1 but the problem I see, how to I distinguish between the different methods? There is a methodID, but what about recursive calls? When is a method closed after it was opened?
Should I compare the stack trace? What would be a meaningful data structure to trace the methods which where entered? Something like Map<StackTrace,Time>?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
每个线程都需要一个堆栈，并且在每次
MethodEnter时将时间戳压入堆栈，在MethodExit时弹出时间戳并计算与当前时间的差值。尽管您应该记住，读取时间戳或滴答计数以及周围的逻辑相对耗时。如果您在某种分析器中使用类似的东西，您将得到的结果使小型快速方法显得非常昂贵。即
ByteBuffer.get()的执行速度可能比您的测量代码至少快 10 倍。再加上 JVMTI 处于活动状态时由于 JIT 编译有限而造成的失真，此类方法在收集的数据中很容易显得比正常情况下重 100 倍。获得方法执行时间份额的有用数据的唯一方法是使用采样。You will need a stack for every thread and and with every
MethodEnteryou push the timestamp on the stack and onMethodExityou pop the timestamp and calculate the difference to the current time.Although you should keep in mind that reading timestamps or tickcounts and also the surrounding logic is comparatively time consuming. If you use something like this in some sort of profiler you will get results that make small fast methods appear very expensive. I.e. a
ByteBuffer.get()is likely to execute at least 10 times faster than your measuring code. Together with the distortion due to limited JIT compiling when JVMTI is active such methods can easily appear 100 times heavier in the collected data than they are under normal circumstances. The only way to get somewhat usable data of the execution time share of methods is to use sampling.