Using ThreadPoolRuntime, I could get a throughput attiribute that means "The mean number of requests completed per second". It's not what I want. I want to get realtime figure that is not the mean number.
Unless this is a custom work manager's thread pool, the number you're going to get back isn't going to be terribly meaningful. And even in the case of a custom thread pool assigned to your particular application component (EJB, WAR file, etc) then the number still isn't likely to mean what you're looking for.
The thread pool is used to perform all work for that component (or in the case of the default thread pool, all work for the server, both internal and client-driven. This means that requests of wildly different 'cost' in terms of CPU and execution time go through the same pool.
What is the problem that you're trying to solve? Is it an understanding of how many requests per second are occurring for particular application components? You might want to look at WLDF as an alternative source for this kind of data, although in either case you'll need to post-process information to get something useful.