Java 中 CountDownLatch 的 await 方法返回超时问题

[chenfang]

我们公司系统是一个 Tomcat 集群,每个 tomcat 最高接受 1000 的并发,不过目前应该没有这么多也就 300 左右,

在 tomcat 接到请求之后,每个请求会再发送几个请求给不同的下游服务,然后主线程使用 public boolean await(long timeout, TimeUnit unit)等待请求完成,这里会根据算出来一个超时时间,防止 response 超时,但是实际的等待时间会比设置的时间多 50-100 毫秒(目前没有统计超过的占比数据,保守估计超时占比在 5%以下)

因为流量比较大,一天经过这个 await 方法的次数应该不到 60 亿(tomcat 数量不少),所以这种超时总量其实是不少的,能优化一点是一点(同时也能提升自己的技术水平)

上图是我问了 ChatGPT 之后,以我现在的知识水平来讲,我觉得是 GC 导致的,于是我看了其中一个 tomcat 的 GC 情况

我们目前使用的是 openJDK17,G1 的垃圾回收器,以及一些虚拟机参数应该也很久不变了(我认为是有优化空间的),比如 jkd17 是有 ZGC 的,之前查看 ZGC 的 world stop 时间会减少很多

验证是否是 GC 导致的方法,我想到的是记录 await 超时的时间戳和不超时的时间戳,分开统计,然后再记录 GC 的开始时间和结束时间,查看在 GC 这个时间段内的是否超时的时间戳占比大,这种验证方法可行么?

最后有大佬遇到过这种问题么?或者有没有别的思路解决这个问题

[cubecube]

除了你说的这种情况，更大的可能是调度延迟，你线程数太多了，核心数太少，该超时的时候，调度不上去

[ikas]

只是靠这些,没法分析.

一般都是上指标监控,搭建一个 Promethues,grafana . 然后接口接加上指标统计..搭配 jvm gc,系统 cpu 等指标一起分析

[chenfang]

@cubecube 我也怀疑过这种,但是我看 cpu 并不高才 30%+,或者调度延迟并不跟 cpu 负载有关系?

[chenfang]

@cubecube 你指的核心数是指硬件么?

[chenfang]

捞一捞 我的帖子..

[arloor]

@chenfang 线程开太多的话，会反应在 cpu load 上，cpu busy 可能并不会太高。