共计 816 个字符，预计需要花费 3 分钟才能阅读完成。
连接池数量到底该配置成多少？
加了数据库连接池监控之后，就能够验证连接池数量是否配置的太大，因为之前都是乱配的，配了好几百，前面发现理论的沉闷连贯数量只有几个，所以配置数量个别只有几十个就能够了，因为
- 1. 并发申请没有那么高，可能就是个位数，高的时候是十位数，所以几十个就足够了。
- 2. 如果不思考并发数量，也只须要配置几十个，就是 cpu 的数量 *2，20 来个就能够了。
所以最终的后果是，如果没有并发，配置 cpu 数量 * 2 就能够了，20 个就足够了。如果有一点并发 (几十个)，就 30 到 50 个就够了。如果并发达到 50 个，就还能够再往上加到 100，然而最好不要超过 100，超过 100 就应该加机器了，因为并发太多，机器也解决不过去，会导致处理速度变慢，所以就要加机器，好比每个人要做的事件变少了，速度就变快了。
数据库连接池的连贯跟线程池有关系吗？
数据库连接池的连贯跟线程池有关系吗？没关系。
切换连贯，是切换线程吗？不是。
一个是切换线程上下文耗资源，因为要用户态和内核态切换，一个是创立数据库连贯耗资源，因为要三次握手。
所以，这两个货色没有任何关系，惟一的共同点就是复用对象，一个是线程对象，一个是数据库连贯对象。
为什么要复用对象？因为这两种对象，一个是创立代价太高，一个是切换代价太高 (线程数量少，切换次数就少)。
数据库连接池满了怎么办？
数据库连接池满了怎么办？阻塞。默认就是阻塞，直到连接池有新的连贯能够用。举个例子，比方配置的是 30，当初满了，第 31 个申请来了，这个时候就阻塞，直到 30 个连贯里有一个连贯曾经执行实现了，当初闲暇进去了，这个时候这个闲暇的连贯就去执行方才的第 31 个申请。
数据库连接池获取连贯的耗时？
个别失常状况就是几 ms，然而如果是新创建的连贯，就要耗时几百 ms，大略是 200ms 左右。如果是启动的时候，即连接池初始化的时候，获取连贯须要 1s，即差不多 1000ms。这些都是实在的监控数据，而且是生产环境的，测试环境也一样也差不多。
