学习背景
最近一直研究已学知识的底层，到数据库连接池这块时，碰巧前段时间也刚好重温了设计模式，于是就产生了一个疑问，对数据库的连接为什么采取了线程池而不是把连接设置为单例模式全局共享？
去很多平台看了很多帖子和回答，但哪怕是StackFlow也没给出一个让我信服的答案。
大家只是在不断重述为什么采取了线程池："因为每次操作都需要建立连接,操作后再关闭，是一个十分重的操作，当高并发时耗时耗资源。所以采用了连接池,提前建立多个连接, 当有操作请求发来时，直接到连接池里取空闲连接就行,节省了建立连接和关闭连接的开销。"
但我的疑问仍旧没有解除啊啊啊啊，既然连接的建立和销毁浪费资源和时间，那么我把建立连接和关闭连接的部分封装成一个单例对象全局共享不就行了吗，为什么非得要用连接池？
好吧，那我就只能结合能查到的一些零零碎碎和AI的回答，总结下自己的理解。
1.单例模式和连接池都具备的优点
理所当然，它们都能节省建立连接和关闭连接的开销，这是最重要的优点。
2.单例存在的问题
- 单例模式只拥有一个连接，如果系统长时间都没有用户访问数据库，那么MySQL会回收连接。虽然我们可以在设计单例类的时候，对连接是否失效需要重连进行逻辑判断，但总的来说不太优雅。
- 单例只会维护一个连接实例，如果高并发场景下，可能导致性能瓶颈或连接的争用情况。
3.连接池的好处
a. 连接的生命周期
- 连接池的设计：连接池不仅仅是为了减少连接的创建和销毁，它还管理了连接的生命周期。当某些连接长时间处于闲置状态时，连接池可以自动检测这些连接的可用性，并在必要时关闭它们。而单例模式不会处理这些长时间未使用连接的管理问题，可能导致无效连接（如过期连接）的问题。
b. 并发处理
- 负载均衡：连接池使得多个请求可以共享连接资源，这样在高并发访问中能够充分利用有限的数据库连接。单例只会维护一个连接实例，如果有多个线程或请求同时访问，可能导致性能瓶颈或连接的争用情况。
c. 连接复用
- 提升性能：连接池能够快速复用连接，减少重复连接的时间开销。
d. 透明性和灵活性
- 更强的管理能力：连接池的实现通常会提供连接的检查、最大连接数限制、连接超时处理等高级特性，这些都不是单例所能轻易实现的。连接池提供更灵活的连接管理策略，可以根据业务需求动态调整连接的数量和状态。
e. 适应高负载场景
- 故障恢复与容错：许多连接池实现包含故障检测、透明重连等功能。当连接失败时，连接池可以自动替换这些无效连接。而简单的单例模式则无法做到这些，可能会导致系统的不稳定。
f. 资源管理
- 数据库连接是有限资源：在大型应用中，数据库连接的数量是有限的，通过连接池，程序能够有效配置和收回连接，避免连接过多导致数据库负载过重的问题。而单例模式可能无法有效控制连接的数量，反而可能导致连接资源的浪费。
