[Bug] NamedThreadFactory might be optimized by removing redundant field mGroup

[zrlw]

Pre-check

• I am sure that all the content I provide is in English.

Search before asking

• I had searched in the issues and found no similar issues.

Apache Dubbo Component

Java SDK (apache/dubbo)

Dubbo Version

Dubbo 3.3

Steps to reproduce this issue

1. it's unnecessary that getting thread group by NamedThreadFactory, because the thread group could be determined by Thread#init:

private void init(ThreadGroup g, Runnable target, String name,
                      long stackSize, AccessControlContext acc,
                      boolean inheritThreadLocals) {
        if (name == null) {
            throw new NullPointerException("name cannot be null");
        }

        this.name = name;

        Thread parent = currentThread();
        SecurityManager security = System.getSecurityManager();
        if (g == null) {
            /* Determine if it's an applet or not */

            /* If there is a security manager, ask the security manager
               what to do. */
            if (security != null) {
                g = security.getThreadGroup();
            }

            /* If the security doesn't have a strong opinion of the matter
               use the parent thread group. */
            if (g == null) {
                g = parent.getThreadGroup();
            }
        }

System.getSecurityManager() should not be called by NamedThreadFactory again, The heart of the Security Manager is a complex access-control algorithm which often imposes an unacceptable performance penalty and System::getSecurityManager always to return null after Java 18.
https://bugs.openjdk.org/browse/JDK-8264713
2. sometimes EagerThreadPoolExecutorTest.testEagerThreadPoolFast failed because of awaitting timeout (> 10 seconds) for EagerThreadPoolExecutor that used NamedThreadFactory as it's threadFactory ,
https://github.com/apache/dubbo/actions/runs/13624514963/job/38079718397

2025-03-03T06:18:30.2462744Z [INFO] Running org.apache.dubbo.common.threadpool.support.eager.EagerThreadPoolExecutorTest
2025-03-03T06:18:41.0029201Z [ERROR] Tests run: 5, Failures: 0, Errors: 1, Skipped: 1, Time elapsed: 10.76 s <<< FAILURE! -- in org.apache.dubbo.common.threadpool.support.eager.EagerThreadPoolExecutorTest
2025-03-03T06:18:41.0031222Z [ERROR] org.apache.dubbo.common.threadpool.support.eager.EagerThreadPoolExecutorTest.testEagerThreadPoolFast -- Time elapsed: 10.04 s <<< ERROR!
2025-03-03T06:18:41.0039551Z org.awaitility.core.ConditionTimeoutException: Condition with Lambda expression in org.apache.dubbo.common.threadpool.support.eager.EagerThreadPoolExecutorTest was not fulfilled within 10 seconds.
2025-03-03T06:18:41.0041273Z 	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
2025-03-03T06:18:41.0042140Z 	at org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
2025-03-03T06:18:41.0042993Z 	at org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
2025-03-03T06:18:41.0043871Z 	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:1006)
2025-03-03T06:18:41.0044730Z 	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:975)
2025-03-03T06:18:41.0046173Z 	at org.apache.dubbo.common.threadpool.support.eager.EagerThreadPoolExecutorTest.testEagerThreadPoolFast(EagerThreadPoolExecutorTest.java:139)
2025-03-03T06:18:41.0047709Z 	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
2025-03-03T06:18:41.0048408Z 	at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
2025-03-03T06:18:41.0049095Z 	at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
2025-03-03T06:18:41.0049517Z 

What you expected to happen

the time elapsed of EagerThreadPoolExecutorTest shoule be less than 5 seconds.

Anything else

No response

Are you willing to submit a pull request to fix on your own?

• Yes I am willing to submit a pull request on my own!

Code of Conduct

• I agree to follow this project's Code of Conduct