JMH是Java官方推荐的微基准测试工具，能屏蔽JIT预热、GC干扰和测量抖动；关键配置包括@Fork控制JVM参数、@Warmup充分预热、@Measurement多轮测量、@Threads调节并发、Mode.Throughput模式测ops/s吞吐量。
直接测吞吐量极限不能靠简单循环加 System.nanoTime()，那样结果失真严重——JIT还没热、GC突然停顿、线程调度抖动都会让数据飘忽不定。必须用专业基准测试框架，配合真实负载和可控环境。
用 JMH 做稳定吞吐压测
JMH 是 Java 官方推荐的微基准测试工具，能屏蔽 JIT 预热、GC 干扰和测量抖动。关键配置如下：
- 加 @Fork(jvmArgsAppend = {"-Xmx2g", "-XX:+UseG1GC"}) 控制堆内存与 GC 行为，避免内存波动干扰
- 设置 @Warmup(iterations = 5, time = 3, timeUnit = TimeUnit.SECONDS) 让 JIT 充分优化
- 正式测量用 @Measurement(iterations = 10, time = 5, timeUnit = TimeUnit.SECONDS) 多轮取平均
- 单线程测吞吐：用 @Threads(1)；多线程对比：分别试 @Threads(4)、@Threads(8)、@Threads(16)
- 模式选 Mode.Throughput，结果单位是 ops/s（每秒完成的批次数），不是单次耗时
构造贴近真实的批量任务
数据库操作吞吐受限于 IO、连接池、事务锁和网络，所以测试任务要模拟这些瓶颈：
- 每个任务执行一次 INSERT INTO ... VALUES (...), (...), ... 批量插入（比如 200 条/批）
- 复用同一个 DataSource，但确保每次任务使用独立连接（如 HikariCP 的
connection.close()自动归还） - 关闭自动提交，手动
tx.commit()，控制事务粒度一致 - 在数据库侧开启慢日志或监控
innodb_row_lock_time_avg（MySQL）或pg_stat_database（PostgreSQL），验证是否真卡在锁或写入上
线程池参数需匹配任务类型
数据库批量操作本质是 IO 密集型，线程数不是越多越好：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 先按公式粗估：IO 密集型 ≈ CPU 核数 × (1 + 平均等待时间 / 平均工作时间)；实测中常见 8–20 个线程已达瓶颈
- 线程池用 ArrayBlockingQueue（有界队列），容量设为 100～500，防止任务积压 OOM
- 拒绝策略建议 CallerRunsPolicy，让调用线程自己执行，避免丢任务且暴露真实承载上限
- 监控运行时指标：
getActiveCount()是否长期满载、getQueueSize()是否持续增长、getCompletedTaskCount()是否线性增长
识别吞吐拐点的三个信号
当增加线程数不再提升吞吐，甚至下降，说明触达极限。观察以下信号：
- 吞吐量平台期：从 @Threads(8) 到 @Threads(16)，ops/s 提升不足 10%
- 长尾响应飙升：95% 分位响应时间翻倍以上，说明连接池争抢或数据库锁排队加剧
- 拒绝率非零 或 队列堆积不降，表明下游（DB 连接、磁盘 IO、网络带宽）已饱和
测出的极限值不是固定数字，它取决于你的数据库配置、网络延迟、批大小和事务隔离级别。重点不是“跑多快”，而是清楚知道：当前配置下，吞吐卡在哪一层，以及换哪种策略（比如改用异步写入、分库分表或批量压缩）才真正有效。
