数据库连接池是资源复用机制，非线程池：它缓存已建立的SqlConnection实例，按连接字符串自动管理借还；线程池调度执行任务，不管理连接；对象池复用轻量对象，需手动Get/Return。三者目标相似但作用域、实现与风险完全不同。
数据库连接池是资源复用，不是线程池
很多人误以为 SqlConnection 的连接池（Connection Pooling）是靠多线程并发管理的，其实它和线程池完全无关。连接池本质是一组已建立、可复用的 SqlConnection 实例缓存，由 ADO.NET 在连接字符串相同、认证方式一致的前提下自动维护。每次调用 new SqlConnection(...) + Open()，底层并不真建新 TCP 连接，而是从池中“借”一个空闲连接；Close() 或 Dispose() 也不是断开网络，而是把连接“还”回池中待复用。
关键点：
- 连接池开关由连接字符串控制：
Pooling=true（默认开启），Pooling=false强制禁用 - 池大小受
Max Pool Size（默认 100）和Min Pool Size（默认 0）约束 - 不同连接字符串（哪怕只差一个空格或大小写）视为独立池，不共享连接
- 连接泄漏（没
Close/Dispose）会导致池耗尽，报错Timeout expired. The timeout period elapsed prior to obtaining a connection...
线程池是操作系统级调度资源，和对象生命周期无关
.NET 的 ThreadPool 是运行时维护的一组后台线程，用于执行短时、无上下文依赖的异步工作项（如 Task.Run、ThreadPool.QueueUserWorkItem）。它不管理任何业务对象（比如 SqlConnection 或自定义类实例），只负责把委托塞进队列、由空闲线程取出来执行。
常见误区：
- 不能用线程池“托管”数据库连接——线程执行完就退出，但连接必须显式归还池，否则泄漏
-
async/await默认在ThreadPool线程上恢复，但SqlConnection.OpenAsync()内部仍走连接池，二者正交 - 盲目调大
ThreadPool.SetMaxThreads对数据库吞吐无直接帮助，反而可能加剧锁竞争或内存压力
对象池是手动控制的轻量级复用机制，适合高频创建销毁的小对象
System.Buffers.ArrayPool 或 Microsoft.Extensions.ObjectPool.ObjectPool 是为减少 GC 压力设计的，典型用于 byte[]、StringBuilder、DTO 类等。它和连接池有相似目标（复用），但实现粒度更细、无自动回收逻辑，必须由开发者显式 Get() 和 Return()。
对比连接池：
- 对象池不感知“连接状态”，也不处理超时、验证、重建等——它只管内存块是否可用
- 数据库连接不能放进
ObjectPool：因为SqlConnection持有非托管资源（socket、事务上下文），且状态复杂（open/closed/broken），强行复用会引发InvalidOperationException或数据污染 - 适合池化的对象特征：构造开销大、生命周期短、无外部依赖、线程安全或可重置
var pool = ArrayPool<byte>.Shared;
var buffer = pool.Rent(1024);
try {
// 使用 buffer
} finally {
pool.Return(buffer); // 必须归还，否则池逐渐膨胀
}</byte>
三者唯一交集：都试图降低资源申请成本，但作用域和风险完全不同
连接池解决的是 TCP 连接建立/销毁的昂贵开销；线程池解决的是线程创建/切换的系统调用开销；对象池解决的是 GC 分配/回收小对象的内存开销。它们可以共存，但绝不能互相替代。
最容易被忽略的细节：
- 连接池中的连接可能因网络中断、SQL Server 重启而失效，下次复用时首次操作会抛异常（如
SqlException），需捕获并重试，不能假设“池里都是健康连接” - 对象池若未正确
Return，不会立即崩溃，但会缓慢耗尽池容量，表现为后续Get()返回更大数组或直接 new —— 表象像内存泄漏，实则是池管理失当 - 线程池线程执行阻塞 IO（如未用
async的SqlConnection.Open()）会导致线程饥饿，此时应优先改用异步 API，而非调大线程池
