Java应用在Docker中“连接数耗尽”主因是宿主机内核参数限制（如端口范围、TIME_WAIT复用、文件描述符），需调优net.ipv4.ip_local_port_range、net.ipv4.tcp_tw_reuse、fs.file-max等，并配合--ulimit nofile和JVM容器感知参数，同时Java层须合理配置连接池与资源释放。
Java 应用在 Docker 容器中出现“连接数耗尽”，通常不是 Java 层面的线程或连接池配置问题，而是宿主机内核对网络资源的限制（如 net.ipv4.ip_local_port_range、net.ipv4.tcp_tw_reuse、fs.file-max 等）未合理调整，导致容器共享宿主机内核时，短连接密集场景下端口耗尽、TIME_WAIT 积压、文件描述符不足。Docker 本身不隔离内核参数（除少数 namespace 可控项），需从宿主机层面调优，并配合容器启动参数显式传递关键限制。
确认瓶颈是否真由内核参数引发
先排除应用层误判：在容器内执行以下命令，比对实际使用与系统上限：
-
cat /proc/sys/net/ipv4/ip_local_port_range—— 查看可用端口范围（默认32768 60999，仅约 28K 端口） -
ss -s | grep "timewait"—— 统计 TIME_WAIT 连接数（若超万级且持续增长，说明复用不足） -
cat /proc/sys/fs/file-max和ulimit -n—— 分别看系统级和当前进程级文件描述符上限 -
docker stats <container>查看pids和open files是否接近 limit
宿主机必须调整的核心内核参数
这些参数影响所有容器，需写入 /etc/sysctl.conf 并执行 sysctl -p 生效：
-
扩大本地端口范围：
net.ipv4.ip_local_port_range = 1024 65535（提供超 64K 可用端口） -
启用 TIME_WAIT 复用：
net.ipv4.tcp_tw_reuse = 1（允许将 TIME_WAIT 套接字用于新连接，需配合net.ipv4.tcp_timestamps = 1） -
降低 TIME_WAIT 超时：
net.ipv4.tcp_fin_timeout = 30（默认 60 秒，可加速回收） -
提升系统文件描述符上限：
fs.file-max = 2097152（建议设为 200 万以上） -
优化连接队列：
net.core.somaxconn = 65535、net.core.netdev_max_backlog = 5000
容器启动时显式传递资源限制
Docker 默认继承宿主机 ulimit，但需主动指定以确保 Java 进程生效：
立即学习“Java免费学习笔记（深入）”；
- 启动时加
--ulimit nofile=65536:65536（软硬限制一致，避免 JVM 启动报错） - 若用 docker-compose.yml，写：
deploy: resources: limits: pids: 4096ulimits: nofile: soft: 65536 hard: 65536 - JVM 启动参数建议补充
-XX:+UseContainerSupport（JDK 10+ 默认开启），让 HotSpot 正确读取 cgroup 限制，避免线程数/堆内存误判
Java 应用层协同优化不可跳过
内核调优只是基础，Java 侧必须匹配，否则仍会提前耗尽连接：
- HTTP 客户端（如 OkHttp、Apache HttpClient）务必启用连接池，并设置合理
maxIdleTime、keepAliveDuration - 数据库连接池（HikariCP）的
maximumPoolSize建议 ≤ 宿主机可用端口数 ÷ 2（防短连接风暴） - 避免手动
new Socket()或未关闭的InputStream，用 try-with-resources - 监控指标接入：暴露
ActiveCount、IdleCount（连接池）、fd_usage_percent（文件描述符使用率）
不复杂但容易忽略：Docker 容器共享宿主机内核，内核参数调优永远在宿主机做，容器内修改无效；而 ulimit 和 JVM 参数才是容器维度可控点。三者（宿主机内核 + 容器资源限制 + Java 连接管理）缺一不可。
