[Proposal/Question] Provide mechanism to monitor thread states more efficiently

[Roger Riggs]

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