跳至主要內容

线程池、连接池、IO、序列化与压缩：资源池如何形成瓶颈

高谷深陵大约 16 分钟约 4695 字
线程池、连接池、IO、序列化与压缩
线程池、连接池、IO、序列化与压缩高清原图

把应用线程池从100调到200，可能只会让更多线程等待同样的20个数据库连接。数据库查询已经结束时，连接又可能被响应组装继续占着。资源池调优需要区分三个时刻：工作开始等待、拿到资源、归还资源。

编码与压缩也发生在这条链路上。一份响应压缩后只剩十分之一字节，会减少网络传输，却增加CPU与临时对象；如果压缩期间仍持有数据库连接，局部的网络优化还会延长连接占用。

执行槽、连接与字节流各自承担什么

线程池的接纳与执行

线程池复用worker来执行任务，同时决定没有空闲worker时任务放在哪里。对于 ThreadPoolExecutor，任务接纳的主要顺序是：

当前 worker 数小于 corePoolSize → 尝试创建 worker
否则 → 尝试放入工作队列
队列不能接收 → 尝试增加 worker，最多 maximumPoolSize
仍不能接收或执行器已关闭 → 执行拒绝策略

因此，无界队列常让任务一直排队，maximumPoolSize 在通常运行中没有机会发挥作用；有限队列会让扩线程和拒绝更早出现。排队任务还可能持有请求体、上下文和回调对象。队列长度除了影响等待，也形成内存保留量。上述接纳规则和拒绝策略见 ThreadPoolExecutor API。

拒绝策略会改变调用语义。AbortPolicy抛出异常，调用方有机会转换为过载响应；CallerRunsPolicy让提交线程执行任务，可以减慢生产速度，也可能把耗时工作移到HTTP接入线程或事件循环；静默丢弃则需要非常明确的业务容忍条件。不能仅因应用“不再抛异常”就采用丢弃策略。

阻塞任务、短CPU任务和长批处理混在同一队列时，长任务可能推迟本来很短的请求。是否分池，要按资源需求和服务优先级判断，同时计算所有池加起来的线程、内存与下游访问量。每个功能单独建一个大池，会把全局约束藏起来。

连接池管理的是可复用会话

连接池中的对象通常对应已建立的网络连接与数据库会话。借用连接的时间包括执行SQL、读取结果，以及借出后发生的其他工作。应用调用池化连接的 close()，通常是把它归还池，而不是每次关闭底层Socket。

一次请求的典型范围如下：

HTTP worker 占用 ────────────────────────────────────┐
  等待连接 ────┐                                    │
               借出连接 ────────────────── 归还      │
                 SQL执行 ── 读取行 ── 对象映射        │
                                      JSON编码 ──── 响应

将JSON编码放在归还连接之后，可以缩短连接持有时间，前提是结果已完整读取且事务允许这样组织。流式读取大量结果时，游标和事务可能必须保持到消费结束；这时应单独限制导出并发，不能一边慢速发送给客户端、一边无限占用普通请求的连接额度。

连接池参数描述不同动作。以实验采用的 HikariCP 7.0.2 为例：

参数主要作用应与什么一起判断
maximumPoolSize池内连接数量上限，包含空闲与借出数据库总连接与活动查询能力
minimumIdle尝试维持的空闲连接数量预热成本、突发连接创建
connectionTimeout等待可用连接的最长时间请求剩余期限、池等待分布
validationTimeout连接可用性检查的时间限制驱动和网络行为
maxLifetime连接允许存在的生命周期数据库、代理的连接寿命限制

maxLifetime到期的借出连接通常在归还后退休，正在执行的慢SQL不会因此被强制终止。连接泄漏检测主要提供诊断日志，业务正在使用的连接仍需由应用归还。

阻塞、非阻塞与异步

阻塞调用让当前线程等到操作可继续；非阻塞调用可以在暂时没有数据时立即返回；异步API通过回调或Future报告后续结果。这三个维度要结合具体API解释。例如使用异步HTTP客户端后马上调用 join()，当前调用线程仍然在等待。

