ListenBacklog 是 Apache HTTP Server 控制内核“已完成连接队列”长度的配置参数，影响 TCP 三次握手后连接排队等待 accept 的容量；它不属 Java，但作为反向代理时会限制 Java 应用接收请求的入口吞吐量。
ListenBacklog 参数在 Apache HTTP Server 中控制的是操作系统内核为某个监听套接字（listen socket）所维护的“已完成连接队列”（accept queue）的最大长度。它**不直接属于 Java**，而是 Apache 服务器自身的配置项；若你在 Java 应用中通过嵌入式 Apache（如使用 Apache Portable Runtime 或 JNI 调用），或 Java 应用前端部署了 Apache 作为反向代理，则该参数才间接影响 Java 服务的表现。
ListenBacklog 影响的是 TCP 连接建立的最后一步
当客户端发起 TCP 连接（SYN → SYN-ACK → ACK），三次握手完成后，内核会将该连接放入“已完成队列”（也叫 accept queue）。此时连接已就绪，等待 Apache 主进程/线程调用 accept() 取出并处理。ListenBacklog 就是这个队列的上限。
- 若新连接到达时队列已满，内核通常丢弃 SYN-ACK 后续的 ACK（或直接忽略 SYN），导致客户端连接超时或重传
- 在高负载下，如果 Apache 处理请求慢（如后端 Java 应用响应延迟大、线程阻塞、GC 暂停等），accept 调用不及时，队列就容易积压
- 默认值通常为 511（Linux）或由系统
net.core.somaxconn限制，往往不足以应对突发流量
高负载下 ListenBacklog 不足的典型表现
不是 502/504 错误，而是更底层的连接失败现象：
- 客户端日志出现 “Connection refused” 或 “Connection timeout”（尤其在短连接高频场景）
- Apache error_log 中可能无明显报错，但
ss -lnt显示对应端口的Recv-Q长期非零（接近 backlog 值） - 网络抓包可见大量重复 SYN 或客户端重发 SYN（因未收到有效 ACK 确认）
- Java 后端负载正常、响应时间稳定，但上游 Apache 接收请求数明显低于预期
如何合理设置 ListenBacklog
不能盲目调大，需配合系统与 Apache 架构协同优化：
立即学习“Java免费学习笔记（深入）”；
- 检查并调高系统级限制：
sudo sysctl -w net.core.somaxconn=65535（需写入/etc/sysctl.conf持久化） - 在 Apache 配置（
httpd.conf或虚拟主机中）显式设置：Listen 8080→ 改为Listen 8080 65535（注意语法：Listen 地址:端口 backlog） - 确认 Apache 使用的是 event/mpm_event 模式（推荐），避免 prefork 下因 fork 开销加剧 accept 延迟
- 监控指标应包括：
ss -lnt的 Recv-Q、Apache 的scoreboard状态、以及 Java 应用入口 QPS 与 Apache access.log 记录 QPS 的差值
它和 Java 应用的关联点其实很明确
ListenBacklog 本身不参与 HTTP 请求处理，也不影响 Java 字节码或线程调度。但它决定了“有多少个已建连的请求能排队等着被 Apache 交到 Java 手里”。一旦这个门限被击穿，再快的 Spring Boot 或 Tomcat 也收不到请求。
- 如果你用 Apache + mod_jk / mod_proxy_ajp 连接 Tomcat，ListenBacklog 控制的是 Apache 接收客户端连接的能力，而非 AJP 连接池
- 若用 Apache + mod_proxy_http，则同样适用；此时瓶颈可能从 Apache accept 队列，转移到后端 Java 的连接池（如 HttpClient max connections）或 Tomcat 的
maxConnections - 真正要提升整体吞吐，需端到端排查：Linux 网络栈 → Apache accept 效率 → 反向代理转发开销 → Java 容器线程模型 → 应用逻辑性能
