Java中线程用户时间和线程CPU时间的区别
ThreadMXBean 有两种检索线程时间使用情况的方法：
两者有什么区别？
更新 2：如果我能够链接到 javadoc，请不要引用它们 - 我已经阅读过它们。
更新：这里有一些代码，我试图用它们来了解这些时间的含义，但收效甚微：
ThreadMXBean threadMXBean = ManagementFactory.getThreadMXBean();
threadMXBean.setThreadContentionMonitoringEnabled(true);
long mainThreadId = getMainThreadId(threadMXBean);
logTimes("Start", threadMXBean, mainThreadId);
URL url = new URL("https://hudson.dev.java.net");
URLConnection connection = url.openConnection();
connection.getContent();
logTimes("After loading", threadMXBean, mainThreadId);
输出为：
Start Tue Jun 16 16:13:40 EEST 2009 Cpu time : 80, user time: 60, waited: 0, blocked: 0
After loading Tue Jun 16 16:13:43 EEST 2009 Cpu time : 1,020, user time: 960, waited: 0, blocked: 0
因此 cpu 和用户时间之间的差异从 20 毫秒增加到 60 毫秒。 这是因为使用 HttpUrlConnection 确实包含一些网络 I/O 吗？
The ThreadMXBean has two methods for retrieving thread time usage:
What is the difference between the two?
Update 2: If I'm able to link to the javadocs, please don't quote them - I've read them already.
Update: here's some code which I tried to use to learn what these times mean, with little success:
ThreadMXBean threadMXBean = ManagementFactory.getThreadMXBean();
threadMXBean.setThreadContentionMonitoringEnabled(true);
long mainThreadId = getMainThreadId(threadMXBean);
logTimes("Start", threadMXBean, mainThreadId);
URL url = new URL("https://hudson.dev.java.net");
URLConnection connection = url.openConnection();
connection.getContent();
logTimes("After loading", threadMXBean, mainThreadId);
and the output is:
Start Tue Jun 16 16:13:40 EEST 2009 Cpu time : 80, user time: 60, waited: 0, blocked: 0
After loading Tue Jun 16 16:13:43 EEST 2009 Cpu time : 1,020, user time: 960, waited: 0, blocked: 0
So the difference between cpu and user time increased from 20 to 60 milliseconds. Is that because using a HttpUrlConnection does include some network I/O?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
正如您链接到自己的 API 文档已经指出的那样
getThreadCpuTime
如果 JVM 的实现区分用户模式和内核模式时间，则两个函数的结果可能会有所不同。
此外，该值仅精确到纳秒，并且如果偏移量> 则该值存在溢出问题。 2^63。 JVM 还必须支持测量当前线程的 CPU 时间并且必须启用它。
在 Win32 上，返回值应与从 GetThreadTimes 函数
getThreadUserTime()->lpUserTime * 100//或者像这样的getThreadCpuTime()->(lpKernelTime + lpUserTime) * 100//或类似的内容以及对 用户模式与内核模式
As the API docs you linked to yourself already point out
getThreadCpuTime
If the implementation of the JVM distinguishes between user mode and kernel mode time there could be a difference in the results of the two functions.
Further the value is only precise to the nanosecond and the value has an overflow problem if the offset is > 2^63. The JVM must also support measuring the CPU time for the current thread and it must be enabled.
On Win32 the return values should be the same as the ones you get from the GetThreadTimes Function
getThreadUserTime()->lpUserTime * 100//or something like thisgetThreadCpuTime()->(lpKernelTime + lpUserTime) * 100//or something like thisAnd a more clear reference to User Mode vs Kernel Mode
javadoc 中对此进行了解释:-)。
不同之处在于 getThreadCpuTime 还包括线程使用 CPU 但不处于用户模式的时间。 这就像在设备驱动程序内部、轮询 I/O 或类似的事情。
It's explained in the javadocs :-).
The difference is that getThreadCpuTime also includes time that the thread used the CPU but was not in user mode. That would be things like being inside a device driver, polling for I/O or similar.