数据库连接池是资源复用，不是线程池
很多人误以为
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<t></t>或
Microsoft.Extensions.ObjectPool.ObjectPool<t></t>是为减少 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); // 必须归还，否则池逐渐膨胀
}
三者唯一交集：都试图降低资源申请成本，但作用域和风险完全不同
连接池解决的是 TCP 连接建立/销毁的昂贵开销；线程池解决的是线程创建/切换的系统调用开销；对象池解决的是 GC 分配/回收小对象的内存开销。它们可以共存，但绝不能互相替代。
最容易被忽略的细节：
连接池中的连接可能因网络中断、SQL Server 重启而失效，下次复用时首次操作会抛异常（如SqlException），需捕获并重试，不能假设“池里都是健康连接” 对象池若未正确
Return，不会立即崩溃，但会缓慢耗尽池容量，表现为后续
Get()返回更大数组或直接 new —— 表象像内存泄漏，实则是池管理失当 线程池线程执行阻塞 IO（如未用
async的
SqlConnection.Open()）会导致线程饥饿，此时应优先改用异步 API，而非调大线程池
