压测一跑起来连接池先被打满接口报错堆成山日志里全是Connection is not available。我盯着监控面板数据库连接数一路飙到上限线程全卡在获取连接的等待队列里整个应用像被掐住脖子一样喘不上气。这是高并发下做 Java DAO 层测试最常见的修罗场。这篇文章不聊虚的就讲清楚三件事连接数怎么管、请求怎么错峰、并发怎么限流。这套方法论我是在多个项目的压测实战里反复打磨出来的适用场景很明确——大批量、高并发的 DAO 层测试比如数据迁移校验、批处理回放、接口压测前置数据准备。无论你是刚接触压测的新人还是被测试环境稳定性折腾得头疼的老手照着这篇文章的思路去搭至少能让你的 DAO 层测试从随机崩变成稳如狗。1. 高并发下的 DAO 层测试问题到底出在哪1.1 崩溃点一连接池被借空的连锁反应用生活化的方式理解连接池它就是数据库连接的水龙头。正常情况下水龙头够用但并发一上来每个线程都要开一个水龙头接水池子里的连接是有限的比如 HikariCP 默认maximumPoolSize 10而你有 50 个线程同时去抢那 40 个线程就只能排队等着。真正让系统崩溃的不是排队本身而是排队引发的连锁反应。等不到连接的线程会一直占着线程池的 worker 不释放而线程池的 worker 数量也是有限的。线程池被打满后新的任务开始进入拒绝策略这时候如果你的业务代码对拒绝异常处理不友好轻则报错重试重则直接丢数据。我在一个批处理项目里就踩过这个坑数据回放任务一启动2 分钟内连接池满10 分钟内线程池满30 分钟后整个应用无响应最后只能靠重启恢复。1.2 崩溃点二测试数据互相踩踏高并发下 DAO 层测试的另一个隐形杀手是测试数据干扰。举个例子你为了测批量插入开了 20 个并发线程同时往同一张用户表里写数据假设每条数据的业务主键是手机号而你在测试数据里用了同一个手机号段那就会有大量Duplicate entry报错。更隐蔽的是数据统计类的测试。你的 DAO 层如果包含统计今日订单金额这类聚合查询多个线程同时写订单数据、同时做统计跑出来的结果很可能是错的——不是因为 SQL 写得不对而是读写并发没有做隔离。这种问题在修复上特别浪费时间因为你要花很多精力去排查是不是 SQL 逻辑本身有问题最后才发现是数据被并发写乱了。1.3 崩溃点三资源竞争把正常流量一起拖死这是很多人忽略的一点DAO 层测试不是在一个真空环境里跑的。你的测试环境里可能还部署着别的服务实例或者同一个实例上还有其他业务在跑。高并发的 DAO 层压测会占满数据库 CPU、吃掉大量带宽和内存轻则影响同一数据库上的其他应用重则把整个测试环境搞瘫。数据库的资源是有限的。一次全表扫描可能就吃掉几秒 CPU20 个并发全表扫描那就是 20 倍的 CPU 开销。我在一次压测里观察过数据库的 CPU 使用率从正常的 15% 直接飙升到 98%响应时间从 5ms 涨到了 800ms。连带着同一个库的其他业务接口全部超时。所以高并发 DAO 层测试不单要管住连接数还要管住你对数据库资源的总消耗。2. 连接数管控把水管拧到可控范围2.1 HikariCP 核心参数怎么调才算稳既然连接池是第一个被打穿的点那第一步就是把连接池参数降到一个可控的范围。注意我说的是可控而不是越大越好。很多人有一个误区测试要快所以把连接池设得特别大。但连接池大的代价是数据库线程数飙升、上下文切换加剧、整体吞吐反而不升反降。以 HikariCP 为例我推荐这套参数作为起点HikariConfig config new HikariConfig(); config.setJdbcUrl(jdbc:mysql://your-db:3306/test_db); config.setUsername(test_user); config.setPassword(test_pass); config.setMaximumPoolSize(20); config.setMinimumIdle(5); config.setConnectionTimeout(3000); config.setIdleTimeout(600000); config.setMaxLifetime(1800000); config.setPoolName(daoTestsPool);maximumPoolSize设 20 是因为大多数 DAO 层压测场景下20 个连接足够支撑每秒几百次的简单增删改查。如果你要跑的是复杂查询建议调到 30 封顶再多收益就很有限了。connectionTimeout设 3000ms 非常关键这是给线程等不到就放弃的保底机制避免线程无限排队把线程池拖垮。这里要强调连接池参数不应该是拍脑袋定的。有一个简单的计算公式连接数 线程数 * (单次任务占用连接的时间 / 单次任务总耗时)。如果你的线程数是 50每个任务里真正拿连接执行 SQL 的时间是 10ms任务总耗时是 50ms那连接数只需要 50 * (10/50) 10 个就够用。按这个公式算出来的值再留个 1.5 到 2 倍的冗余就是比较合理的配置。2.2 连接数上限的设计逻辑我在实际项目中还会做一层连接数上限的业务侧管控而不是完全依赖连接池。什么意思就是在代码层面加一个计数器或信号量把 DAO 层测试实际用到的并发连接数卡在连接池的 80% 左右。原因很简单连接池还有一部分连接可能被其他业务占用。如果你把池子设成 20测试却用满 20那同一实例上的其他业务就一条连接都拿不到了。我在测试基类里的做法是加一个静态信号量同一时间最多只让 16 个线程同时访问数据库private static final Semaphore DB_ACCESS_LIMIT new Semaphore(16); protected void executeWithLimit(Runnable task) throws InterruptedException { DB_ACCESS_LIMIT.acquire(); try { task.run(); } finally { DB_ACCESS_LIMIT.release(); } }这个设计的好处是即使你后续不小心把某个测试类的线程数调到了 50也不会真的同时有 50 个线程去抢数据库连接——信号量会帮你拦一道。2.3 用监控验证连接池状态参数调完了不是就结束了。你要能随时看到连接池的实时状态。我在压测期间会在测试代码里加一点监控埋点定期输出连接池的关键指标HikariPoolMXBean poolMXBean hikariDataSource.getHikariPoolMXBean(); logger.info(active{}, idle{}, total{}, waiting{}, poolMXBean.getActiveConnections(), poolMXBean.getIdleConnections(), poolMXBean.getTotalConnections(), poolMXBean.getThreadsAwaitingConnection());这里我最关心的是waiting这个值。如果它持续大于 0说明连接已经不够用了如果它一直在涨说明线程积压在加剧。正常情况下连接池应该有少量空闲连接等待线程数为 0 或者偶尔出现 1。如果观察到的数据和这个正常状态偏离很大就需要回头检查参数设置。注意压测过程中的监控输出要控制频率别每执行一次 SQL 就打一条日志否则日志本身会成为新的性能瓶颈。我一般每 3 秒打一次或者用定时任务在后台单独输出。3. 错峰访问把压力摊到时间轴上3.1 错峰的核心思路连接数管住了接下来要管的是访问模式。高并发 DAO 层测试最容易出现的问题就是波峰叠加——所有线程都集中在同一秒去访问数据库。比如你开了 20 个线程每个线程的第一次查询都发生在启动后的 100ms 内那数据库在那一瞬间收到的请求数就是 20 倍的平均值。波峰叠加会导致短时间的数据库 CPU 飙高然后触发锁等待接着所有请求都变慢形成一个恶性循环。错峰访问的思路很简单把并发请求的发起时间在时间轴上抹匀。不让 20 个线程同时起步而是让它们在 0 到 2 秒内依次启动。这样数据库收到的请求量是平滑的而不是陡峭的尖峰。3.2 基于时间窗口的任务调度实现具体怎么做我用的是固定速率启动的方式配合一个简单的调度器。比如我要并发 20 个任务希望它们在 2 秒内全部启动那每个任务之间的启动间隔就是 2000ms / 20 100ms。一个实用的小技巧是用Thread.sleep()加一个递增的延迟参数来模拟启动间隔public class StaggeredRunner { private final int concurrency; private final Duration window; private final ExecutorService executor; public StaggeredRunner(int concurrency, Duration window) { this.concurrency concurrency; this.window window; this.executor Executors.newFixedThreadPool(concurrency); } public void run(ListRunnable tasks) throws InterruptedException { long intervalNanos window.toNanos() / tasks.size(); long startNanos System.nanoTime(); for (int i 0; i tasks.size(); i) { long targetStart startNanos i * intervalNanos; long currentDelay targetStart - System.nanoTime(); if (currentDelay 0) { Thread.sleep(currentDelay / 1_000_000, (int) (currentDelay % 1_000_000)); } final int taskIndex i; executor.submit(() - { try { tasks.get(taskIndex).run(); } catch (Exception e) { logger.error(task {} failed, taskIndex, e); } }); } executor.shutdown(); executor.awaitTermination(1, TimeUnit.HOURS); } }你可能会问这不就是加了个sleep吗对原理就是这么朴素。但核心在于每个任务不是启动后立刻执行 SQL而是精确控制到什么时候才开始执行这样数据库接收到的流量是均匀分布的。3.3 错峰与批处理结合错峰不仅适用于任务启动阶段还适用于 DAO 层测试里的批量操作。我在做大批量数据回放测试时会把数据分成多个批次每个批次的执行时间错开。比如总共 1000 万条数据分成 100 个批次每批 10 万条批次之间的启动间隔控制在 50ms 到 200ms 之间。用代码表示就是int totalBatches 100; int batchSize 100_000; for (int i 0; i totalBatches; i) { int start i * batchSize; int end start batchSize; executor.submit(() - batchProcessor.process(start, end)); Thread.sleep(100); // 批次之间错开 100ms }这个模式特别适合数据迁移校验、对账跑批这一类重 IO 的 DAO 层测试场景。既能让整个压测过程看起来像一个连续的负载流又不会瞬间把数据库的 IO 能力吃干抹净。注意错峰间隔不要设成固定值就完事了。我建议根据数据库的响应时间动态调整——如果数据库平均响应时间在上升说明负载已经接近临界点需要调大间隔如果响应时间很稳定可以适当调小间隔加快测试进度。4. 并行限流控制同时出发的人数4.1 线程池限流 vs 信号量限流错峰解决的是启动时间分布问题但还有一个维度需要控制同一时刻到底允许多少任务并行执行。这就涉及并行限流了。实现并行限流有两种主流方式线程池限流和信号量限流。它们各有适用场景。线程池限流是把任务扔到一个固定大小的线程池里执行。如果线程池大小是 10那同一时刻最多只有 10 个任务在跑第 11 个任务会在队列里排队。它的特点是不仅限制了并发度还限制了资源占用因为线程池的 worker 是真实占用系统资源的。信号量限流则是在任务执行前获取一个许可拿到许可才能继续否则就阻塞等待。它不限制线程数量只限制同时进入临界区的任务数量。它的特点是更轻量适合在已经有线程池的基础上再加一道保护。我个人的做法是如果任务是 IO 密集型的 DAO 操作优先用线程池限流因为数据库连接、网络 IO 这些资源都会被线程直接占用如果任务是 CPU 密集型的计算逻辑加少量 SQL 查询用信号量限流更灵活不会把 CPU 核心数浪费在线程排队上。4.2 信号量 Semaphore 实战下面是一个信号量限流的典型用法我用在测试基类里让所有 DAO 测试在同一个并发上限下执行public abstract class BaseDaoConcurrencyTest { private static final int MAX_CONCURRENCY 12; private static final Semaphore CONCURRENCY_GATE new Semaphore(MAX_CONCURRENCY); protected T ListT runConcurrently(int taskCount, SupplierT daoCall) throws InterruptedException { ExecutorService executor Executors.newFixedThreadPool(taskCount); ListFutureT futures new ArrayList(); CountDownLatch readyLatch new CountDownLatch(taskCount); CountDownLatch startLatch new CountDownLatch(1); for (int i 0; i taskCount; i) { futures.add(executor.submit(() - { readyLatch.countDown(); startLatch.await(); // 所有线程就绪后同时出发 CONCURRENCY_GATE.acquire(); try { return daoCall.get(); } finally { CONCURRENCY_GATE.release(); } })); } readyLatch.await(); startLatch.countDown(); // 收尾 executor.shutdown(); executor.awaitTermination(1, TimeUnit.HOURS); ListT results new ArrayList(); for (FutureT future : futures) { results.add(future.get()); } return results; } }这段代码有几个值得注意的设计点readyLatch和startLatch的组合是为了保证所有线程真正就绪后再同时出发避免线程还在创建过程中对测试结果造成干扰。CONCURRENCY_GATE是限流的核心它保证不管taskCount设置成多少同一时刻最多只有 12 个任务真正执行 DAO 操作。信号量要放在startLatch.await()之后获取否则拿不到许可的线程会一直阻塞在acquire()导致后面的线程根本无法就绪。4.3 限流参数怎么定限流的数值不能拍脑袋。我的经验是结合两个指标来确定数据库的连接池大小和数据库的吞吐能力。连接池大小是一个硬约束。MAX_CONCURRENCY不应该超过连接池maximumPoolSize的 80%。假设连接池设的 20那限流最多设 16。这样即使每个并发任务都占用一个连接也还有 4 个连接作为缓冲留给其他业务。数据库吞吐能力是另一个参考维度。你可以先做一个单连接压测测出数据库能承受的 QPS 上限然后用这个值反推限流数。比如单连接下你的 DAO 方法能跑 50 QPS数据库的合理负载是 800 QPS那限流数可以设为 800 / 50 16。这是理论值实际建议再打个七折设置为 12 左右给波动留余量。5. 完整测试基类落地示例5.1 配置样例有了前面的思路我把整套方案整合成一个可直接落地的测试基类。先看配置部分我使用的是 Testcontainers 加 MySQL 的测试环境方便本地复现。当然你也可以用已有的测试库配置逻辑是一样的。# application-test.properties spring.datasource.hikari.maximum-pool-size20 spring.datasource.hikari.minimum-idle5 spring.datasource.hikari.connection-timeout3000 spring.datasource.hikari.idle-timeout600000 spring.datasource.hikari.max-lifetime1800000 # 自定义配置DAO测试专用 dao-test.max-concurrency12 dao-test.stagger-window-ms2000 dao-test.task-count20 dao-test.retry-count3这些配置我都加了详细注释方便你根据自己项目的实际参数调整。5.2 测试基类代码基类里我整合了三个阶段启动前的连接池预检、任务执行时的错峰限流、结束后的数据清理。这三个阶段缺一不可。SpringBootTest ActiveProfiles(test) public abstract class BaseDaoHighConcurrencyTest { Autowired protected JdbcTemplate jdbcTemplate; Value(${dao-test.max-concurrency:12}) private int maxConcurrency; Value(${dao-test.stagger-window-ms:2000}) private long staggerWindowMs; BeforeEach void preCheckConnectionPool() { // 连接池预检确保数据库连接池可用 Integer result jdbcTemplate.queryForObject(SELECT 1, Integer.class); Assertions.assertEquals(1, result); } protected void executeDaoTest(int taskCount, String taskName, ConsumerInteger daoTask) throws Exception { long startTime System.currentTimeMillis(); Semaphore concurrencyGate new Semaphore(maxConcurrency); ExecutorService executor Executors.newFixedThreadPool(taskCount); CountDownLatch doneLatch new CountDownLatch(taskCount); ListThrowable errors Collections.synchronizedList(new ArrayList()); long intervalNanos TimeUnit.MILLISECONDS.toNanos(staggerWindowMs) / taskCount; long startNanos System.nanoTime(); for (int i 0; i taskCount; i) { final int taskIndex i; long targetStart startNanos i * intervalNanos; long delayNanos targetStart - System.nanoTime(); if (delayNanos 0) { Thread.sleep(delayNanos / 1_000_000, (int) (delayNanos % 1_000_000)); } executor.submit(() - { try { concurrencyGate.acquire(); try { daoTask.accept(taskIndex); } finally { concurrencyGate.release(); } } catch (Throwable t) { errors.add(t); } finally { doneLatch.countDown(); } }); } // 等待所有任务完成 boolean completed doneLatch.await(30, TimeUnit.MINUTES); executor.shutdown(); if (!completed) { throw new IllegalStateException(DAO测试任务超时未完成); } if (!errors.isEmpty()) { throw new RuntimeException(DAO测试执行过程中存在异常, errors.get(0)); } long elapsed System.currentTimeMillis() - startTime; logger.info(任务 {} 完成耗时 {} ms并发数 {}, taskName, elapsed, taskCount); } AfterEach void cleanTestData() { // 清理测试数据避免脏数据影响下一次测试 jdbcTemplate.execute(DELETE FROM test_order WHERE test_flag 1); jdbcTemplate.execute(DELETE FROM test_user WHERE test_flag 1); } }这段代码的每一步都有明确的目的我再拆解一下preCheckConnectionPool在每轮测试前检查数据库连接是否正常。这个很关键如果数据库连接不正常后面所有测试跑出来的结果都没有参考价值。executeDaoTest是核心方法。它把错峰启动和信号量限流整合在一起任务按照staggerWindowMs指定的窗口内均匀启动同时受限于maxConcurrency。cleanTestData在每轮测试后清理脏数据。我在测试数据里统一加了test_flag字段就是为了方便这批清理操作。5.3 执行效果验证这个基类的效果我实际跑过的压测数据是这样的任务数 50错峰窗口 3 秒最大并发 12。跑下来耗时 42 秒数据库连接池的active稳定在 10 到 12 之间waiting始终为 0数据库 CPU 峰值从之前的 98% 降到了 40% 左右。测试全程没有出现连接超时或任务失败整个过程完全可控。而对比之前不设限的裸并发测试50 个任务同时启动20 秒内数据库 CPU 飙到 98%连接池被占满30 个任务报连接超时测试结果完全不可信。这个对比数据说明连接数管控、错峰、限流这三板斧不是拍脑袋想出来的是有实际效果支撑的。6. 常见问题与排查实录6.1 连接泄漏怎么排查高并发 DAO 层测试最常遇到的隐形问题就是连接泄漏。症状是测试跑着跑着连接池的active数只会涨不会跌最后所有连接都被占满新的请求全部超时。排查思路分三步第一步在测试基类里加一个连接池状态定时输出观察active会不会在任务结束后回落。正常情况下任务结束后active应该在几秒内降到minimumIdle附近。第二步如果发现active持续不降去看是不是有线程拿完连接后没有释放。我这边遇过一种情况代码里手动调用了Connection但忘了在finally里close()。这种问题在普通测试里很难发现因为连接池有空闲连接兜底但并发一上来泄漏几轮就把池子堵死了。第三步在测试代码里给数据源包一层代理记录每次拿连接和释放连接的调用栈。用到的是 HikariCP 的leakDetectionThreshold参数。这个参数设成 60000连接被持有超过 60 秒就会在日志里打印获取连接时的调用栈直接定位到是哪一行代码泄漏的。6.2 超时参数设多少合适超时参数是另一个容易踩坑的地方。连接池的connectionTimeout设太短比如 500ms在高并发下会出现大量正常排队但被判定超时的误杀设太长比如 30000ms又会让线程无限等待把线程池拖垮。我的建议是connectionTimeout设为 3000ms 到 5000ms 之间。这个值比数据库的慢查询阈值一般 1 到 2 秒要长又不会让线程等太久。如果你发现 3000ms 内拿不到连接那几乎可以肯定连接数已经不够用了你需要做的是调整并发上限而不是调高超时时间。还有一个参数容易被忽略validationTimeout。HikariCP 默认是 5000ms但这个值必须小于connectionTimeout否则会出现校验连接本身就把超时时间耗光的情况。我一般设成 3000ms 或更短。6.3 测试数据污染问题测试数据污染表现为上一轮测试的脏数据影响下一轮的查询结果或者导致Duplicate entry报错。我在第 5 章提供了cleanTestData的清理方案这里补充两个细节。第一清理操作要在连接池空闲的时候做。比如你刚跑完一个高并发测试连接池可能还有部分连接在做慢查询这时候执行大范围 DELETE 会拖慢整个清理过程。我一般会先调用一次连接池的evictIdleConnections()把空闲连接清掉再执行清理 SQL。第二清理字段要有独立标识不要用业务主键判断。我在测试表里统一加test_flag字段所有测试数据写入时都置为 1清理时就按这个字段删。这种方式最稳妥避免了误删线上数据或者清理不彻底。6.4 避坑清单速查我整理了日常最容易踩的 5 个坑直接看图坑点表现解决方案连接池过大数据库 CPU 飙高、线程切换频繁按公式计算并限制在 20 以内并发任务同时启动波峰叠加、瞬时请求量大使用错峰启动任务散布在时间轴上信号量限流缺失线程无限排队、连接耗尽用 Semaphore 限制最大并发数连接泄漏未监控连接池 active 只涨不跌开启 leakDetectionThreshold 定位测试数据无清理脏数据污染、Duplicate 报错统一 test_flag 字段、跑后清理提示以上配置都以 MySQL 8 Spring Boot 3 HikariCP 为参考环境。如果你用的数据库是 PostgreSQL连接池参数基本通用但清理 SQL 的语法要做相应调整。我个人在实际操作中的体会是DAO 层测试的稳定性问题说到底是一个资源预算问题。数据库的连接池、线程数、吞吐能力都是有限的资源你要做的不是把每一份资源都榨干而是为每类测试任务分配合理的资源配额。连接数管控解决的是总量配额错峰访问解决的是时间分布并行限流解决的是瞬时速率。三方面配合起来你的 DAO 层测试既能保持高吞吐又能稳稳当当地跑完。最后再分享一个小技巧把这三套参数全部抽到配置文件里每个测试任务可以独立覆盖。这样即使换了不同的压测场景比如从批量插入换成复杂报表查询也不用改测试代码只调配置就能适配不同的资源需求。我在项目里就是这么干的实测下来切换场景特别顺。