[Performance]Use threadGroup to compute threads state rather than ThreadMXBean

[hfutatzhanghb]

Environment: jdk-1.8
We encountered performance issue caused by jmx-exporter agent when the thread counts of HDFS Router becoming high.
We have found that it because exporter agent uses ThreadMXBean to compute threads state. It has big performance problem when thread count is high.

More detailes, please refer to https://issues.apache.org/jira/browse/HADOOP-16850

[zeitlinger]

Thanks for the contribution!

There's a build failure.

[hfutatzhanghb]

Thanks for the contribution!

There's a build failure.

Sir, thanks for reminding. Have fixed.

[zeitlinger]

Now fails at JvmThreadsMetricsTest.testGoodCase:86

[hfutatzhanghb]

Now fails at JvmThreadsMetricsTest.testGoodCase:86
Sir, In my local without this PR, there are also some failed unit tests. So i always use -DskipTests parameter to compile this project.

[zeitlinger]

Now fails at JvmThreadsMetricsTest.testGoodCase:86
Sir, In my local without this PR, there are also some failed unit tests. So i always use -DskipTests parameter to compile this project.

compare with the setup in gh actions - probably a different VM of maven version

[hfutatzhanghb]

Now fails at JvmThreadsMetricsTest.testGoodCase:86
Sir, In my local without this PR, there are also some failed unit tests. So i always use -DskipTests parameter to compile this project.

compare with the setup in gh actions - probably a different VM of maven version

Sir, After refer to source code. It is because we don't use ThreadMXBean to compute thread state, so the mocked ThreadMXBean is invalid.

[zeitlinger]

so the mocked ThreadMXBean is invalid.

can you fix it?

[hfutatzhanghb]

so the mocked ThreadMXBean is invalid.

can you fix it?

Sir, we can add a config to decide use which way to compute thread state. Then in unit test we still use ThreadMXBean

[zeitlinger]

what's your proposed fix for the build failure?

[jhominal]

According to the ThreadGroup class documentation:

A thread group represents a set of threads. In addition, a thread group can also include other thread groups. The thread groups form a tree in which every thread group except the initial thread group has a parent.

A thread is allowed to access information about its own thread group, but not to access information about its thread group's parent thread group or any other thread groups.

This change would break users that use nested thread groups - not all VM threads would be observed.