查看代码，这是处理每个传入请求所需的挂钟经过时间的累积毫秒数。System.currentTimeMillis()因此，对于始终忙碌的单个 http 连接器线程（在具有稳定系统时钟的系统上）的此测量值的增量不应超过每分钟 60,000。但是，对于GlobalRequestProcessor，它的增长速度可能比这要快得多，具体取决于正在处理的并发请求数。
如果在给定的一分钟内，您在一秒钟内收到 100 个满足的请求，另外 100 个在返回值之前阻塞 10 秒的请求，则该计数器GlobalRequestProcessor将在该分钟内增加 100x1x1000 + 100x10x1000 = 1,100,000。
请注意，由于这会测量挂钟经过的时间，因此如果您的服务器上的时钟向前跳，它将导致您错误地获得经过时间的大值。也就是说，如果在给定 servlet 的处理过程中时间向前跳了一分钟，并且 servlet 用了 20 秒来处理请求，那么这个度量将告诉您 servlet 用了 80 秒来处理请求。如果您在 DST“Spring Forward”发生时碰巧有一个实时请求，那么您将被告知该请求花费了一个多小时，这意味着此 JMX 测量将增加一个多小时。对于我查看的版本，如果时钟向后跳，您最终可以递减这个计数器！希望 Tomcat 6System.nanoTime()能够避免这种对系统时钟稳定性的依赖。
在 Java 1.5 之前，没有一种很好的方法来测量真实的经过时间（与经过的挂钟时间相反）。由于 Tomcat 6.x 和更早版本都不需要 Java 5 或更高版本，因此它们实际上没有办法测量毫秒以外的任何东西，或者测量与时钟变化无关的真实经过时间。（除非使用反射来做到这一点。我没有注意到，但我也没有搜索过。）