[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-serviceability-dev
Subject: Re: [Proposal/Question] Provide mechanism to monitor thread states more efficiently
From: mandy chung <mandy.chung () oracle ! com>
Date: 2017-10-27 20:54:29
Message-ID: 635af57f-86d0-3983-091d-74cf4a47a9df () oracle ! com
[Download RAW message or body]
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
>
[Attachment #3 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
serviceability-dev is the mailing list for discussing
java.lang.management APIs.<br>
<br>
Getting the stack trace is expensive.
ThreadMXBean.getThreadInfos(ids) does not get the stack trace and
locks information and is less expensive.<br>
<br>
A typical lightweight monitoring application does BCI and call
Thread::getState and collect all other monitoring data. <br>
<br>
Mandy<br>
<br>
<div class="moz-cite-prefix">On 10/27/17 8:23 AM, Christoph Dreis
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:000001d34f37$7fb5c1d0$7f214570$@freenet.de">
<pre wrap="">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
</pre>
</blockquote>
<br>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic