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?
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
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.