jmeter 压测时出现 `java.net.bindexception: address already in use: connect`，本质是客户端（jmeter）耗尽本地可用临时端口，而非 spring boot 服务端配置问题；需从操作系统端口复用、jvm 网络参数及分布式压测三方面协同优化。
该错误 并非 Spring Boot 应用本身性能瓶颈所致，而是 JMeter 所在机器（即压测发起端）的 TCP 客户端连接资源枯竭——典型表现为：高并发短连接场景下（如你设置的 100 线程/秒、持续 5 分钟），系统为每个 HTTP 请求分配一个临时端口（ephemeral port），而默认范围有限（Linux 通常为 32768–65535，仅约 32K 端口），且 TIME_WAIT 状态会阻塞端口快速复用。
✅ 关键调优方向（非 Spring Boot 属性配置）
Spring Boot 的 application.properties 或 application.yml 对解决此报错几乎无直接作用（因为问题不在服务端监听能力，而在客户端端口供给）。真正有效的措施如下：
1. 调整操作系统临时端口范围与复用策略（Linux 示例）
# 查看当前范围 sysctl net.ipv4.ip_local_port_range # 扩大范围（如扩展至 1024–65535） sudo sysctl -w net.ipv4.ip_local_port_range="1024 65535" # 启用 TIME_WAIT 套接字快速复用（务必确保后端服务无代理或四层负载均衡导致序列号混乱） sudo sysctl -w net.ipv4.tcp_tw_reuse=1 # 缩短 TIME_WAIT 超时（可选，谨慎使用） sudo sysctl -w net.ipv4.tcp_fin_timeout=30
⚠️ 注意：tcp_tw_reuse=1 在 NAT 环境或存在中间设备时可能引发连接异常，生产环境建议优先扩容端口范围 + 分布式压测。
2. 优化 JMeter 自身配置（jmeter.properties）
# 启用连接池复用（关键！避免每请求新建 socket） httpclient4.idletimeout=60000 httpclient4.maxconnections=2000 httpclient4.maxconnectionsperhost=1000 # 启用 Keep-Alive（服务端也需支持） http.connection.stalecheck=true
并在 HTTP 请求采样器中勾选 "Use KeepAlive" —— 这能显著降低端口消耗，将 100 并发线程的实际连接数从数千级降至数十级。
3. Spring Boot 服务端辅助加固（虽非根因，但提升整体稳定性）
# application.yml
server:
tomcat:
max-connections: 10000 # Tomcat 最大连接数
accept-count: 1000 # 全连接队列长度
max-http-header-size: 16384
connection-timeout: 5000 # 避免慢连接长期占用
spring:
web:
resources:
cache:
period: 0 # 压测期间禁用静态资源缓存干扰同时确保 JVM 启动参数合理：
java -Xms2g -Xmx2g -XX:+UseG1GC -Dfile.encoding=UTF-8 -jar app.jar
4. 终极方案：采用 JMeter 分布式压测
当单机端口与资源已达极限时，应横向扩展压测节点：
- 一台 Master（控制机）协调多台 Slave（执行机）
- 每台 Slave 承担部分线程负载，端口压力分散
- 配置参考：JMeter Distributed Testing 官方指南
✅ 总结
| 问题根源 | 正确应对方式 |
|---|---|
| BindException | 调整 OS 端口范围 + 启用 tcp_tw_reuse |
| JMeter 连接爆炸 | 启用 Keep-Alive + 调整 httpclient4 连接池 |
| Spring Boot 配置 | 仅需保障基础连接容量，无需过度调优 |
| 规模化压测 | 必须转向分布式架构，而非堆砌单机资源 |
请优先检查并优化 JMeter 所在机器的操作系统网络参数，再辅以连接复用配置——这比修改 Spring Boot 的任何属性都更直接、更有效。