Linux的epoll报告文件描述符上是否可以进行IO，应用收到就绪事件后仍要实际读写、解析和处理数据。事件循环适合及时处理短工作；在其线程里执行长时间压缩、阻塞JDBC或大JSON解析，会延迟同一个循环上的其他连接。就绪通知、水平/边缘触发规则见 Linux epoll手册。

虚拟线程降低了大量阻塞任务对平台线程的占用成本，但数据库连接、CPU和远程限额仍需要单独控制。使用虚拟线程时，通常按任务创建虚拟线程，通过Semaphore等限制稀缺资源，而不是再用一个“虚拟线程池”制造额外队列。设计目的与使用方式见 Oracle虚拟线程指南。

文件IO的字节数、操作数与缓存

带宽描述每秒传输多少字节，IOPS描述每秒完成多少次IO操作。读取1MiB数据，可以是一笔较大的顺序读取，也可以分成256笔4KiB读取；若小块还分散在不同位置，存储设备、文件系统和请求调度会承担不同成本。比较磁盘性能时，同时说明块大小、顺序或随机、读写比例、队列深度与延迟，只有“每秒多少MB”无法还原负载。

Linux普通文件读写通常经过页缓存。热数据可能从内存返回，冷读则需要等待存储；一次刚启动的测试与反复读取同一文件的测试因此可能经过不同路径。页缓存还占用系统内存，与Java堆属于不同的统计范围。缓存与回写机制见 Linux内存概念。不要在共享机器上随意清空系统缓存来制造冷读；可在隔离实验中用明确工作集和预热步骤控制条件。

写调用成功、数据进入页缓存和满足持久化要求是不同阶段。普通缓冲写入可以先返回，随后再回写；fsync用于请求将文件修改同步到存储，文件新增或重命名还可能涉及目录同步。具体语义与限制见 Linux fsync手册。把持久化等待移出计时范围会使结果更快，也改变了测量完成点。

零拷贝通常指减少某些用户态与内核态之间的数据复制。例如Linux sendfile可以在文件描述符之间传输数据，减少应用先读入缓冲、再写出的步骤；支持条件见 sendfile手册。它仍然需要底层IO和协议处理；动态JSON生成、压缩或TLS加密是否能走相同路径，取决于具体实现。评估整段传输时，这些计算仍应计入各自的耗时。

等待、超时与编码成本怎样互相影响

超时应覆盖自己的阶段

一次数据库调用可能经历等待连接、建立连接、发送SQL、数据库执行、读取响应。应先知道时间花在哪一段，再选择参数：

阶段典型控制超时之后继续检查
获取池中连接Hikari connectionTimeout是否拿到连接、借出数是否耗尽
建立数据库连接驱动 connectTimeout网络、认证、TLS与服务监听
数据库执行语句PostgreSQL statement_timeoutSQLSTATE、事务状态、锁等待
Socket读取驱动 socketTimeout连接是否关闭、服务端是否仍在执行
完整业务请求上层deadline下游剩余预算、取消传播和业务结果

pgJDBC的连接与Socket参数单位、默认值和行为见驱动连接参数。JDBC Statement.setQueryTimeout要求驱动尝试取消超时语句，具体实现仍要核对驱动；API规则见 Statement。

各阶段都设“3秒”会让串行调用累积超过上层3秒期限。更合适的做法是从请求剩余时间分配预算，预留响应处理时间，并在重试前重新计算剩余额度。超时返回给调用方以后，还要确认后台任务是否真正取消、连接是否可继续使用、写操作结果是否需要查询。

连接池等待的成因

连接等待增长，通常有两类直接原因：借用请求变多，或每次借出持续更久。先观察活跃连接数、等待者数、获取耗时和持有耗时，再查看SQL执行与事务范围。若活跃数一直很高，而数据库几乎不忙，应用可能在拿着连接等待别的资源。

