[Proposal/Question] Provide mechanism to monitor thread states more efficiently
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
Hi Christoph, You might use ThreadGroup.enumerate(Thread[], recurse) after walking up the parents to the root ThreadGroup. $.02, Roger 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
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
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
Hi, (A bit too quick on the send button; need to reallocate if the array is not big enough). 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 = g.activeCount(); Thread[] threads = null; do { threads = new Thread[count+100]; 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
serviceability-dev is the mailing list for discussing java.lang.management APIs. Getting the stack trace is expensive. ThreadMXBean.getThreadInfos(ids) does not get the stack trace and locks information and is less expensive. A typical lightweight monitoring application does BCI and call Thread::getState and collect all other monitoring data. Mandy On 10/27/17 8: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
participants (3)
-
Christoph Dreis
-
mandy chung
-
Roger Riggs