Hi,
I was just pointing out there already is access to the information you
are requesting
without adding a new API.
ThreadGroup.activeCount() provides the number of active threads.
Of course, threads come and go asynchronously.
Yes, the Thread array has to be allocated by the caller and may be too
small but
the caller can check the return count against the array size to determine if
any threads have been omitted and retry with a larger array.
For example, a Stream of threads:
static Stream<Thread> a(ThreadGroup g) {
int count = 0 ;
Thread[] threads = new Thread[g.activeCount() + 100];
do {
count = g.enumerate(threads, true);
} while (count >= threads.length);
return Arrays.stream(threads, 0, count);
}
Roger
On 10/27/2017 12:12 PM, Christoph Dreis wrote:
Hi Roger,
You might use ThreadGroup.enumerate(Thread[], recurse) after walking up
the parents to the root ThreadGroup.
Thanks. Isn't this method silently dropping threads in case it can't hold what
you specified upfront as an array? Apart from that: Would it be a candidate for
live-monitoring - e.g. what's the overhead of it based on your experience
compared to other approaches?
And to make it more clear - preferably my suggestion would move into the
ThreadMXBean interface as well to be fetchable via the management interfaces,
which I think has no ThreadGroup.enumerate(Thread[], recurse) alternative at
the moment. Am I right?
Cheers,
Christoph
On 10/27/2017 11:23 AM, Christoph Dreis wrote:
Hey,
I don't know if this is the correct mailing list for this specific topic.
Please let me know in case it isn't.
I'm currently trying to improve the live-monitoring of an application
and would like to get a simple overview of how many threads are in
state RUNNABLE, BLOCKED and so on.
For this I need to get all threads in the first place to iterate on. I
know of two ways how to do that programmatically:
1) ThreadMXBean.dumpAllThreads() which gives me an array of ThreadInfo
objects on which I could call getThreadState()
2) Thread.getAllStackTraces().keySet() which gives me a Set of Thread
objects on which I could call getState()
Either 1) or 2) both dump the threads, which seems like a lot of
overhead for this task and therefore presumably aren't supposed to be
executed every X seconds. Using reflection to make the private native
Thread.getThreads() available - if that's even possible(?) - doesn't
seem correct either. Is there an alternative for this?
If not, I'd like to suggest the addition of two in my opinion more
lightweight alternative APIs in Thread and/or ThreadMXBean (ThreadImpl).
Here is what I'm thinking of in a rough and untested state:
public static Map<Thread.State, Integer> getAllThreadStateCounts() {
// Get a snapshot of the list of all threads
Thread[] threads = getThreads();
Map<Thread.State, Integer> m = new
EnumMap<>(Thread.State.class);
for (int i = 0; i < threads.length; i++) {
m.merge(threads[i].getState(), 1, Integer::sum);
}
return m;
}
public static int getThreadCountByState(Thread.State state) {
// Get a snapshot of the list of all threads
Thread[] threads = getThreads();
int counter = 0;
for (int i = 0; i < threads.length; i++) {
if (state == threads[i].getState()) {
counter++;
}
}
return counter;
}
Is this something that could be worthwhile? Let me know what you think.
Cheers,
Christoph