用 Little定律 可以核对平均占用：借用速率乘平均持有时间应接近平均借出数。该式帮助发现口径或持有时间变化；实际池上限还要由突发分布和数据库承载能力决定。

所有实例的连接池会共同作用于数据库。例如20个实例各配置50个连接，仅这一组就可能建立1,000个会话；再加后台任务、迁移工具和运维会话，需要留出数据库管理余量。应用扩容之前应重新计算这笔总账。

序列化与压缩改变了什么

序列化把对象转换为协议字节，反序列化再按协议恢复字段。JSON的字符数、UTF-8字节数和Java对象占用不同；“订单”有两个Unicode基本多文种平面字符，UTF-8需要6字节。数字格式、字段名、空值策略、重复结构和字符串内容都会影响编码体积。

优化时先固定输出契约。删字段、降低数字精度或把缺失值改为默认值，可能让结果更小更快，同时改变消费者得到的含义。兼容性校验应覆盖字段、类型、字符编码与集合元素，不只判断“能解析”。Jackson的对象绑定与树模型入口见 jackson-databind官方说明。

压缩进一步用CPU换取较小字节流。重复文本常能明显缩小，随机或已压缩数据可能几乎不缩小，甚至增加格式头与校验信息。选择压缩阈值时，应把编码、压缩、传输、解压与对象恢复放到同一次对照中，并记录CPU与分配量；单独比较网络字节不足以推导总延迟。

批量和缓冲也有相同取舍。合并小写入可以减少系统调用，但等待凑批会增加首字节延迟；整份响应缓存在内存里方便压缩，却可能让大导出占据大量堆空间。流式发送降低部分峰值内存，但需要处理背压、取消和尚未完成的事务。

在PostgreSQL上区分池超时与语句超时

编译并启动实验

下载完整连接池与编码实验包，解压进入 pool-io-lab。使用Linux、Docker Engine/Compose，宿主普通用户具有Docker权限。实验固定Maven3.9.12、Temurin25、HikariCP7.0.2、pgJDBC42.7.13、Jackson2.20.1和PostgreSQL18.6；源码按Java17编译。

构建缓存放在当前解压目录，避免非root Maven无法写入默认root目录：

mkdir -p .m2
docker run --rm --user "$(id -u):$(id -g)" \
  -e HOME=/tmp -e MAVEN_CONFIG=/tmp/.m2 --entrypoint mvn \
  -v "$PWD:/lab" -v "$PWD/.m2:/cache" -w /lab \
  maven:3.9.12-eclipse-temurin-25 -B -ntp \
  -Dmaven.repo.local=/cache clean verify dependency:copy-dependencies
docker compose up -d --wait pg
docker compose run --rm lab

Maven成功后应出现 target/classes/PoolIoLab.class 和 target/dependency。这个工程将集成断言放在可执行主程序内，因此 verify编译成功后还必须执行 docker compose run；没有运行主程序时，尚未验证数据库行为。

数据库只在Compose网络内开放；初始化入口准备目录后，数据库进程以postgres身份运行，实验应用使用受限的lab数据库账号，Java容器使用10001。数据库数据放在本组tmpfs中，仅供可丢弃实验使用。初始化失败时查看 docker compose logs pg，不要将认证或断连错误当成预期超时。

先占住两条连接，再借第三条

池最大值为2，程序在同一个作用域内实际借出两条连接，再发起第三次借用：

config.setMaximumPoolSize(2);
config.setConnectionTimeout(300);
try (var first = pool.getConnection();
     var second = pool.getConnection()) {
    // 第三次 getConnection() 等待后抛 SQLTransientConnectionException
}
// 前两条已归还，重新借用并执行 SELECT 42

正常实验输出应包含 pool_acquire_timeout、异常类型 SQLTransientConnectionException 和 active=2，随后 pool_release_recovery value=42。等待大致围绕配置的300 ms，调度会使观察值变化。程序检查具体异常类型及活跃数，而没有把任意数据库异常视为成功。

