the more threads the better, if your business logic is all computational (CPU-intensive), does not involve IO, and has only one core. It is certain that one thread is the best. If there is one more thread, there will be more thread switching calculation. CPU cannot completely focus its computing power on business computing. The more threads it has, the lower the CPU utilization (time spent in business computing / total time).

but in the WEB scenario, the business is not CPU-intensive, but IO-intensive, and a thread is not suitable. If a thread transfers the computing power of CPU to other threads while waiting for data, it can also make full use of CPU resources. But there is also a limit to the number of threads. In general, there is a formula for the number of threads:
the best number of starting threads = [task execution time / (task execution time-IO waiting time)] * the number of CPU cores
exceeds this number, CPU has to carry out redundant thread switching and waste computing power. Below this number, CPU has to wait for IO, resulting in unsaturated computing power. In short, it is necessary to extract the computing power of CPU as much as possible.

if your CPU is saturated and there is no extra thread switching waste, then this is the perfect state of your service. If you increase the concurrency, it is bound to cause performance degradation.

threads has no direct effect on the maximum concurrency, but the task computing time is the root cause of maximum concurrency .
when the execution time of a task decreases, the server processes more requests per second, that is, more concurrency is supported. For example, if you simply return ok; on the server, the Tomcat on the server can achieve 5000 or even 10000 concurrency if you are a little more normal. However, in most web applications, the task execution time is not too short, and it also involves database operations, so in most cases the highest concurrency of Tomcat is only a few hundred.

in addition, for the same task execution time, the maximum concurrency is also different in different IO and threading models.
in the BIO model, the number of threads = the number of links, the increase in concurrency will result in an increase in the number of threads to a certain extent, CPU will take a little time to switch on.
in the NIO model, concurrency does not cause the increase of threads, but can maintain the optimal number of threads, thus improving the utilization of CPU and the maximum concurrency to some extent.
Tomcat has implemented the NIO model, which needs to be configured in version 7.x, and version 8.x uses NIO as the default model.

add:
the answer above is not good, please add.
the subject should ask, what is the reason why tomcat can only support hundreds of concurrency? In fact, it does not have much to do with threads. For the time being, the number of concurrency is measured by the number of requests handled by the server within 1 second . Then the maximum concurrency is the maximum number of requests that the server can handle within 1 second . Obviously, the shorter the average processing time of a single request, the higher the maximum concurrency. The average request processing time directly affects the height of maximum concurrency. In most cases, the average time for Tomcat to process requests is not too short, and sometimes database operations are designed, so in most cases the highest concurrency of Tomcat is only a few hundred.
then the thread model affects the average processing time of Tomcat requests, either because there are too few threads that cause CPU to wait and increase the average processing time, or because there are too many threads that cause CPU to spend a certain period of time to switch threads and extend the average processing time. Therefore, a reasonable setting of the number of threads can improve the maximum concurrency to a certain extent.
so how to increase maximum concurrency? The idea of
is, of course, to reduce the average request processing time, such as optimization algorithm, static and dynamic separation, caching, async, and so on.

you can adjust the number of threads yourself. For example, you can also adjust to thousands.

but the exact amount of adjustment depends on the nature of your business, and it's not the more threads the better.

threads leads to frequent context switching, which also has a significant impact on performance.

1: the operating system has a limit on the number of threads.
2: when there are many threads, there is frequent context switching, and a large part of the time is spent on context switching rather than responding to user requests.
3: network card transmission speed.

the concurrency of a stand-alone system is certain. In practice, if a high concurrency is needed, it can be deployed in a cluster to provide services uniformly.

the core reason is that it is free. You can compare other paid versions of Java EE containers. The value is the core competitiveness