从一次 FULL GC 卡顿谈对服务的影响

最新推荐文章于 2025-04-27 11:34:13 发布

Weiguang_123

最新推荐文章于 2025-04-27 11:34:13 发布

阅读量1.1w

点赞数

分类专栏：工作总结 java

本文链接：https://blog.youkuaiyun.com/Weiguang_123/article/details/48577175

版权

本文通过一次FULL GC引发的TCP连接问题，探讨了Java服务优化的步骤。首先分析了TCP连接的建立过程和服务器队列，发现FULL GC导致服务卡顿，影响TCP连接。然后，通过调整CMSInitiatingOccupancyFraction参数以避免promotion failed，优化救助空间大小，以及调整缓存过期时间和精简代码，逐步解决了问题。总结指出，CMS垃圾回收器在减少停顿时间的同时牺牲了堆空间利用率，优化应结合理论与实践。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Full GC 的时间和次数是管理java的应用服务不得不考虑的问题，高吞吐量和低停顿是追求高质量服务重要目标，从而会有根据业务的特点衍生出各种垃圾回收器。在实战中如何根据如何使用ParNew ，CMS等回收器和配置各种参数，要在理论结合实践中不断优化。

一、问题的发现

看到线上的服务机器一些节点时不时地有TCP报警，所以我们断定是TCP的连接出现了问题。

让我们来回顾一下TCP的三次握手和四次挥手，借网上的一个图：

当第一次握手，建立半连接状态：

client 通过 connect 向 server 发出 SYN 包时，client 会维护一个 socket 队列，如果 socket 等待队列满了，而 client 也会由此返回 connection time out，只要是 client 没有收到第二次握手SYN+ACK，3s 之后，client 会再次发送，如果依然没有收到，9s 之后会继续发送。

此时server 会维护一个 SYN 队列，半连接 syn 队列的长度为 max(64, /proc/sys/net/ipv4/tcp_max_syn_backlog) ，在机器的tcp_max_syn_backlog值在/proc/sys/net/ipv4/tcp_max_syn_backlog下配置，当 server 收到 client 的 SYN 包后，会进行第二次握手发送SYN＋ACK 的包加以确认，client 的 TCP 协议栈会唤醒 socket 等待队列，发出 connect 调用。

最低0.47元/天解锁文章