第三次借用还没有拿到连接，等待发生在SQL执行之前。归还前两条连接，再次借用并查询成功，才完成了从池耗尽到可重新使用的检查。

连接已拿到时，让SQL超时

下一阶段在已借出的连接上执行：

SET statement_timeout = '200ms';
SELECT pg_sleep(1);

pg_sleep在真实PostgreSQL会话中制造一秒等待，服务端语句超时会取消它。程序只接受SQLSTATE 57014，打印 query_timeout，然后在同一连接再次执行 SELECT 42。这一段没有把SQL等待计入“池获取时间”。

实验处于自动提交模式，单条语句失败后可以执行下一条。若在显式事务中出现错误，需要按事务状态回滚后再使用；不能把自动提交实验的恢复流程原样套进长事务。statement_timeout、lock_timeout和事务相关超时的作用范围见 PostgreSQL客户端默认配置。

同时检查JSON字节和GZIP往返

数据库实验完成后，程序用Jackson编码1,000条 Item(id, "订单")，再解析并核对记录数与字段。接着对JSON、1MiB重复字节和1MiB固定种子的随机字节执行真实GZIP压缩、解压和逐字节比较。

var bytes = new ByteArrayOutputStream();
try (var gzip = new GZIPOutputStream(bytes)) {
    gzip.write(input);
}
byte[] packed = bytes.toByteArray();

关闭GZIP流会完成格式尾部写出；如果在完成前读取缓冲区，可能得到不完整压缩流。GZIPOutputStream API提供了 finish 与 close 的规则。

每行输出包含原始字节数、压缩后字节数和实际压缩耗时，最后应出现 pool/sql/json/gzip checks passed，进程退出0。重复数据应显著缩小，固定随机数据不会得到相同收益。毫秒值是短演示观测，包含预热与机器噪声，不用于给编码库排名；严格的对照方法见基线、压测与性能回归。

Java17复验可把Maven镜像替换为 maven:3.9.12-eclipse-temurin-17 重新编译，再执行：

JDK_IMAGE=eclipse-temurin:17.0.20_8-jdk docker compose run --rm lab
docker compose down --remove-orphans

down会停止本组容器，临时数据库内容随容器删除，源码、target和Maven缓存保留。不要在共享环境使用全局清理命令替代这个范围明确的操作。

按资源等待位置处理慢请求

CPU很低，响应却很慢

查看worker栈、池等待和远程调用。线程可能在等待连接、锁、Socket或队列；此时增加CPU通常不会让这些等待直接消失。先从高等待量的范围找到资源持有者，再确认它们正在做什么。

若借出连接很多而SQL执行时间短，查看事务是否包住远程请求、响应编码或慢客户端写出。缩短持有区间后重新测连接等待，避免只调整池大小。线程与运行诊断可结合后端能力地图中的并发和JVM学习入口。

扩大池以后数据库更慢

核对全部实例的活动会话、查询吞吐、锁与IO。数据库已经繁忙时，更多连接会允许更多工作同时竞争；如果吞吐没有增加、等待却增长，应回退这个变化，再缩小查询工作量或限制慢任务并发。

如果数据库有余量但应用等待仍高，检查连接创建是否失败、连接验证是否频繁失败、是否存在泄漏，以及最小空闲与连接寿命是否导致大量重建。池等待与建立连接失败要使用不同计数。

压缩后字节更小，总时间却上升

同时保留压缩前后字节、编码与压缩CPU、分配量、客户端解压成本和完整调用耗时。小响应、低带宽压力或CPU已经接近饱和时，压缩收益可能不足以覆盖计算成本。先按响应类型设置阈值，再比较相同业务输出下的有效吞吐与延迟。

大对象解析慢时，检查字段与集合规模、对象树是否被重复构建、是否在编码与压缩之间复制了整份缓冲区。降低内存复制应以完整输出一致为前提；连接提前归还、编码按需流式处理和慢客户端背压也需要一起验证。

权威资料与规范地址

跳到正文