是的，这是有意的。引用文档：
此属性控制允许池达到的最大大小，包括空闲和使用中的连接。基本上，此值将确定到数据库后端的最大实际连接数。合理的值最好由您的执行环境确定。当池达到此大小，并且没有空闲连接可用时，对的调用
getConnection()将connectionTimeout在超时之前最多阻塞数毫秒。请阅读有关池大小的信息。 默认值：10
所以基本上，当所有300个连接都在使用，而你试图让你的301
ST连接，阿光不会创建一个新的（因为
maximumPoolSize是绝对最大值），但它会宁愿等待（默认为30秒），直到连接再次可用。
这也解释了为什么会遇到上述异常，因为默认值（未配置时
maximumPoolSize）是10个连接，您可能会立即达到。
要解决此问题，您必须找出阻止这些连接超过30秒的原因。即使在有1000个并发用户的情况下，如果您的查询最多花费几毫秒或几秒钟也没有问题。
增加泳池大小
如果要调用需要很长时间的复杂查询，则有几种可能。第一个是增加池的大小。但是， 不建议这样做 ，因为用于计算最大池大小的推荐公式为：
connections = ((core_count * 2) + effective_spindle_count)
引用关于池大小调整文章：
多年来在许多基准测试中保持良好状态的公式是，为了获得最佳吞吐量，活动连接的数量应接近
((core_count * 2) +effective_spindle_count)。即使启用了超线程，核心数也不应包括HT线程。如果完全缓存了活动数据集，则有效主轴数为零，并且随着高速缓存命中率的降低，有效主轴数将接近实际主轴数。…到目前为止，尚未对该公式与SSD的配合情况进行任何分析。
如同一篇文章中所述，这意味着带有1个硬盘的4核服务器应该只有大约10个连接。即使您可能拥有更多的核心，我还是假设您没有足够的核心来保证您正在建立的300个连接，更不用说进一步增加它了。
增加连接超时
另一种可能性是增加连接超时。如前所述，当所有连接都在使用中时，默认情况下它将等待30秒，这是连接超时。
您可以增加此值，以便应用程序等待更长的时间才能进入超时状态。如果您的复杂查询需要20秒，并且您拥有300个和1000个并发用户的连接池，则理论上应将连接超时至少配置为
20* 1000 / 300 = 67 seconds。
但是请注意，这意味着您的应用程序可能需要很长时间才能向用户显示响应。如果您有67秒的连接超时，并且在复杂查询完成之前还有20秒，则您的用户可能需要等待一分半钟。
缩短执行时间
如前所述，您的主要目标是找出为什么查询需要这么长时间。连接池为300，连接超时为30秒，并发用户为1000，这意味着您的查询至少需要 9秒
才能完成，这很多。
尝试通过以下方法缩短执行时间：
- 添加适当的索引。
- 正确编写查询。
- 改善数据库硬件（磁盘，核心，网络等）
- 通过引入分页来限制要处理的记录量。
- 分工。看一下查询是否可以拆分为较小的查询，这些查询会产生中间结果，然后可以在其他查询中使用该结果，依此类推。只要您不在事务中，连接之间的连接就会被释放，从而使您以牺牲一些性能为代价为多个用户提供服务。
- 使用缓存
- 预先计算结果：如果您要进行大量的资源计算，则可以尝试在不经常使用该应用程序的时候预先计算结果，例如。晚上将这些结果存储在可以轻松查询的其他表中。
- …
