[Potential Risk] FixedThreadPool creates unbounded queue when 'queues' parameter is negative

[QiuYucheng2003]

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 Version: Master branch (Source Code Analysis) JDK: 1.8+ OS: Cross-platform

Steps to reproduce this issue

While analyzing the source code of org.apache.dubbo.common.threadpool.support.fixed.FixedThreadPool, I noticed a potential risk in how the thread pool queue is initialized.

Code Location:
dubbo-common/src/main/java/org/apache/dubbo/common/threadpool/support/fixed/FixedThreadPool.java

Snippet:

return new ThreadPoolExecutor(threads, threads, 0, TimeUnit.MILLISECONDS,
        queues == 0 ? new SynchronousQueue<Runnable>() :
                (queues < 0 ? new LinkedBlockingQueue<Runnable>()  // <--- Potential Risk Here
                        : new LinkedBlockingQueue<Runnable>(queues)),
        new NamedInternalThreadFactory(name, true), new AbortPolicyWithReport(name, url));


Analysis: The code explicitly invokes new LinkedBlockingQueue<Runnable>() when the queues parameter is less than 0. The default constructor of LinkedBlockingQueue sets the capacity to Integer.MAX_VALUE.

If a user configures queues=-1 (or any negative value) in dubbo.properties or XML, the system creates an effectively unbounded queue. Under high load, requests will accumulate without limit, leading to OutOfMemoryError (OOM).


### What you expected to happen

Even if this logic is intended for backward compatibility, it poses a stability risk.

**Expected Behavior:**
1. At a minimum, a **WARN log** should be printed when `queues < 0` is detected, explicitly warning the user that an unbounded queue is being used.
2. Alternatively, consider enforcing a default hard limit (safeguard) instead of allowing a completely unbounded queue.

### Anything else

I found this issue during a static code analysis research project.

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

- [x] Yes I am willing to submit a pull request on my own!

### Code of Conduct

- [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct)

[shivvani-r]

Hello, i worked on this issue here.

Note to Reviewers:
I implemented Option 1 (Warning Log) from the issue description because it is safer and preserves backward compatibility for users currently relying on negative values. If you prefer enforcing a hard limit (Option 2), please let me know what the safe default limit should be, and I can update this PR.

[QiuYucheng2003]

Thanks for picking this up! I agree that Option 1 (Warning Log) is the safer approach right now to avoid breaking changes for existing users. Raising awareness via logs is a great first step.

[shivvani-r]

Thanks for picking this up! I agree that Option 1 (Warning Log) is the safer approach right now to avoid breaking changes for existing users. Raising awareness via logs is a great first step.

Thanks for the feedback! I'm glad to hear this approach aligns with what you expected.